Introduction
En 2017, un partenaire de Verizon Wireless a involontairement mal configuré les contrôles d'accès à un service Amazon S3, exposant ainsi environ 6 millions d'enregistrements contenant des noms de clients, des informations de contact, des adresses personnelles, des données financières de compte, et même des pins de compte. Verizon a été informée en privé de l'exposition le 13 juin 2017, et la mauvaise configuration a été corrigée le 22. Tant que le service est resté mal configuré, toute personne disposant d'une connexion Internet pouvait facilement consulter une partie ou la totalité de ces données.
À l'ère de l'adoption massive des solutions de stockage en nuage, nous constatons malheureusement trop souvent des expositions de ce type. Les services en nuage semblent simples à configurer, mais une petite erreur peut exposer des ensembles entiers de données sur l'internet public. Il se peut que vous gériez de nombreux espaces de stockage avec différents niveaux d'accès pour un usage interne et externe, et il peut rapidement devenir difficile de gérer vos configurations. Les expositions au stockage en nuage sont particulièrement problématiques, car il est facile pour un pirate d'accéder à des données ou de les modifier alors qu'un espace de stockage reste mal configuré. Le ministère américain de la défense, Dow Jones & Co et Booz Allen Hamilton ont déjà été victimes de violations très médiatisées de buckets S3 et d'autres actifs de stockage en nuage.
Ce blog explore comment une mauvaise configuration d'un seau S3 peut conduire à une violation à travers une analyse étape par étape :
- Création d'un nouveau panier de stockage Amazon S3
- Configuration de la liste de contrôle d'accès (ACL) pour ce seau Amazon S3
- Vecteurs d'attaque courants pour accéder aux données une fois que les autorisations du seau sont configurées
- Comment vérifier l'exposition involontaire potentielle des buckets Amazon S3 à l'aide de la plateforme Censys ASM ?
Analyse
Pour illustrer la complexité de la configuration de l'accès au stockage en nuage, prenons l'exemple du groupe d'accès "Authenticated User" d'Amazon pour les buckets. Cela ne semble pas si effrayant à première vue, n'est-ce pas ? Cependant, dans la nomenclature d'Amazon, un "utilisateur authentifié" est toute personne disposant au moins d'un compte AWS de niveau gratuit. En d'autres termes, si votre panier S3 est configuré avec un accès au groupe "Authenticated User", toute personne prête à s'inscrire à un compte AWS a un accès total à vos données. Des cas documentés d 'exposition à grande échelle se sont produits lorsqu'un praticien a mal configuré un godet de stockage en utilisant ce groupe d'accès.
Pour illustrer la manière dont un attaquant peut compromettre et exfiltrer des données à partir d'un bac de stockage, nous allons voir un exemple à l'aide de l'outil CLI d'AWS.
En utilisant un compte privé, nous allons créer un nouveau seau de stockage.
Il est maintenant temps de configurer la politique ACL pour ce seau. Nous allons donner au groupe des utilisateurs authentifiés un accès en lecture, car nous voulons que nos collègues puissent consulter tous les documents stockés dans le seau.
Une fois notre bucket créé, il est temps de télécharger des données. `ohno.txt` est le fichier que nous voulons que nos collègues ayant un compte AWS puissent lire.
Imaginons que quelques semaines se soient écoulées et que notre équipe interne ait utilisé ce seau avec succès.
Malheureusement, un attaquant a découvert que notre société utilise `my-exposed-bucket` comme nom de projet, et veut en tirer parti pour découvrir des données potentiellement exposées dans notre panier de stockage. Il note que le fait d'appuyer sur `https://my-exposed-bucket.s3.us-east-2.amazonaws.com/` dans son navigateur renvoie un code d'erreur `AccessDenied`, l'informant qu'un panier de stockage existe sous ce nom.
L'attaquant sait maintenant qu'il peut potentiellement voir ces informations. Il configure son outil personnel AWS CLI, et essaye de lister le bucket en utilisant la commande `ls`. Il découvre que le bucket est exposé, et qu'il contient un fichier `txt` nommé `ohno`.
Pour accéder aux données exposées, l'attaquant utilise la commande `cp` pour copier le contenu dans un répertoire de sa machine personnelle. Ici, nous copions `ohno.txt` dans `./Desktop`.
Les informations contenues dans le seau se trouvent maintenant sur la machine personnelle de l'attaquant. Heureusement, le contenu de notre document exposé est bénin !
De tous les buckets de stockage gérés par Censys ASM, ~8,5 % sont exposés comme étant publiquement lisibles, inscriptibles ou avec des paramètres de configuration modifiables. Pour l'ensemble de vos fournisseurs de stockage en nuage, cela peut représenter une part importante de vos espaces de stockage mal configurés et peut conduire à des attaques telles que celles illustrées ci-dessus.
Que puis-je faire ?
La bonne nouvelle, c'est qu'il est possible de résoudre le problème de la mauvaise configuration des seaux. En mettant en œuvre les meilleures pratiques au sein de votre équipe et en introduisant des solutions automatisées pour découvrir les risques, vous pouvez mieux vous protéger.
- Veillez à ce que vos services de stockage en nuage soient dotés de politiques IAM appropriées.
- Créez et communiquez des politiques de sécurité solides au sein de votre équipe. Le NIST fournit des directives de sécurité complètes pour les infrastructures de stockage.
- Envisagez la mise en œuvre d'une solution ASM automatisée pour identifier les mauvaises configurations du stockage en nuage. Censys est le seul fournisseur d'ASM qui identifie les risques associés aux unités de stockage que vous possédez et qui exploite automatiquement vos données pour découvrir les unités de stockage inconnues susceptibles d'avoir un impact sur votre posture de sécurité.
- Les clients actuels de Censys ASM peuvent se rendre sur la page de la liste des godets de stockage pour consulter une liste actualisée de leurs godets de stockage et de tous les risques qui y sont associés. Vous n'êtes pas client de Censys ASM ? Prenez contact avec nous via la page de contact deCensys !
--
