Des chercheurs en cybersécurité ont révélé une faille de sécurité affectant le kit de développement cloud (CDK) d’Amazon Web Services (AWS) qui aurait pu entraîner un piratage de compte dans des circonstances spécifiques.
« L’impact de ce problème pourrait, dans certains scénarios, permettre à un attaquant d’obtenir un accès administratif à un compte AWS cible, ce qui entraînerait une prise de contrôle complète du compte », a déclaré Aqua dans un communiqué. rapport partagé avec The Hacker News.
Suite à une divulgation responsable le 27 juin 2024, le problème a été résolu par les responsables du projet dans CDK version 2.149.0 sorti en juillet.
AWS CDK est un cadre de développement logiciel open source permettant de définir des ressources d’applications cloud à l’aide de Python, TypeScript ou JavaScript et de les provisionner via CloudFormation.
Le problème identifié par Aqua s’appuie sur des découvertes antérieures de la société de sécurité cloud concernant les ressources fantômes dans AWS et sur la manière dont les conventions de dénomination prédéfinies pour les compartiments AWS Simple Storage Service (S3) pourraient être utilisées pour orchestrer des attaques de Bucket Monopoly et accéder aux données sensibles.
La préparation d’un environnement AWS pour une utilisation avec AWS Cloud Development Kit (AWS CDK) est réalisée par un processus appelé bootstrapping, dans lequel certaines ressources AWS sont provisionnées dans l’environnement. Cela inclut un compartiment AWS S3, un référentiel Amazon Elastic Container Registry (Amazon ECR) et des rôles AWS Identity and Access Management (IAM).
« Les ressources et leur configuration utilisées par le CDK sont définies dans un modèle AWS CloudFormation », selon Documentation AWS.
« Pour amorcer un environnement, vous utilisez la commande cdk bootstrap de l’interface de ligne de commande AWS CDK (AWS CDK CLI). La CLI CDK récupère le modèle et le déploie sur AWS CloudFormation en tant que pile, appelée pile d’amorçage. Par défaut, la pile le nom est CDKToolkit. »
Certains des Rôles IAM créé dans le cadre du processus d’amorçage, accorde l’autorisation de télécharger et de supprimer des actifs du compartiment S3 associé, ainsi que d’effectuer des déploiements de pile avec un accès administrateur.
Aqua a déclaré que le modèle de dénomination des rôles IAM créés par AWS CDK suit la structure « cdk-{Qualifier}-{Description}-{Account-ID}-{Region} », où chacun des champs est expliqué ci-dessous :
- Qualificateur, une valeur de chaîne unique de neuf caractères dont la valeur par défaut est « hnb659fds », bien qu’elle puisse être personnalisée pendant la phase d’amorçage
- Description, description de la ressource (par exemple, cfn-exec-role)
- ID de compte, ID de compte AWS de l’environnement
- Région, région AWS de l’environnement
Dans le même ordre d’idées, le compartiment S3 créé lors de l’amorçage suit le modèle de dénomination « cdk-{Qualifier}-assets-{Account-ID}-{Region} ».
« Étant donné que de nombreux utilisateurs exécutent la commande cdk bootstrap sans personnaliser le qualificatif, le modèle de dénomination du compartiment S3 du compartiment intermédiaire devient prévisible », a déclaré Aqua. « En effet, la valeur par défaut du qualificatif du nom du compartiment est définie sur « hnb659fds », ce qui facilite l’anticipation du nom du compartiment.
Avec des milliers de cas découvert sur GitHub où le qualificatif par défaut est utilisé, cela signifie également que deviner le nom du compartiment est aussi simple que de trouver l’ID de compte AWS et la région dans laquelle le CDK est déployé.
En combinant cet aspect avec le fait que les noms de compartiments S3 sont globalement uniques sur tous les comptes AWS, cette faille ouvre la porte à ce qu’on appelle Squatting de noms de compartiment S3 (ou Bucket Sniping), permettant à un attaquant de revendiquer le bucket CDK d’un autre utilisateur s’il n’existe pas déjà.
Cela pourrait alors ouvrir la voie à un déni de service partiel (DoS) lorsqu’un utilisateur tente d’amorcer le CDK avec le même ID de compte et la même région, un scénario qui pourrait être résolu en spécifiant un qualificatif personnalisé lors de l’amorçage.
Une conséquence plus grave pourrait survenir si le CDK de la victime est autorisé à lire et à écrire des données depuis et vers le compartiment S3 contrôlé par l’attaquant, permettant ainsi de falsifier les modèles CloudFormation et d’exécuter des actions malveillantes au sein du compte AWS de la victime.
« Le rôle de déploiement du service CloudFormation, qui est le rôle CloudFormationExecutionRole dans CDK, dispose par défaut de privilèges administratifs au sein du compte », a souligné Aqua.
« Cela signifie que tout modèle CloudFormation écrit dans le compartiment S3 de l’attaquant par le CDK de la victime serait déployé ultérieurement avec des privilèges administratifs sur le compte de la victime. Cela permettrait à l’attaquant de créer des ressources privilégiées. »
Dans une attaque hypothétique, si un utilisateur avait lancé le processus d’amorçage CDK dans le passé et avait ensuite supprimé le compartiment S3 en raison des limites de quota, un adversaire pourrait profiter de la situation pour créer un compartiment portant le même nom.
Cela pourrait alors amener le CDK à faire implicitement confiance au compartiment non fiable et à y lire/écrire des modèles CloudFormation, les rendant ainsi susceptibles d’être exploités. Cependant, pour que cela réussisse, l’attaquant doit remplir les conditions préalables ci-dessous :
Réclamez le compartiment avec le nom prévisible et autorisez l’accès public
Créez une fonction Lambda qui injectera un rôle d’administrateur malveillant ou une porte dérobée dans un fichier de modèle CloudFormation donné chaque fois qu’il sera téléchargé dans le compartiment.
Dans la dernière étape, lorsque l’utilisateur déploie le CDK à l’aide de « cdk déployer », non seulement le processus envoie le modèle au compartiment de réplication, mais injecte également un rôle d’administrateur que l’attaquant peut assumer pour finalement prendre le contrôle du compte de la victime.
En d’autres termes, la chaîne d’attaque facilite la création d’un rôle d’administrateur dans un compte AWS cible lorsqu’un compartiment CDK S3 configuré lors du processus d’amorçage est supprimé et que le CDK est à nouveau utilisé. AWS a depuis confirmé qu’environ 1 % des utilisateurs de CDK étaient vulnérables au vecteur d’attaque.
Le correctif mis en place par AWS garantit que les actifs sont uniquement téléchargés dans des compartiments au sein du compte de l’utilisateur afin d’empêcher le CDK de transmettre des données vers des compartiments n’appartenant pas au compte qui a lancé l’amorçage. Il a aussi clients invités pour utiliser un qualificatif sur mesure au lieu du « hnb659fds » par défaut.
Cela dit, une action de l’utilisateur est requise si l’amorçage a été effectué à l’aide de la version CDK v2.148.1 ou antérieure, ce qui nécessite qu’il mette à jour le CDK vers la dernière version et réexécute la commande d’amorçage. Les utilisateurs ont également la possibilité d’appliquer une condition de stratégie IAM au rôle FilePublishingRole CDK.
Les résultats appellent une fois de plus à garder secrets les identifiants de compte AWS, à définir une politique IAM étendue et à éviter de donner des noms prévisibles aux compartiments S3.
« Au lieu de cela, générez des hachages uniques ou des identifiants aléatoires par région et par compte, et intégrez-les dans les noms de vos compartiments S3 », a conclu Aqua. « Cette stratégie permet de vous protéger contre les attaquants qui s’approprient votre compartiment de manière préventive. »
La divulgation intervient alors que Symantec, propriété de Broadcom, a découvert plusieurs applications Android et iOS contenant des informations d’identification de service cloud codées en dur et non chiffrées pour AWS et Microsoft Azure Blob Storage, mettant ainsi données utilisateur en danger.
Certaines des applications incriminées incluent Pic Stitch : Collage Maker, Crumbl, Eureka : Earn Money for Surveys, Videoshop – Video Editor, Meru Cabs, Sulekha Business et ReSound Tinnitus Relief.
« Cette pratique dangereuse signifie que toute personne ayant accès au code binaire ou source de l’application pourrait potentiellement extraire ces informations d’identification et les utiliser à mauvais escient pour manipuler ou exfiltrer des données, entraînant de graves failles de sécurité », ont déclaré les chercheurs en sécurité Yuanjing Guo et Tommy Dong. dit.