Comment le partage d'informations d'identification ouvre la porte aux violations
Contenu
Introduction
Qu'il s'agisse d'un portail de connexion bancaire, d'un logiciel Open Source ou même du système d'exploitation lui-même, la dépendance actuelle à la technologie a rendu les professionnels de la technologie et le grand public redevables à d'autres personnes. Le besoin de cohérence et de commodité nous a amené des choses comme les bibliothèques de codes, car l'écriture de chaque élément de code de A à Z n'est pas évolutive.
Plus les environnements gagnent en complexité, plus il est important de trouver des endroits où l'on peut automatiser et réutiliser les outils déjà disponibles.
Cependant, l'utilisation du code de ces bibliothèques préétablies par un développeur comme base de son propre code crée des « problèmes de confiance ». Cette utilisation nécessite un niveau de confiance qu'un professionnel de la sécurité pourrait considérer comme risqué. Plus une vulnérabilité est cachée dans le code source, plus elle est difficile à trouver ; à supposer que vous sachiez rechercher cette aiguille digitale dans une botte de foin.
Nous avons rencontré un exemple de ces problèmes de confiance dans notre propre processus de développement. Une utilisation apparemment anodine de l'un de nos services externes a finalement conduit à la découverte de plusieurs possibilités d'attaques graves. Après avoir divulgué les informations au fournisseur, les problèmes identifiés ont été résolus. Dans cet article de blog, nous partageons nos découvertes, nous expliquons en détail comment nous les avons faites et nous discutons de la manière dont les attaquants peuvent potentiellement les utiliser à leur avantage.
Jetons un coup d'œil
Au cours d'un test d'optimisation de routine, l'un de nos ingénieurs DevOps a créé un nouveau conteneur pour un outil de test tiers. Il a exécuté la commande très courante suivante : apt get update && apt get install XXXX -y.
Après avoir saisi la commande, nous avons voulu voir ce qui était exécuté sur notre point de terminaison pendant que le processus de création était en cours d'exécution. Pour ce faire, nous avons exécuté la commande simple de liste de processus ps sur notre point de terminaison et nous sommes tombés sur cette ligne très intéressante :
Nous avons pu utiliser les informations d'identification obtenues pour nous authentifier sur un site contenant des centaines de builds de clients.
La présence d'une clé en texte clair était alarmante, mais pouvait être expliquée/contenue par un contrôle utilisateur approprié ; par exemple, avec un jeton par utilisation de l'application. Ce n'était manifestement pas le cas ici. Le nom d'utilisateur fourni contenait la chaîne « default », ce qui n'est jamais bon signe.
Nous avons décidé de creuser un peu plus et avons essayé d'utiliser les informations d'identification pour nous authentifier auprès de l'API, ce qui nous a permis de rechercher des informations potentiellement sensibles et très nombreuses. Il s'est avéré que l'utilisateur « par défaut » méritait bien son nom… Cet utilisateur n'était pas réservé à Akamai, mais était utilisé par l'ensemble de la base de clients de l'application.
Muni de ce secret en texte brut, n'importe quel pirate pouvait récupérer des données sensibles, telles que des résultats de tests internes, des enregistrements vidéo, des captures d'écran et des flux d'exécution de scripts internes, de la plupart des clients de l'application (Figure 1).
Fig. 1: Example of improperly accessed sensitive customer data
La quantité extraordinaire de données qui ont été exposées et la visibilité intrinsèque de la vulnérabilité nous ont donné envie d'examiner plus en détail leur base de code et de voir ce qu'il était possible de trouver d'autre.
Il ne faut pas tout partager
Après avoir identifié un secret partagé qui était gravement mal utilisé par l'application, nous avons décidé de partir à la recherche d'autres secrets de ce type. Après quelques recherches bien ciblées (et beaucoup d'enjolivement) dans le code source des applications, nous avons découvert trois secrets supplémentaires :
- Une clé privée Coralogix
- Une clé API Google
- Un jeton ngrok
Examinons chacun de ces secrets et leur potentiel d'utilisation abusive.
Coralogix : Une clé privée (très publique)
L'un des secrets identifiés dans la base de code de nos applications était une clé privée, ce qui a suscité notre intérêt. Nous avons donc cherché un nom d'utilisateur éventuellement lié à cette clé privée. Nous avons réussi à trouver un nom d'utilisateur quelques lignes sous la clé, dans le cadre d'une fonction de journalisation. À partir d'autres indices qui avaient été laissés, nous avons découvert que la clé privée appartient au cadre de journalisation Coralogix.
Les informations d'identification étaient codées en dur, ce qui signifie qu'elles étaient également partagées par différents clients. Cela pourrait signifier une autre fuite de données potentielle, mais heureusement, cet utilisateur/attaquant disposait de privilèges faibles et n'était autorisé qu'à écrire des messages de journal dans le cadre.
Bien qu'elle ne soit pas aussi puissante que la primitive précédente, une primitive d'écriture peut toujours faciliter des vecteurs intéressants sur le fournisseur lui-même : Un attaquant peut insérer des messages de journal frauduleux dans l'environnement du fournisseur ou tenter d'injecter des journaux malveillants pour effectuer des attaques telles que le cross-site scripting (XSS) ou l'injection SQL (Structured Query Language).
Clé API Google
OAuth est un mécanisme d'autorisation utilisé par toutes les opérations de Google. Les applications et les sites peuvent permettre aux utilisateurs de se connecter à leurs applications ou à leurs sites à l'aide de leur compte Google facilité par OAuth. Pour activer cette option par le biais du code, les développeurs ont besoin de plusieurs paramètres qu'ils peuvent obtenir à partir de leur compte Google, à savoir leur clé API : leur google_name et leur google_secret.
En parcourant le code, nous avons trouvé une référence à l'API Google. En général, lorsque nous voyons une clé « google api », nous ne voyons que cela ; mais pas cette fois. Cette fois-ci, nous avons également trouvé la clé « google api », l'identifiant unique google_client , et (le plus déconcertant !) l'identifiant google_secret . Avec ces trois identifiants, les attaquants peuvent demander un lien d'authentification à Google en tant que fournisseur. Ce lien peut être utilisé dans le cadre d'une campagne d'hameçonnage pour inciter les victimes à autoriser les attaquants à accéder à leur espace de travail.
Exploitation potentielle de l'hameçonnage
Les attaquants peuvent créer un e-mail d' hameçonnage contenant un lien vers un site identique au site du fournisseur avec un changement crucial : le lien permettant de se connecter à Google est le lien que l'attaquant a obtenu en utilisant les détails de l'API Google du fournisseur (Figure 2).
Fig. 2: Malicious Google login page appears to be legitimate
En se connectant, la victime autorise l'attaquant à accéder à l'intégralité de son compte Google Workspace. En accédant à un élément aussi sensible qu'une identité Google, les possibilités offertes à un attaquant sont immenses. Une exploitation réussie permettrait à un attaquant de manipuler n'importe quel élément du compte Google Workspace de la victime, y compris la compromission des e-mails, le téléchargement de fichiers et bien d'autres choses encore. Cela pourrait s'avérer très utile dans le cadre d'une attaque d'ingénierie sociale contre des entreprises.
ngrok
La tunnellisation du réseau est une solution presque universelle pour le transfert de données sécurisé, qui peut fournir à un attaquant une manne d'opportunités malveillantes si elle est compromise. Nous avons découvert de nombreux paramètres liés à la tunnellisation dans l'installation de l'application compromise, y compris une configuration ngrok , ce qui nous a incités à approfondir nos recherches. Les mêmes fonctionnalités qui améliorent la collaboration entre les développeurs sont précisément celles qui rendent l'application attrayante pour un acteur malveillant.
Ngrok est un service spécialisé dans la fourniture d'une plateforme de tunnelisation d'informations via des serveurs. Ngrok facilite l'exposition des services à Internet, ce qui accélère le débogage et améliore l'efficacité des boucles de rétroaction de développement. Malheureusement, si un attaquant a pris le contrôle du tunnel, il a également accès à cette simplicité.
En invoquant une simple commande ps, un attaquant peut afficher l'identifiant unique et le jeton d'authentification de l'entreprise. Cet identifiant unique n'est pas modifiable ; il restera le même lors d'autres utilisations de l'application sur d'autres points de terminaison. Les attaquants peuvent utiliser ces paramètres pour envoyer l'ID et le jeton au serveur en ligne d'un fournisseur afin de recevoir les détails ngrok de l'entreprise (Figure 3).
Fig. 3: Ngrok token received from the vendor’s server
Cela signifie qu'après leur accès initial, les attaquants peuvent copier l'identifiant et le jeton uniques de la victime et les utiliser pour lire les données envoyées/reçues par l'application de la victime (Figure 4).
Fig. 4: Example of data being read from ngrok tunnel
Conclusion
Les menaces ne sont pas exclusivement externes. En fait, nous acceptons volontiers certaines menaces en interne. De nombreuses personnes pensent que les logiciels Open Source représentent le plus grand danger en raison de la confiance que nous leur accordons, mais les outils tiers peuvent représenter un défi encore plus grand pour les entreprises.
À la suite de nos découvertes, nous avons divulgué les problèmes décrits dans ce blog au fournisseur concerné, qui les a corrigés. Malgré cela, de nouvelles failles de sécurité sont toujours en embuscade.
Nous pensons que dans ce cas, et dans beaucoup d'autres, la surveillance de la sécurité est aussi importante que la formation des développeurs à la sécurité. Ces deux éléments peuvent contribuer à garantir aux entreprises que les services gérés ne leur causent aucun problème.