Comment trouver l’identifiant de compte AWS d’un bucket S3

Trouver l’identifiant de compte AWS d’un bucket S3

• En 2021, Ben Bridts a présenté une méthode originale pour trouver l’identifiant de compte AWS d’un bucket S3 public.
• Cet article explique une technique permettant de trouver l’identifiant de compte pour des buckets S3 privés comme publics.

D’un bucket S3 à un identifiant de compte AWS

• Présentation d’une technique, à partir d’une sortie shell, pour découvrir l’identifiant de compte AWS auparavant inconnu d’un bucket nommé bucket-alpha.

Comment cette technique fonctionne-t-elle exactement ?

• L’article analyse pourquoi la technique de Ben fonctionne en combinant trois éléments clés :
  • la capacité d’appliquer des politiques IAM aux requêtes
  • la capacité de déduire si une politique IAM a autorisé une requête ou non
  • la capacité d’appliquer une correspondance par wildcard à la clé de condition s3:ResourceAccount

La solution

• Une solution a été trouvée en utilisant un endpoint VPC pour S3 et en exploitant la différence de comportement dans CloudTrail lorsque les requêtes sont refusées.

Étape par étape

• Procédure détaillée lorsqu’on cherche à trouver l’identifiant de compte du bucket bucket-alpha :
  • déterminer la région du bucket
  • déployer un VPC et un endpoint VPC dans la même région
  • lancer une instance EC2 dans le VPC et vérifier l’utilisation de l’endpoint VPC pour S3
  • modifier la politique de l’endpoint VPC pour déterminer si l’identifiant de compte du bucket cible commence par « 0 »
  • envoyer une requête au bucket cible
  • vérifier si la requête apparaît dans CloudTrail
  • en fonction du résultat, modifier la politique de l’endpoint VPC pour découvrir davantage d’informations sur l’identifiant de compte

Résultats

• Un script a été écrit pour automatiser ce processus et retrouver de manière fiable l’identifiant de compte d’un bucket.
• Une recherche binaire est effectuée pour chaque chiffre afin de réduire le nombre de tests nécessaires.

Accélération

• La politique de l’endpoint VPC a été ajustée pour réduire le temps nécessaire à sa prise d’effet ainsi que l’attente individuelle des résultats dans CloudTrail.
• Cela permet de ramener le temps nécessaire pour trouver l’identifiant de compte à moins de 10 minutes.

Avis

• Ce billet de blog a été publié après échange avec l’équipe sécurité d’AWS.
• Une discussion intéressante a eu lieu sur la question de savoir si les identifiants de compte AWS doivent être considérés comme des informations sensibles.
• Cette technique pourrait s’appliquer à d’autres services que S3.
• Ces techniques sont possibles parce qu’il est possible d’utiliser une condition StringLike pour s3:ResourceAccount.
• Il pourrait être utile que les événements refusés par les politiques d’endpoint VPC soient journalisés dans CloudTrail.

Remerciements

• La technique originale de Ben Bridt a inspiré ce travail.
• Remerciements à Chris Farris pour son aide et ses conseils.

L’avis de GN⁺

• Cette technique peut être très utile pour réaliser des audits de sécurité dans des environnements cloud, notamment pour vérifier la propriété de buckets AWS S3.
• La discussion sur la sensibilité des informations fournies par cette technique reflète le débat continu entre fournisseurs de services cloud et utilisateurs autour de la sécurité des données et de la vie privée.
• Parmi les autres outils offrant des fonctions similaires figure le service natif d’AWS, CloudTrail, qui sert à journaliser et surveiller l’ensemble des activités se produisant dans l’environnement AWS d’un utilisateur.
• Avant d’adopter cette technique, les utilisateurs doivent vérifier qu’elle est conforme aux politiques d’AWS et aux bonnes pratiques de sécurité.
• Les bénéfices de cette technique incluent des audits de sécurité efficaces et une vérification rapide de la propriété des données, mais il faut aussi prendre en compte des risques tels qu’une possible exposition d’informations personnelles.

[GN⁺]

Commentaires sur Hacker News

• La capacité d’appliquer une correspondance avec joker à la clé de condition AWS s3:ResourceAccount

  • Ce qui est surprenant avec cette fonctionnalité, c’est qu’il n’y a pas de raison légitime d’accorder ou de refuser des autorisations sur la base d’une correspondance partielle d’ID de compte. Les ID de compte AWS peuvent être sensibles, comme les adresses IP, mais pour faire avancer les choses, quelqu’un doit les connaître.

• ID de compte AWS == votre adresse IP. Cela peut être sensible, mais pour que le travail soit fait, quelqu’un doit le connaître.

  • Exemple : l’auteur voulait une configuration privatelink, généralement plus sûre qu’un port sftp ouvert, dans le cadre d’une transaction avec un tiers avec lequel il devait s’intégrer pour des procédures de lutte contre le blanchiment. Mais cette entreprise a refusé pour des raisons de sécurité, afin de cacher son ID de compte. Au final, l’équipe de l’auteur a mis en liste blanche sur le port 22 les plages d’IP publiques qu’elle utilisait.
  • Morale de l’histoire : cacher son ID peut sembler judicieux, mais on ne peut pas réellement faire tourner une activité si personne n’a d’adresse pour vous joindre.

• En général, on ne diffuse pas publiquement son ID de compte, mais il faut s’attendre à ce qu’une partie soit révélée à un moment ou à un autre.

  • À mesure que les éditeurs tiers et les plateformes SaaS passent des utilisateurs IAM et des clés d’accès à des intégrations qui privilégient l’assumption de rôle (role assumption), l’ID du compte utilisé comme point d’intégration est connu par l’autre partie, qui a elle-même ses dépendances et ses vulnérabilités.

• D’autres ressources AWS publiques avec un espace de noms global révèlent aussi l’ID de compte AWS.

  • Pour les personnes intéressées, le code correspondant est publié ici : find-s3-account

• À noter aussi : l’ID de clé AWS (pas la partie clé secrète) contient l’ID de compte, avec un décalage d’un bit.

  • Cet ID de clé est inclus dans l’URL des liens pré-signés pour S3, donc il est probable que vous exposiez déjà votre ID de compte.

• Découverte intéressante, mais en voyant le titre je m’attendais à une méthode plus simple.

  • J’aimerais qu’il existe chez AWS un moyen simple de demander, depuis un compte administrateur, « où se trouve la ressource X ». En particulier, une fonction qui indique rapidement dans quel compte se trouve un bucket S3 donné. C’est surtout un problème lié aux buckets hérités qui existaient avant d’être définis en code. Quand on a beaucoup de comptes AWS, chercher des ressources dans des comptes inconnus et des régions possibles peut être fastidieux.

• Les scénarios où le piratage réel reprend le vieux cliché ou malentendu du « piratage » d’un mot de passe un caractère à la fois sont toujours sympas.

• Le vecteur d’attaque le plus préoccupant est maintenant le fait d’utiliser le numéro de compte pour tenter d’ajouter à la liste blanche, dans la politique de son propre compte, des principals d’un autre compte.

  • Si ce principal n’existe pas dans l’autre compte, on obtient une erreur indiquant que le rôle/l’utilisateur est introuvable. On peut s’en servir pour découvrir de vrais principals dans d’autres comptes.

• Pourquoi est-ce important ? Une conséquence évidente : si l’on connaît un bucket de production, on peut alors trouver des buckets de développement de la même organisation, ce qui n’est pas un comportement attendu.