Le bucketsquatting sur S3 a (enfin) disparu

 (onecloudplease.com)
2 points par GN⁺ 2026-03-14 | 1 commentaires | Partager sur WhatsApp
  • AWS a introduit une nouvelle protection d’espace de noms basée sur le compte pour résoudre le problème de bucketsquatting sur S3
  • Le nouvel espace de noms suit le format <prefix>-<accountid>-<region>-an, et seul le même compte peut créer un bucket portant ce nom
  • Si un autre compte tente d’utiliser le même nom, une erreur InvalidBucketNamespace se produit ; la même erreur est également renvoyée si la région indiquée est incorrecte
  • L’utilisation de cet espace de noms est recommandée par défaut, et son application peut être imposée via une politique d’organisation (SCP) avec la clé de condition s3:x-amz-bucket-namespace
  • Cela ne s’applique pas rétroactivement aux buckets existants, mais offre une protection forte aux nouveaux buckets, ce qui représente une amélioration fondamentale de l’architecture de sécurité de S3

Vue d’ensemble du problème de bucketsquatting

  • Le bucketsquatting (ou bucketsniping) est une forme d’attaque qui exploite le fait que les noms de buckets AWS S3 sont globalement uniques
    • Lorsqu’un bucket est supprimé, son nom redevient disponible, ce qui permet à un attaquant d’enregistrer un nouveau bucket avec le même nom
    • Cela peut entraîner des risques d’accès à des données sensibles ou d’interruption de service
  • Les organisations utilisent souvent des règles de nommage prévisibles comme myapp-us-east-1, ce qui augmente leur exposition à ce type d’attaque
  • Les équipes internes d’AWS ont également été touchées par ce problème, et ont travaillé avec l’équipe sécurité d’AWS pendant près de 10 ans pour trouver une solution

Introduction du nouvel espace de noms S3

  • Pour résoudre ce problème, AWS a introduit le concept d’espace de noms par compte (account namespace)
    • Format : <prefix>-<accountid>-<region>-an
    • Exemple : myapp-123456789012-us-west-2-an
  • Cet espace de noms limite la création d’un bucket portant ce nom au seul compte concerné
    • Si un autre compte tente de créer le même nom, une erreur InvalidBucketNamespace se produit
    • La même erreur est également renvoyée si la région du nom de bucket ne correspond pas à la région réelle
  • AWS recommande d’utiliser cet espace de noms par défaut pour tous les nouveaux buckets
    • Contrairement aux espaces de noms existants (.mrap, --x-s3, -s3alias), celui-ci est introduit comme un espace de noms destiné aux utilisateurs généraux à des fins de sécurité

Application des politiques et gestion

  • Les responsables sécurité peuvent utiliser la clé de condition s3:x-amz-bucket-namespace pour imposer l’usage de cet espace de noms via une politique d’organisation globale (SCP)
  • Cela ne s’applique pas automatiquement aux buckets existants ni aux templates sans espace de noms
    • Pour protéger les buckets existants, il faut créer un bucket au nouveau format d’espace de noms et migrer les données
  • Grâce à cette mesure, le bucketsquatting est en pratique « en train de disparaître », avec une protection complète pour les nouveaux buckets

Approche des autres fournisseurs cloud

  • Google Cloud Storage (GCS) utilise déjà un espace de noms basé sur la vérification du nom de domaine
    • Les buckets au format domaine comme myapp.com ne peuvent être créés que par le propriétaire du domaine
    • Les buckets qui ne sont pas au format domaine restent exposés au risque de bucketsquatting
  • Azure Blob Storage utilise une structure nom de compte de stockage + nom de conteneur
    • Avec une limite maximale de 24 caractères, l’espace de noms est plus restreint, ce qui peut le rendre plus vulnérable au même problème

Conclusion (tl;dr)

  • AWS S3 introduit un nouvel espace de noms compte-région
  • Cet espace de noms empêche les attaques de bucketsquatting et il est fortement recommandé de l’utiliser à chaque création de nouveau bucket
  • Les buckets existants ne sont pas protégés automatiquement ; si nécessaire, une migration des données est requise pour renforcer la protection

À lire aussi

1 commentaires

 
GN⁺ 2026-03-14
Réactions sur Hacker News

  • J’ai récemment découvert qu’on ne peut pas réutiliser l’adresse e-mail de l’utilisateur root, même après la suppression d’un compte AWS
    Dans notre organisation, quelqu’un avait créé l’utilisateur root d’un compte fermé avec l’adresse e-mail principale de l’entreprise, puis créé un nouveau compte avec une autre adresse, et maintenant même la période de récupération après suppression est passée
    Résultat, cette adresse e-mail reste définitivement liée au compte root supprimé, ce qui rend la connexion SSO via un IdP externe impossible
    J’ai contacté le support AWS, mais je n’ai pratiquement reçu aucune aide

    • En aidant récemment le support client, j’ai vu un cas où, après le départ d’un ancien ingénieur clé, le MFA du compte root était resté lié à son téléphone
      Le mot de passe était documenté, mais il n’y avait aucun moyen de désactiver le MFA ; nous avons contacté le support AWS, le chargé de compte, etc., sans résultat
      Au final, l’accès au compte root reste bloqué, et nous devrons peut-être migrer tout l’environnement complexe vers un nouveau compte
    • Si votre fournisseur d’e-mail le permet, vous pouvez utiliser le plus addressing
      AWS considère les adresses e-mail avec un « + » comme des adresses distinctes
    • Il ne faut pas utiliser le compte root pour des personnes ; il faut en faire un compte spécial d’urgence et conserver ses identifiants en lieu sûr
      Mieux vaut ne l’utiliser qu’en cas de problème vraiment grave
    • Ça rappelle à quel point la sécurité peut être fragile
      Au final, il suffit qu’un phishing trompe le support client et obtienne une note de 10/10 pour que tout s’effondre
    • Si l’e-mail de l’IdP est mappé à un rôle, je me demande ce que signifie exactement « définitivement lié à un compte root supprimé »
      J’aimerais savoir quel mécanisme bloque réellement l’usage

  • L’auteur semble avoir mal compris la notion de account name dans Azure Blob Storage
    C’est en pratique au même niveau qu’un nom de bucket S3, et ça doit rester globalement unique, donc c’est toujours une grosse contrainte
    C’est encore plus frustrant avec la limite à 24 caractères
    J’aimerais que Microsoft introduise, comme AWS, un namespace par client

    • L’équipe S3 était déjà consciente du problème il y a environ dix ans
      Mais elle n’a pas pu le changer à cause des contraintes de la conception initiale
      Personnellement, je ne comprends pas pourquoi ils n’ont toujours pas créé une API S3 v2
      Ils auraient pu pousser une migration progressive vers une nouvelle API, mais au final clients et ingénieurs subissent tous une douleur inutile
    • Quand j’ai utilisé Azure pour la première fois, j’ai trouvé que le fait que les ressources ne soient pas namespacées par compte était une conception vraiment étrange
    • L’auteur du billet est intervenu lui-même pour dire qu’il avait mis à jour l’article en tenant compte des retours
    • La limite n’est pas seulement de 24 caractères : les tirets, underscores et points sont aussi interdits
      Il faut donc se limiter aux chiffres et aux lettres minuscules, ce qui est extrêmement pénible
      J’aimerais qu’ils autorisent au moins les tirets, comme S3 ou GCS
    • Ne même pas pouvoir mettre de tiret dans le nom d’un compte de stockage, c’est selon moi une conception complètement ratée
      C’est pareil pour d’autres ressources comme les registres de conteneurs

  • Pour les noms de package, de bucket, de compte GitHub, etc., je me dis qu’un format à la Discord, @nom-4chiffresaléatoires, pourrait être une bonne idée
    Ça démocratiserait l’espace de noms et empêcherait le squatting ou les attaques par réutilisation
    Quand un compte est supprimé, il suffirait de retirer tout le nom, ce qui serait propre

    • Mais Discord a abandonné ce format il y a deux ans pour passer à un système de noms globalement uniques
      La raison est expliquée dans l’annonce officielle :
      il fallait mémoriser quatre chiffres et tenir compte de la casse, ce qui était peu pratique
    • Personnellement, je pense qu’un système UUID + petname serait meilleur
      Surtout pour les applis de chat, où il est plus propre d’utiliser un ID interne et de laisser les utilisateurs n’utiliser qu’un alias
      Pour les buckets, comme l’important est d’avoir un nom lisible par un humain, je pense qu’il vaut mieux utiliser son propre domaine
    • C’est acceptable pour des buckets, mais pour éviter le détournement de packages, le code à 4 chiffres n’aide pas beaucoup
      Au contraire, il augmente surtout le risque de faute de frappe
    • J’aimerais simplement qu’on puisse utiliser partout des noms basés sur la validation de domaine (@example.com)
    • Quand je construis des outils internes, j’attribue aux utilisateurs un ID interne opaque, et je leur laisse le droit de changer librement leur nom
      Il est naturel que des noms se chevauchent dans les communautés en ligne ;
      je me demande donc pourquoi on impose à tout prix des noms globalement uniques

  • Merci à Ian Mckay pour son article
    Le fait qu’AWS ait officiellement introduit un namespace au niveau compte et région est une bonne évolution
    Ce serait encore mieux si les outils d’IaC comme Terraform adoptaient cette règle par défaut
    Terraform ajoute déjà un suffixe de hachage aléatoire à la fin des noms de bucket pour éviter les collisions
    Le blog officiel d’AWS en parle aussi

  • Les attaques de bucket squatting sont intéressantes quand des fournisseurs cloud utilisent des noms de bucket prévisibles pour des espaces de travail internes temporaires
    Chez AWS, l’attaque réelle était difficile à cause du hachage, mais GCP a encore eu récemment ce type de problème
    Présentation connexe : talk DC32 sur le bucket squatting AWS,
    vulnérabilité GCP : CVE-2026-1727

    • Cette présentation m’a vraiment marqué
      Dès qu’on voit que les noms de bucket sont prévisibles, on pressent immédiatement le risque
      Avec la combinaison bucket squatting + bucket public + problème de TOCTOU dans CloudFormation,
      il aurait été possible de déployer des ressources dans le compte de quelqu’un d’autre
      C’est étonnant que l’équipe sécurité d’AWS n’ait pas détecté ça plus tôt

  • Les noms DNS posent un problème similaire
    Si un domaine n’est pas renouvelé, il peut être réenregistré,
    et quelqu’un peut configurer un enregistrement MX pour intercepter des e-mails de réinitialisation de mot de passe, entre autres

    • C’est aussi comme ça qu’on récupère parfois des actifs comme d’anciens blocs IPv4

  • Les buckets AWS offrent encore des fonctionnalités spéciales uniquement quand leur nom correspond exactement au nom d’hôte
    Documentation associée : Virtual Hosting in S3

  • Un nom ne devrait pas être identique à l’objet qu’il désigne
    Quand un nom est réutilisé, il finit par désigner quelque chose de totalement différent,
    et sa signification dépend alors du contexte
    On ne peut le considérer comme identique que lorsqu’on se réattribue soi-même ce nom

  • Je me suis demandé si le fait d’exposer un ID de compte posait un risque de sécurité

    • AWS indique officiellement que l’ID de compte n’est pas une information secrète
      Selon la documentation officielle,
      il faut le manipuler avec précaution, mais il n’est pas considéré comme une donnée sensible
    • À mon avis, c’est comme une adresse e-mail : un identifiant, pas un moyen d’authentification
      Tant qu’on ne l’expose pas partout, ce n’est pas un problème
    • Ce n’est pas idéal d’un point de vue hygiène, mais on ne peut pas attaquer avec le seul ID de compte
      Dans les règles IAM, un attaquant peut utiliser *, donc au final l’essentiel reste la manière dont le défenseur configure ses politiques
    • Si vous partagez une URL signée S3, elle contient un Access Key ID
      En le décodant en base32, on peut en extraire l’Account ID
      Référence : analyse associée

  • Le fait que S3 utilise uniquement le nom du bucket comme clé d’accès a été l’une des décisions de conception les plus agaçantes