HTTPCSLeader européen de la cyber sécurité

| À propos de nous
Étude d'impact - Configuration AWS Buckets Amazon S3

Étude d'impact - Configuration AWS Buckets Amazon S3 [FR]


Depuis plusieurs mois maintenant, les médias relatent des fuites de données liées à des Buckets Amazon S3 mal configurés et permettant la lecture de fichiers sensibles.


Amazon S3 est en effet un service de stockage dans le cloud. Afin d’y envoyer vos fichiers (photos, vidéos, PDF, etc.), vous devez dans un premier temps créer un « compartiment », appelé « bucket », dans l'une des régions Amazon Web Service (AWS). Cette étape permet de charger un nombre illimité de données vers ce compartiment.


De Verizon à la WWE en passant par le Pentagone lui-même, de plus en plus de services d’États, d'entreprises et de particuliers s'offrent des espaces de stockage disponibles en ligne sans appliquer les configurations de sécurité requises.


De par la nature du stockage, acceptant tout type de fichier, les Buckets peuvent contenir de la simple image, jusqu'au backup complet de bases de données.



Quelques exemples de fuites découvertes par HTTPCS :

Fuites Buckets Amazon

Légende : Amazon AWS Buckets publics non verrouillés en lecture contenant des informations sensibles.



Fuites Buckets Amazon

Légende : Amazon AWS Buckets publics non verrouillés en lecture contenant des informations sensibles.



Ceci en fait des cibles de choix pour tout hacker digne de ce nom.

Sachant cela, HTTPCS a mené une étude d'impact afin d'obtenir des résultats récents et concrets sur l'état des configurations des Buckets Amazon S3.



Les paramètres analysés lors de cette étude sont :


  • 1 - le Bucket est-il privé ou public ?
  • 2 - Lorsque le Bucket est public, contient-il des fichiers ?
  • 3 - Lorsqu'il contient des fichiers, peut-on les lire ?
  • 4 - Lorsque le Bucket est public, est-il possible d'écrire ?


La méthodologie :


  • 1 - Énumération des adresses *.s3.amazonaws.com : HTTP 404 = Bucket inexistant ; HTTP 403 = Bucket privé ; HTTP 200 = Bucket public.
  • 2 - Si la page contient la balise <Keys> alors le Bucket contient au moins un fichier.
  • 3 - Analyse des fichiers et tentative de lecture du premier fichier : si la page contient la string "<Code>Access Denied</Code>", alors le fichier n'est pas lisible. Dans le cas contraire, le fichier est lisible.
  • 4 - Tentative d'écriture puis lecture du fichier transmis.


Nous avons choisi cette méthodologie car elle prend en compte plusieurs facteurs qui semblent avoir été omis dans les précédentes études publiées, notamment le fait que le Bucket soit privé ou vide. Par ailleurs, l’énumération aléatoire d'adresses permet d'éviter d'avoir à utiliser les moteurs de recherche, qui recensent uniquement les Buckets publics.



Les résultats sur plus de 100 000 Buckets existants sont les suivants (pourcentages arrondis à l'unité) :

Étude HTTPCS Bucket Amazon

Légende : Schéma illustrant les résultats de l'étude menée par HTTPCS



Les conclusions que l'on peut tirer sont :


  • 90% des Buckets ne sont pas publics et donc sont à l’abri de fuites ou de corruptions de données ;
  • 58% des Buckets publics (soit 5.8% du total) contiennent des fichiers et ne sont pas verrouillés en lecture, ce qui permet la fuite de données ;
  • 20% des Buckets publics (soit 2.0% du total) ne sont pas verrouillés en écriture, ce qui peut mener à des attaques de corruption de données, de la propagation de malware, voire à des attaques type ransomware, comme on a pu voir sur les bases de données MongoDB mal configurées en 2017 ;
  • Uniquement 5% des Buckets non verrouillés en écriture (soit 0.1 % du total) ne contiennent aucun fichier, donc les possibilités d'attaques à grande échelle sont bien réelles.

A l'issue de cette étude, HTTPCS, leader européen en sécurité informatique, rend disponible son outil (intégré à la Console HTTPCS) afin de tester la sécurité de vos Buckets Amazon S3.

Tester gratuitement la console HTTPCS


HTTPCS Scanner screenshot desktop HTTPCS Scanner screenshot tablet HTTPCS Scanner screenshot phone