Le danger des espaces Cloud comme GitHub ou Amazon S3

En février 2018, le RSSI de la société Uber a témoigné devant un comité du sénat américain à propos de la fuite de données massive survenue en 2016 (et révélée fin 2017). Le site TheRegister.co.uk en a publié une analyse et l’on peut aussi consulter le témoignage intégral sur le site du sénat US.

Il y explique comment le vol des données Uber s’est déroulé :

• Les pirates ont obtenu le login et mot de passe d’un compte GitHub  privé utilisé par Uber pour héberger certains de ses développements. On ne sait pas comment ces informations ont été obtenues. Cela peut-être par exemple par une attaque en force brute (mot de passe trop simple) ou par un phishing. Uber a mis en place depuis une authentification 2-facteurs sur ses comptes GitHub.
• En explorant le contenu GitHub les pirates ont trouvé dans le code des jetons d’authentification permettant d’accéder aux « Buckets » Amazon S3 créés par Uber pour stocker des données de sauvegarde.
• L’accès Amazon S3 obtenu a permis aux pirates de voler les données Uber.

Nota : Les « Buckets » (« Compartiments » en Français) sont des espaces de stockage accessibles via des services web, commercialisés dans l’offre AWS (Amazon Web Services) sous le nom d’Amazon S3 (Simple Storage Service).

Ce schéma d’attaque est classique et c’est l’un des points de vigilance que nous identifions dans notre Bilan 2017 des failles et attaques. 

• Les entreprises  construisent de plus en plus des solutions basées sur le Cloud (par exemple via Amazon AWS ou Microsoft Azure) et utilisent aussi des outils collaboratifs dans le Cloud (comme GitHub) pour le développement de leurs projets IT.
• Si ces espaces Cloud ne sont pas correctement protégés, ils peuvent facilement être piratés.

La recherche d’espaces Cloud mal protégés est de plus en plus active :

Les attaquants ont pris conscience de ces faiblesses, et cela entraine une augmentation de ce type d’attaques. GitHub et les Buckets S3 sont les cibles les plus exposées, et il existe de plus en plus d’outils pour automatiser la recherche des cibles vulnérables. On peut citer par exemple :

• Gitleaks un outil (écrit en GO) pour rechercher dans un espace GitHub les codes d'accès AWS (API keys) ou autres.
• Slurp, S3Scanner ou AWSBucketDump : des outils pour rechercher des buckets S3 et tester s’ils sont mal protégés.

Trouver une liste des Buckets S3 existants chez Amazon est la principale difficulté pour l’attaquant, car les Buckets sont désignés par des noms choisis par leurs créateurs (par exemple « myawsbucket.s3.amazonaws.com ») et il n’existe pas d’annuaire. Il faut donc que le pirate essaye ces noms au hasard, ou cherchede façon plus ou moins systématique pour découvrir les Buckets qui existent vraiment.

De ce fait, il y aurait un boum dans les tentatives d’attaques si un moteur de recherche répertoriant les Buckets existants était ouvert sur Internet. Il y a eu récemment deux tentatives (au moins) dans ce domaine :

• Public Cloud Storage Search qui se base sur le moteur de recherche Google
• BuckHacker : ce service expérimental a été fermé quelques heures après son lancement. Officiellement, c’est parce qu’il a été submergé de requêtes (voir l’annonce officielle).

Combien y a-t-il réellement de sites mal protégés ?

La société HTTPCS a publié une étude intéressante sur ce sujet. Selon les tests qu’elle a réalisés :

• 5,8% des 100 000 Buckets qu’elle a testés contiennent des données accessibles en lecture pour tous (pas de login).
• 2% ne sont même pas protégés en écriture et permettent le dépôt ou l‘écrasement de données.

Le chiffre de 5,8% n’est pas énorme, si l’on considère qu’il ne s’agit pas systématiquement de données sensibles, mais il y a clairement des négligences. Il faudrait également disposer d’études sur l’ampleur des fuites de jetons AWS (fuites via Github par exemple) pour mieux mesurer le risque dans le cas d’attaques combinées (GitHub + S3). L’outil Gitleaks cité plus haut donne dans son fichier ReadMe les références d’une publication qui pourrait couvrir ce point. (

 Amazon est visiblement conscient de ces négligences :

• Depuis novembre 2017, il affiche des messages d’avertissement dans l’interface d’administration Amazon S3 si le bucket est « public » (accessible en lecture  pour tous).
• Depuis février 2018, il a rendu gratuit l’accès à son outil « Trusted Advisor S3 Bucket Permissions Check ».

Conclusion

Bien sûr, ces problèmes ne sont pas uniquement liés aux solutions Amazon, et ils sont également applicables sur les autres offres de ce type : Microsoft Azure, DropBox, Google Cloud, etc.

Le recours à des solutions Cloud expose l’entreprise à de nouveaux risques, ou plutôt ouvre sur Internet des risques qui existent parfois déjà dans le cas d’outils internes à l’entreprise. Par exemple, on sait que le maintien des droits d’accès corrects sur un espace documentaire partagé est une tâche exigeante et difficile à tenir sur le long terme sans une organisation stricte. Lorsque l’espace documentaire est accessible uniquement à l’intérieur de l’entreprise, le risque est limité à ce périmètre. Dans le cas d’une solution externalisée (via le cloud),  la notion de périmètre disparait.

Enfin, il faut noter également, que le plus souvent, ces fuites ne sont pas vraiment dûes à des négligences, mais plutôt à un manque de prise de conscience des dangers encourus.

Sur le même sujet

• Article de BleepingComputer.com : Amazon AWS Servers Might Soon Be Held for Ransom, Similar to MongoDB