Bucket Namespace Hijacking : la menace silencieuse du cloud

Ce qui s'est passé

Les chercheurs de l'équipe Unit 42 de Palo Alto Networks ont publié une analyse technique détaillant une classe d'attaque contre les infrastructures de stockage objet des trois principaux hyperscalers — Amazon Web Services, Google Cloud Platform et Microsoft Azure — exploitant la nature globale des espaces de noms des buckets. La technique, dénommée bucket namespace hijacking ou bucketsquatting, permet à un attaquant d'intercepter silencieusement des flux de données opérationnels sans déclencher aucune alerte côté victime ni générer d'événement visible dans les journaux IAM.

Le mécanisme repose sur une caractéristique architecturale fondamentale des trois plateformes : chaque bucket de stockage objet existe dans un espace de noms partagé entre tous les clients du fournisseur, non scopé à un compte, un projet ou une organisation. En d'autres termes, les noms de buckets fonctionnent comme des domaines : une fois créé, un bucket nommé mon-bucket-logs empêche tout autre client de créer un bucket portant ce même nom sur la même plateforme. En revanche, lorsque ce bucket est supprimé, son nom retourne dans le pool global et peut être enregistré par n'importe quel autre client — y compris un attaquant.

L'attaque se déroule en trois temps. Premièrement, l'attaquant identifie des buckets qui étaient référencés dans des flux de données opérationnels mais qui ont depuis été supprimés — une situation plus courante qu'il n'y paraît, notamment lors de migrations, de réorganisations d'infrastructure ou de départs d'équipes qui laissent derrière elles des configurations orphelines. Deuxièmement, l'attaquant enregistre le nom du bucket abandonné sur son propre compte cloud, une opération facturée quelques centimes par mois. Troisièmement, tous les systèmes qui envoyaient des données vers ce bucket continuent de le faire sans erreur ni alerte, mais ces données arrivent désormais dans le bucket de l'attaquant.

Le caractère particulièrement insidieux de cette technique réside dans l'absence totale d'alerte visible. Du point de vue de l'infrastructure victime, rien d'anormal ne se produit : les appels API S3, GCS ou Azure Blob réussissent avec un code HTTP 200, aucune erreur n'est générée, aucun événement IAM suspect n'est enregistré puisque les accès proviennent de l'infrastructure légitime vers un bucket qui existe. Seule l'analyse active des destinations de flux dans un audit de configuration ou lors de la reconstruction d'un incident permet de détecter la dérive.

Checkmarx a documenté un cas concret d'attaque supply chain exploitant ce mécanisme : le package npm bignum, utilisé dans des centaines de milliers de projets JavaScript, téléchargeait un binaire natif depuis un bucket S3 spécifique. Ce bucket avait été supprimé environ six mois avant l'attaque. Un acteur malveillant a enregistré le nom du bucket abandonné sur son propre compte AWS et y a déposé un binaire modifié contenant un payload malveillant. Pendant plusieurs semaines, toutes les installations fraîches du package bignum récupéraient et exécutaient ce binaire vérolé, sans aucune alerte de la chaîne npm ni des outils de sécurité standards.

La technique s'applique à plusieurs scénarios d'attaque distincts. Dans le cas de l'exfiltration de logs, l'attaquant récupère passivement des télémétriques de sécurité, des journaux applicatifs et des traces d'audit sans jamais interagir activement avec l'infrastructure de la victime. Dans le cas des pipelines CI/CD, des artifacts de build ou des images de conteneurs peuvent être substitués silencieusement. Dans le cas des backups, des sauvegardes incrémentales envoyées vers un bucket orphelin peuvent être interceptées et analysées à loisir. Dans tous ces scénarios, l'attaquant dispose d'un accès en lecture aux données sans avoir besoin de pivoter sur le réseau de la victime ni d'exploiter une vulnérabilité applicative classique.

En réponse à la divulgation, AWS a déployé en mars 2026 une fonctionnalité d'espaces de noms régionaux pour les buckets S3 à usage général : une option de configuration permettant de scoper le nom du bucket à un suffixe spécifique au compte, rendant techniquement impossible l'enregistrement d'un même nom par un autre compte. La correction est opt-in et prospective : elle protège les nouveaux buckets créés après activation, mais n'affecte pas les millions de buckets existants déjà en espace de noms global. Ni Google Cloud Platform ni Microsoft Azure n'ont annoncé de correctif structurel équivalent à la date de publication de cette analyse.

La Cloud Security Alliance a publié un document de recherche qualifiant le bucket namespace hijacking de porte dérobée silencieuse dans les architectures cloud modernes, et appelant à une refonte des pratiques de cycle de vie des ressources cloud. Le site Hackaws.cloud, qui couvre l'actualité AWS en profondeur, a titré sur la fin du bucketsquatting suite à la mise à jour AWS, tout en soulignant que la correction partielle laisse un angle mort significatif pour les infrastructures existantes dont les buckets en espace de noms global n'ont pas migré vers les nouveaux espaces régionaux.

Pourquoi c'est important

Le bucket namespace hijacking illustre un angle mort structurel dans la manière dont les équipes gèrent le cycle de vie des ressources cloud. Dans un environnement cloud mature, des buckets sont créés et supprimés quotidiennement — pour des environnements de test éphémères, des migrations, des projets temporaires. Les références à ces buckets dans les configurations applicatives, les scripts d'infrastructure-as-code, les paramètres de logging cloud natif, perdurent souvent bien après la suppression des ressources elles-mêmes. Cette dette de configuration est le sol fertile sur lequel prospère cette famille d'attaques, et elle est d'autant plus difficile à détecter qu'elle ne génère aucune erreur visible dans les outils de monitoring traditionnels.

Pour les équipes de sécurité, le défi est double. D'abord, la détection échappe aux voies traditionnelles : les alertes SIEM basées sur les erreurs d'accès ou les événements IAM anormaux ne captent pas une situation où les flux de données aboutissent avec succès mais vers une mauvaise destination. Seule une approche proactive — analyse périodique des destinations de flux de données, vérification que les buckets référencés dans les configurations appartiennent bien à l'organisation — permet de détecter l'anomalie. Ensuite, la remédiation est complexe pour les applications legacy qui encodent en dur des noms de buckets sans passer par des paramètres de configuration externalisés : modifier ces références peut nécessiter des cycles de release complets et des tests de non-régression étendus.

L'impact potentiel sur la chaîne d'approvisionnement logicielle est particulièrement préoccupant dans le contexte post-XZ Utils et des attaques supply chain documentées ces dernières années. Les gestionnaires de paquets npm, PyPI ou Maven hébergent des milliers de packages qui téléchargent des dépendances binaires depuis des URLs externes, dont des buckets S3. Un attaquant patient peut identifier des buckets abandonnés dans des packages à fort taux de téléchargement et attendre des mois avant d'agir, maximisant l'exposition avant détection. La recommandation NIS2 d'évaluation des risques de la chaîne d'approvisionnement s'applique directement ici : les dépendances sur des ressources cloud tierces doivent être inventoriées et surveillées au même titre que les dépendances logicielles.

La correction partielle d'AWS — opt-in et prospective uniquement — est un premier pas mais insuffisant. Elle signifie que des millions de buckets créés avant mars 2026 en espace de noms global restent vulnérables à la réutilisation s'ils sont supprimés. Les organisations dont l'infrastructure AWS a plus d'un an doivent conduire un audit ciblé de leurs configurations CloudTrail, des destinations de flux Kinesis, des paramètres de backup et des références de buckets dans leurs fichiers Terraform et CloudFormation. L'absence de correctif annoncé chez Google Cloud et Azure rend la priorité de cet audit d'autant plus urgente pour les environnements multi-cloud.

Ce qu'il faut retenir

• Ne supprimez jamais un bucket cloud sans d'abord mettre à jour toutes les références dans vos configurations applicatives, scripts IaC et politiques de logging — un nom libéré peut être réclamé par un attaquant en quelques minutes.
• Activez immédiatement l'espace de noms régionaux AWS (opt-in) pour tous les nouveaux buckets S3 ; pour GCS et Azure, adoptez des conventions de nommage incluant un identifiant de compte unique pour rendre la réutilisation improbable.
• Inventoriez les packages open-source qui téléchargent des binaires natifs depuis des buckets S3 ou autre stockage objet : un bucket abandonné dans votre chaîne de dépendances est un vecteur d'attaque supply chain silencieux et difficile à détecter.