AWS a Introduit une Outil de Sécurité Qui a Créé un Risque de Sécurité Majeur Dans cette série de billets sur la politique de confiance, nous avons exploré plusieurs idées reçues dangereuses concernant la manière de configurer en toute sécurité l'accès inter-comptes dans les environnements AWS. Ce dernier article décrit un cas réel où AWS lui-même a commis une erreur, présentant ainsi un risque de sécurité majeur. Contexte de la Découverte Au cours d'une enquête sur un risque critique d'escalade de privilèges impliquant un rôle IAM dans l'environnement AWS d'un client, nous avons découvert un rôle identique présent dans leurs comptes de production et de gestion, chacun faisant confiance à deux rôles de leur compte de développement. Voici les détails du risque d'escalade de privilèges identifié (les informations sensibles ont été omises) : Ce rôle avait accès à plusieurs appels d'API sensibles liés à IAM et à des données, y compris : - iam:PassRole - ec2:RunInstances - s3:GetObject Ces permissions étaient accordées sur toutes les ressources (resource: "*") ce qui les rendait particulièrement dangereuses si elles étaient compromise. Le compte de développement de l'organisation ayant des contrôles de sécurité moins rigoureux, ce chemin de confiance représentait un risque majeur. Un attaquant compromise un rôle de confiance dans le compte de développement pourrait immédiatement obtenir ces permissions dans les comptes de production et de gestion. En combinaison avec d'autres mauvaises configurations (comme des rôles IAM exposés, des noms de secrets, des clés KMS ou des buckets S3 publics), cela pourrait faciliter la compromission des comptes les plus sensibles de l'organisation. L'Outil Account Assessment for AWS Organizations : Un Paradoxe Le nom original de ces rôles était inhabituel, suggérant qu'ils faisaient partie d'un système automatisé. Une recherche rapide nous a conduits à Account Assessment for AWS Organizations, un outil développé par AWS et publié dans la bibliothèque AWS Solutions. Cet outil est conçu pour « évaluer et gérer les comptes AWS au sein de votre organisation AWS », aidant les utilisateurs à mieux comprendre les dépendances de compte. AWS indique ses principaux cas d'utilisation comme les fusions et acquisitions, les audits de sécurité, l'exploration centralisée de stratégies et les transitions de comptes de gestion. L'outil utilise une architecture hub-and-spoke. Le rôle hub peut assumer les rôles spoke dans tous les comptes, agrégant ainsi les données de sécurité à travers l'organisation. Cependant, l'instruction officielle de déploiement contenait une recommandation problématique : - "Hub stack - Deploy to any member account in your AWS Organization except the Organizations management account." Cette recommandation, sans aucune clarification des implications de sécurité, poussait les organisations à déployer le rôle hub dans un compte moins sécurisé, souvent un compte de développement, de sandbox ou un autre compte à faible sensibilité. Pourquoi C'est un Risque Majeur Permettre à un rôle dans un compte moins sécurisé d'assumer des rôles dans des comptes plus sensibles crée un risque d'escalade de privilèges. Lorsqu'un attaquant compromet un rôle dans un compte moins sécurisé, il peut facilement pivoter vers des comptes plus sensibles comme ceux de production, de gestion et même d'environnements PCI-DSS. La structure hub-and-spoke de l'outil rendait cela possible car le compte hub avait un accès total aux rôles spoke de tous les comptes liés. Dans le cas étudié, le client a déployé le rôle hub dans son compte de développement, qui : - Had weaker security controls compared to production or management accounts. - Could assume roles across all accounts, including sensitive ones like management and production accounts. Ainsi, la compromission du compte de développement aurait permis à un attaquer de prendre le contrôle du compte de gestion, rendant la prise en charge de l'ensemble de l'organisation AWS beaucoup plus facile. Implications pour les Organisations Affectées Toute organisation ayant déployé cet outil suivant les instructions d'AWS avant le 28 janvier 2025, avec le rôle hub dans un compte moins sécurisé que le compte de gestion, est vulnérable. Pour ces organisations, le compte où le rôle hub est déployé devient une cible de valeur élevée. Si un attaquant compromet ce rôle, que ce soit par un accès direct ou une escalade de privilèges, il peut assumer les rôles spoke dans tous les comptes liés, y compris dans des environnements hautement sensibles. Une fois à l'intérieur, les attaques potentielles comprennent : - Accès non autorisé à des APIs sensibles. - Compromission de données. - Escalade de privilèges vers d'autres comptes. De plus, les noms de rôles prédéfinis de l'outil facilitent l'exploitation par les attaquant. Si un attaquant accède à n'importe quel compte AWS au sein d'une organisation affectée, il peut facilement identifier si l'outil est déployé et connaître les noms exacts des rôles qui peuvent être assumés via le compte hub. Détection et Correction Voici deux méthodes pour déterminer si votre organisation est affectée : 1. Si l'outil est déjà déployé : Vérifiez la date de création des rôles en examinant la propriété CreateDate. Si l'outil a été déployé avant le 28 janvier 2025, nous vous recommandons vivement d'enlever le déploiement actuel sauf si le rôle hub est déjà dans un compte à haute sécurité (comme un compte dédié DevOps ou Infrastructure). 2. Désinstaller l'outil : Supprimez les piles CloudFormation pour les composants Hub, Spoke et Org-Management. Consultez le guide officiel AWS pour les instructions de désinstallation. Si l'outil est toujours nécessaire, rédéployez-le en plaçant le rôle hub dans un compte ayant une sécurité équivalente à celle du compte de gestion pour prévenir les risques de escalade de privilèges. Rapport et Résolution Après avoir identifié cette issue, nous l'avons signalée au service de sécurité d'AWS, soulignant les risques graves créés par les instructions de déploiement. AWS a rapidement examiné nos conclusions, reconnu la préoccupation de sécurité et engagé des discussions avec nous pour déterminer comment mettre à jour la documentation afin d'éviter les futures mauvaises configurations. Sur la base de ces discussions, AWS a révisé la documentation pour conseiller explicitement aux clients de déployer le rôle hub dans un compte aussi sécurisé que les comptes scannés : - "Select a dedicated high-sensitivity account for the hub role." Nous remercions l'équipe de sécurité d'AWS, qui a été très réactive, ouverte aux retours et engagée à améliorer la sécurité des clients. Ils ont pris la question au sérieux dès le début, travaillé avec nous pour déterminer la meilleure mise à jour des documents, et apporté une correction claire et efficace. Chronologie du Signalement Découverte: Identification du risque lors d'une enquête sur une escalade de privilèges. Report to AWS: Remise du rapport au service de sécurité d'AWS. Acknowledgment: Reconnaissance du problème par AWS. Documentation Update: Révision de la documentation pour préciser le déploiement dans un compte sécurisé. Resolution: Publication de la nouvelle documentation. Conclusion Cette série de billets a examiné comment les risques liés aux politiques de confiance peuvent infiltrer même des environnements AWS bien gérés, que ce soit par des détails techniques négligés, des idées reçues subtiles ou même des outils officiels. La sécurité des relations de confiance repose moins sur le suivi d'une liste de vérification que sur une compréhension profonde de la façon dont ces mécanismes fonctionnent dans des environnements réels. Nous espérons que cette série a permis de mieux éclairer sur certains des défis cachés liés aux politiques de confiance. La plateforme de sécurité d'identité basée sur les machines de Token Security détecte ces risques de politiques de confiance, y compris les politiques inter-comptes de faible sécurité, que ces risques soient causés par des outils AWS, des erreurs humaines ou des configurations négligées. Pour en savoir plus sur la façon dont elle fonctionne, prenez rendez-vous pour une démonstration et découvrez comment nous aidons les organisations à anticiper ces risques. Évaluation de l'Événement par des Professionnels de l'Industrie et Profil de l'Entreprise La découverte de ce problème de sécurité a mis en lumière les défis persistants de la sécurité dans le cloud. Des experts de l'industrie ont salué l'approche responsable de Token Security dans la notification et la collaboration avec AWS pour corriger la vulnérabilité. Cette démarche contribue à une culture de sécurité proactive et collaborative, essentielle dans l'écosystème cloud. Token Security est une entreprise de sécurité technologique innovante, spécialisée dans la détection et la gestion des risques associés à l'identité et les accès dans les environnements cloud. Leur plateforme utilise des algorithmes avancés pour analyser et remédier aux configurations dangereuses avant qu'elles ne soient exploitées par des attaquants.