Fuites AWS très médiatisées et comment les éviter

Quelques jours avant Noël 2021, les employés et les clients de Flexbooker, un service de prise de rendez-vous, ont découvert que des acteurs malveillants avaient dérobé dix millions de lignes de données d’identification client, notamment des photos, des permis de conduire et des mots de passe hachés.

Les attaquants ont dérobé des millions de données à caractère personnel (PII) parce que Flexbooker avait mal configuré son compte AWS, plus précisément un compartiment AWS S3 dont le contenu était accessible au public. Cette fuite AWS a fait la une, mais pas parce qu’elle était inédite. Capital One, Twilio, Uber et d’autres ont également été victimes de fuites liées à AWS. Dans ces cas, les attaquants n’avaient pas compromis AWS lui-même, mais une entreprise en exploitant une mauvaise configuration AWS.

Malgré l’ampleur de ces fuites, la cause des problèmes de sécurité du cloud est généralement la même : les mauvaises configurations. La sécurité du cloud repose sur un modèle de responsabilité partagée : le fournisseur sécurise l’infrastructure, mais il revient au client de déployer ses applications de manière sécurisée dans tous les environnements, pas seulement en production. Dans la plupart des cas, de simples erreurs de configuration des applications ou services déployés créent des failles suffisamment importantes pour permettre une fuite.

Dans cet article, nous allons présenter quelques fuites AWS très médiatisées survenues ces dernières années à cause de mauvaises configurations, et voir comment vous pouvez prévenir les fuites grâce à de meilleures pratiques de sécurité.

Capital One : un pare-feu mal configuré touche 100 millions de clients

En juillet 2019, la grande banque et société de services financiers Capital One a révélé qu’un ancien employé d’Amazon avait piraté ses serveurs AWS.

Le piratage a touché plus de 100 millions de clients et exposé des données personnelles telles que les numéros de sécurité sociale, les numéros de compte bancaire, les scores de crédit, etc. Amazon a clairement indiqué qu’AWS n’était pas en cause et que les services cloud sous-jacents n’avaient pas été compromis. Comme l’a reconnu Capital One, le pirate a plutôt obtenu l’accès par l’intermédiaire d’un pare-feu d’application Web (WAF) open source mal configuré.

Des clients ont intenté une action collective en justice, que Capital One a réglée en accordant jusqu’à 25 000 $ par demande. Les plaignants ont affirmé que Capital One « connaissait les vulnérabilités de sécurité particulières qui ont permis la fuite de données », mais ne les avait pas corrigées. Capital One n’a ni reconnu ni contesté ces allégations, déclarant plutôt qu’elle réglerait l’affaire « afin d’éviter les délais, les frais et l’incertitude d’une procédure judiciaire prolongée ».

Pegasus Airlines : un compartiment S3 non protégé expose 6,5 téraoctets de données

En mai 2022, la compagnie aérienne turque Pegasus Airlines a découvert, grâce au travail d’une société de sécurité, qu’elle avait mal configuré un compartiment AWS S3. Celui-ci contenait des données de vol sensibles, notamment des cartes de vol, des documents de navigation et les données personnelles de nombreux employés.

Le compartiment S3 ouvert a également révélé une partie du code source de l’entreprise, qui contenait des mots de passe en texte brut et des clés secrètes. Des attaquants potentiels auraient pu s’en servir pour accéder à des données encore plus sensibles.

Au total, la société de sécurité a découvert près de 23 millions de fichiers exposés, soit environ 6,5 téraoctets de données. Elle a indiqué que « cette exposition pourrait avoir des conséquences sur la sécurité de chaque passager et membre d’équipage de Pegasus dans le monde entier ».

La société de sécurité a averti Pegasus Airlines et, selon elle, « le compartiment AWS S3 a été rapidement sécurisé et PegasusEFB nous a ensuite répondu pour nous remercier de l’avoir informée ».

Twilio : un compartiment S3 exposé permet aux attaquants d’injecter du code malveillant

En juillet 2020, Twilio, une entreprise de communications cloud, a confirmé que des attaquants avaient accédé à un compartiment S3 mal configuré et modifié le SDK JavaScript de son outil TaskRouter.

Les attaquants ont exploité une mauvaise configuration du compartiment S3 qui hébergeait la bibliothèque du SDK JS TaskRouter de Twilio (TaskRouter est un outil permettant aux clients de Twilio d’acheminer des tâches). Après l’attaque, la bibliothèque modifiée faisait charger aux navigateurs une URL supplémentaire, que l’on a ensuite associée aux tristement célèbres attaques Magecart.

Dans un communiqué, Twilio a expliqué avoir corrigé le problème en quinze minutes et reconfiguré le compartiment S3 une heure plus tard. Twilio a également précisé que les attaquants n’avaient eu accès ni aux données des clients ni aux systèmes internes.

Twilio a fait preuve de transparence en expliquant : « Nous n’avions pas correctement configuré la politique d’accès de l’un de nos compartiments AWS S3. » Twilio avait mis en place cette configuration en 2015 et, à l’époque, elle ne présentait aucune vulnérabilité. Mais quelques mois plus tard, après avoir résolu un problème, l’entreprise n’a pas « correctement réinitialisé » les autorisations.

Uber : une authentification faible révèle des clés secrètes qui donnent aux pirates accès à des entrepôts de données AWS S3 contenant les dossiers de 600 000 conducteurs américains

En novembre 2017, Uber, une entreprise de covoiturage, a révélé qu’en 2016, des attaquants avaient dérobé les données personnelles de plus de 50 millions de passagers et de conducteurs, ainsi que les dossiers de 600 000 conducteurs américains, avec leurs numéros de permis de conduire.

Les attaquants ont pu accéder au dépôt GitHub d’Uber parce que l’entreprise n’avait pas activé l’authentification multifacteur. Malgré ce manque de sécurité, ces dépôts contenaient des identifiants AWS importants, qui ont permis aux attaquants d’accéder aux entrepôts de données AWS S3 d’Uber.

Uber a expliqué avoir sécurisé les données, mis fin aux accès non autorisés, convaincu les attaquants de supprimer les données et renforcé les contrôles de ses comptes de stockage cloud. Cependant, des articles publiés par la suite ont révélé qu’Uber avait déguisé le piratage initial en programme de chasse aux bogues réussi et versé 100 000 $ aux attaquants pour qu’ils gardent le silence.

Imperva : une clé d’API AWS exposée permet aux attaquants d’accéder à une base de données contenant les adresses e-mail et les mots de passe des clients

En octobre 2019, le fournisseur de cybersécurité Imperva a révélé que des attaquants avaient dérobé des données clients en exploitant une instance AWS mal configurée.

Le PDG d’Imperva a expliqué que les attaquants avaient utilisé une clé d’API administrative trouvée dans l’un des comptes AWS de l’entreprise pour accéder à un instantané de base de données contenant des adresses e-mail et des mots de passe.

Imperva a fait preuve de transparence concernant les erreurs à l’origine de la fuite de sécurité AWS et a expliqué que quatre étapes principales avaient conduit à l’exposition des données clients :

1. Imperva a créé un instantané de base de données à des fins de test pendant son évaluation d’AWS.

2. Imperva a rendu accessible au public une instance de calcul interne, alors qu’elle contenait une clé d’API AWS.

3. Les attaquants ont compromis l’instance de calcul et dérobé la clé d’API AWS.

4. Les attaquants ont utilisé la clé d’API AWS pour accéder à l’instantané de base de données et à toutes les données qu’il contenait.

Depuis, l’entreprise a pris de nombreuses mesures correctives, notamment en renforçant les contrôles d’accès et en mettant en place des audits d’accès.

Trois leçons à retenir des fuites de données AWS

Voici quelques leçons à tirer de ces fuites AWS pour renforcer la sécurité de l’utilisation d’AWS par votre entreprise :

1. Connaissez votre environnement : De nombreuses fuites AWS sont dues à des erreurs de configuration. Plus vous connaissez et auditez votre environnement, moins les attaquants auront de chances d’exploiter une mauvaise configuration.

2. Donnez les moyens d’agir à vos développeurs : Les développeurs sont les mieux placés pour détecter et corriger les erreurs de configuration. Les entreprises peuvent mieux prévenir les fuites AWS si elles donnent aux développeurs les outils et les conseils nécessaires pour créer des environnements sécurisés.

3. Misez sur la prévention et la conception sécurisée : Nombre de ces fuites AWS auraient pu être évitées si les entreprises concernées avaient davantage misé sur une conception sécurisée. Grâce à des outils comme l’analyse des vulnérabilités AWS de Snyk, les entreprises peuvent repérer les vulnérabilités avant les attaquants. Découvrez ici comment Snyk s’intègre aux outils de sécurité AWS.

Pour en savoir plus sur la sécurité du cloud, téléchargez notre e-book « Les cinq fondamentaux de la sécurité du cloud ». Et si vous souhaitez en savoir plus sur l’intégration de Snyk et AWS, consultez le guide de démarrage rapide AWS.