Etude d’impact – Configuration AWS Buckets Amazon S3
De nos jours, les fuites de données sont de plus en plus présentes dans les médias… Une mauvaise configuration de vos Buckets Amazon S3 peut avoir de gros impacts tels que des attaques de corruption de données, des propagation de malwares, voire des attaques de type ransomware ! Grâce à HTTPCS , il est possible de tester la sécurité de vos Buckets Amazon S3.
Depuis plusieurs mois maintenant, les médias relatent des fuites de données liées à des AWS 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.
Tester gratuitement la console HTTPCS
Quelques exemples de fuites découvertes par HTTPCS :
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é):
Les conclusions d’HTTPCS sur AWS Buckets Amazon S3
- 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.
