👆🏾 🤰🏻 📃 Pourquoi les nuages deviennent des nuages d'orage: les échecs de déploiement du cloud 🌁 🕞 💆🏿

Une implémentation cloud dans une grande organisation comprend généralement de nombreux services de différents fournisseurs, chacun ayant ses propres règles d'interaction, de paramètres et même de protocoles. En conséquence, la configuration de la sécurité devient si complexe qu'elle est difficile à suivre et encore plus difficile à comprendre. Dans notre nouvelle étude, nous avons collecté les erreurs les plus courantes dans le déploiement d'une infrastructure cloud à l' aide d'Amazon Web Services à titre d'exemple, et nous en partagerons certaines dans cet article.

Les fournisseurs de cloud offrent aujourd'hui des services qui vont au-delà de la «dédicace» triviale ou du stockage de fichiers. Chaque aspect de chaque service peut être programmé. Cela donne aux développeurs et aux opérateurs plus de contrôle sur la sécurité qu'un centre de données traditionnel. Cependant, la richesse des fonctions et de leurs outils de configuration conduit au fait que vous pouvez configurer à partir de plusieurs interfaces, et - et c'est important - les paramètres par défaut sont différents pour différentes méthodes.

Pour les utilisateurs expérimentés, ce n'est pas un problème - au contraire, ils utiliseront l'outil le plus approprié pour la tâche. Cependant, pour d'autres, le résultat peut ne pas être à la hauteur de leurs attentes.

Stockage Amazon S3

Amazon Simple Storage Services ou Amazon S3 est l'un des services cloud les plus recherchés par de nombreux clients, des petites entreprises aux grandes entreprises. La popularité a fait de S3 une cible préférée des attaquants qui recherchent des failles dans la mise en œuvre des services et des erreurs dans leur configuration.

Les vecteurs d'attaque Amazon S3 les plus courants utilisés par les cybercriminels sont:

des installations de stockage public pour l'enregistrement;
interception de comptes;
abus de privilèges.

Partage d'enregistrement

En février 2018, le mineur de crypto-monnaie Monero a été découvert sur le site de l'un des plus grands journaux américains. Chaque lecteur qui a visité le site a extrait des pièces pour des criminels qui ont ajouté du code malveillant aux fichiers JavaScript de la publication.

Le site du journal était hébergé par Amazon et stockait toutes les images, scripts et fichiers de style dans le référentiel S3. L'accès à ce référentiel n'était limité que par la lecture, donc le piratage était une surprise complète pour les administrateurs de site. Ils ne pouvaient tout simplement pas comprendre comment ils étaient piratés jusqu'à ce que les spécialistes des services cloud expliquent que la raison en était les droits d'accès incorrects.

Les référentiels Amazon S3 peuvent être utilisés via http / https, et dans cette partie, les administrateurs du site ont tout fait correctement, restreignant l'accès uniquement à la lecture. Cependant, S3 est également accessible via le protocole natif AWS via la ligne de commande, et les droits d'accès pour de tels appels doivent être définis séparément, et par défaut, l'accès au stockage via AWS CLI est autorisé pour tous les utilisateurs autorisés AWS.

Le résultat de l'exécution de la commande de la console aws s3api get-bucket-acl --bucket <BUCKET_NAME> pour le coffre-fort par défaut

pour les nouveaux utilisateurs d'Amazon S3, la nécessité de double-restreindre leurs autorisations de coffre-fort est loin d'être évident, ce qui a conduit à de nombreux incidents.

Fin 2018, AWS a redéfini la politique de sécurité en interdisant l'accès public à partir de la console pour les nouveaux référentiels S3, mais cette politique n'a pas été appliquée lors de l'utilisation de la ligne de commande. L'accès devait encore être limité à une équipe distincte.

En 2018-2019, le compromis du stockage S3 s'est généralisé. Certains professionnels de la sécurité et des pirates informatiques sympathiques ont spécifiquement recherché des ressources AWS ouvertes pour l'écriture et y ont laissé des fichiers d'avertissement.

Avertissement anonyme concernant une configuration non sécurisée d'AWS S3

Quelqu'un a même proposé ses services pour configurer des paramètres de stockage sécurisé:

avertissement et offre de services de Pentester Random Robbie

Random Robbie est le pseudonyme de Robbie Wiggins pentester, qui en 2018 a laissé son avertissement sur les milliers de stockage S3 ouverts pour l'enregistrement.

Les hackers ont immédiatement profité de la possibilité de modifier librement les sites hébergés dans les référentiels S3. Le groupe Magecart a massivement introduit un code malveillant pour voler les données de carte bancaire et les informations de compte utilisateur. Après tout, il suffisait de trouver un site acceptant les paiements et utilisant AWS. En conséquence, les criminels ont réussi à voler les données de centaines de milliers de visiteurs de ces ressources.

Exemple de données qu'un skimmer a transmises à des criminels

Parmi les victimes des actions de Magecart figurent des centaines de boutiques en ligne, dont des marques bien connues.

Au cours de l'étude, nous avons constaté que, malgré les nombreuses publications et recommandations concernant la configuration sécurisée des services AWS, au moins cinq magasins en ligne sur le nombre de magasins compromis continuent d'utiliser les magasins S3 disponibles pour l'enregistrement. À ce jour, leurs sites ne contiennent pas d'écrémeurs, mais ils peuvent être ajoutés à tout moment, car les cybercriminels disposent d'outils pratiques pour faciliter la recherche de ressources vulnérables.

Outils de recherche de stockage ouvert S3

Les outils Slurp, Bucket Stream et s3scanner vous aident à trouver un stockage lisible et inscriptible.

Slurp vous aide à trouver des noms de stockage possibles pour un domaine donné et à vérifier les autorisations d'écriture en eux:

exemple de sortie Slurp. L'accès par http est fermé.

Pour vérifier la disponibilité du stockage trouvé via l'AWS CLI, vous pouvez utiliser la commande get-bucket-acl:

L'accès à la ressource via l'API AWS est également fermé.

L'utilitaire s3scanner écrit en Python utilise une heuristique simple pour trouver les noms de stockage possibles et vérifie leur accès.

Rechercher et vérifier la disponibilité du stockage S3 à l'aide de s3scanner

L'utilitaire Bucket Stream recherche les magasins S3 potentiellement vulnérables dans les sources publiques, par exemple, dans la transparence des certificats et autres.

L'utilitaire AWSBucketDump répertorie les fichiers de référentiel dont les noms contiennent des mots clés spécifiques:

Résultat de l'utilitaire AWSBucketDump

En utilisant ces utilitaires, de décembre 2018 à janvier 2019, nous avons trouvé plus de 5200 stockages S3 uniques. Environ 4 400 d'entre eux étaient disponibles pour les utilitaires de ligne de commande AWS standard. Seulement 79 d'entre eux étaient disponibles pour la lecture et 40 pour l'écriture. Pour accéder à une partie d'entre eux, il fallait simplement céder les droits nécessaires.

Comment les comptes fuient

Les droits d'accès aux ressources sont une source de maux de tête pour les développeurs. Et dans le cas des fonds cloud, le problème devient encore plus aigu. Les processus doivent être authentifiés afin d'accéder aux ressources, sinon il existe un risque de vol ou de compromission des données. Toute la question est de savoir comment le faire sans risquer de compromettre les données lors de la publication du code dans le référentiel, comme l'a fait l'auteur du fragment suivant publié sur Pastebin:

Un fragment du code publié sur Pastebin avec un ID et une clé API AWS valides

En utilisant ces données, l'attaquant peut obtenir tous les droits qui sont fournis par le compte de cette application.

Une autre source de fuites d'informations d'identification est les certificats clients de l'API Kubernetes. D'une part, dans la configuration par défaut, ce système d'orchestration de conteneurs nécessite une protection obligatoire sous la forme d'un certificat client. D'un autre côté, les développeurs avec une naïveté surprenante publient des certificats avec du code sur GitHub, Pastebin et d'autres services.

Ce n'est qu'à Pastebin que nous avons réussi à trouver une cinquantaine de certificats clients différents placés avec des scripts de configuration.

Si publier des certificats en texte clair n'importe où est une mauvaise idée, le publier sur GitHub est tout simplement dégoûtant, car:

Pour supprimer un certificat, vous devez le supprimer de toutes les versions enregistrées dans le référentiel;
- , , ;
, , , .

Les clés et certificats API compromis peuvent devenir une source de graves dommages financiers, comme une entreprise russe devait 12000 $ à Amazon pour une journée : elle a piraté un site Web sur Bitrix, qui, entre autres, indiquait une clé API pour accéder au stockage S3.

Capture d'écran du panneau de facturation d'une entreprise russe, dont la clé API volée a été utilisée pour créer de nombreuses machines virtuelles et l'extraction de crypto-monnaie. Source: habr.com/en/post/357764

La fuite des données clients peut devenir non moins douloureuse, comme chez Imperva en 2019 . Imperva a également volé la clé API et fusionné toutes les données client.

Les comptes volés peuvent être utilisés par des cybercriminels pour échanger illégalement des serveurs AWS dédiés, qui devront être payés par les vrais propriétaires. Sur le forum lolzteam, nous avons trouvé plus de 250 annonces proposant des «Dédicos zéro pur».

Annonce sur le forum lolzteam. Qui paiera Amazon à la fin?

Une troisième source de fuites de clés API est une variété de cours de formation pour les programmeurs.

En essayant d'expliquer le processus de connexion aux services AWS aux débutants aussi simplement que possible, les auteurs reproduisent les mauvaises pratiques, ce qui conduira à l'avenir à de nouveaux et nouveaux cas de compromis.

Un extrait d'un cours Python qui explique comment travailler avec les services Amazon S3. Des clés sont proposées pour coder en dur dans le programme

Les auteurs du cours sur le langage Java progressif et sûr démontrent une attitude si négligente envers la sécurité des clés API: le

langage est différent, mais les conseils sont les mêmes - les clés sont à droite dans le texte du programme.

Nos recommandations

Une configuration incorrecte des services cloud présente de nombreux risques liés à l'utilisation illégale de ressources informatiques louées pour l'extraction de crypto-monnaie, au vol de données et à l'introduction d'écumeurs en ligne. À cet égard, nous recommandons que le personnel de sécurité analyse les scénarios de déploiement du cloud pour identifier les vulnérabilités potentielles avant la fin du processus. Les scripts de validation cloud comme AWS CloudFormation fournissent un aperçu du fonctionnement de l'infrastructure résultante, où rechercher les paramètres de sécurité ou les journaux incorrects ou manquants. Parmi les outils de sécurité développés par Trend Micro, il existe un produit destiné à protéger les environnements cloud - Deep Security pour les instances Amazon EC2.Et l'outil de conformité du cloud permet à l'environnement cloud de l'entreprise pour les paramètres non sécurisés.

Pour les programmeurs utilisant des clés d'API AWS pour interagir avec les référentiels S3, nous suggérons de passer au travail via AWS Secrets Manager, Docker Secrets, Blackbox, git-secrets et d'autres outils similaires qui permettront d'éviter de compromettre et d'utiliser de manière malveillante les informations d'identification stockées avec l'original textes d'application.

Pourquoi les nuages ​​deviennent des nuages ​​d'orage: les échecs de déploiement du cloud

Stockage Amazon S3

Partage d'enregistrement

Outils de recherche de stockage ouvert S3

Comment les comptes fuient

Nos recommandations

More articles:

Pourquoi les nuages deviennent des nuages d'orage: les échecs de déploiement du cloud