Une intrusion chez Qubole, plateforme de data lake, a exposé les mécanismes de confiance mis en place entre un fournisseur et ses clients sur AWS. Entre le 14 et le 26 octobre 2026, des acteurs malveillants ont réussi à exploiter des rôles IAM établis par les clients pour accéder à des secrets et des données dans leurs propres comptes AWS. Wiz, société de sécurité, a documenté cette attaque, révélant que même si le processus d’octroi d’accès via un rôle IAM exige l’inclusion d’un « External ID » lors de l’appel AssumeRole, cet élément ne constitue pas une barrière absolue.

L’attaque s’est greffée sur le compte AWS de Qubole, identifié sous l’ID 805246085872. Les chercheurs ont observé que l’attaquant a pu utiliser les identifiants de ce compte pour assumer des rôles créés par les clients. Le mécanisme de sécurité, l’Identifiant Externe, censé prévenir le « confused deputy problem », a été accepté par AWS, même si l’attaquant utilisait des adresses IP externes.

Le fonctionnement des rôles tiers sur AWS

Pour permettre à un service tiers d’interagir avec les ressources d’un compte AWS, le client définit un rôle IAM. Ce rôle, dont la politique de confiance autorise le compte du fournisseur à l’assumer, est la méthode standard pour éviter le partage de clés d’accès permanentes. AWS exige que, lors de l’appel AssumeRole, un Identifiant Externe soit fourni pour valider l’opération. AWS précise que cet Identifiant Externe n’est pas un secret ; il peut être visible par quiconque a les droits sur le rôle.

Cependant, l’analyse de Wiz montre que l’attaquant a réussi à faire accepter ses requêtes AssumeRole en utilisant cet identifiant. Une fois à l’intérieur des environnements des victimes, l’acteur a procédé à l’énumération des ressources. Il a récupéré des variables d’environnement de fonctions Lambda, des secrets via Secrets Manager, et des paramètres du SSM Parameter Store, avant de tester ces identifiants volés.

Pistes de détection et mesures de remédiation

Face à cette faille de la chaîne d’approvisionnement, les experts conseillent aux organisations qui ont intégré Qubole à AWS de consulter immédiatement leurs journaux CloudTrail à partir du 1er octobre. Il faut spécifiquement chercher des tentatives d’appel AssumeRole provenant de l’ID de compte 805246085872, mais dont l’adresse IP source n’est pas une adresse interne à AWS. Les chercheurs ont noté l’utilisation de l’IAM principal ID AIDA3W7DIFLYOLTK63SFS par l’attaquant dans les comptes examinés.

Pour renforcer la défense, il est recommandé de ne pas se fier uniquement à l’Identifiant Externe, étant donné qu’il est visible. Les chercheurs suggèrent d’ajouter des conditions de politique telles que aws:SourceIp ou aws:SourceVpce pour restreindre strictement les appels AssumeRole aux plages réseau documentées du fournisseur. Il est également conseillé de purger tous les secrets et paramètres accessibles par les rôles potentiellement compromis et de révoquer les sessions actives.

L’incident rappelle que, bien que la documentation AWS détaille les exigences pour créer un rôle tiers (ID de compte et Identifiant Externe), la mise en œuvre de cette seule mesure n’est pas suffisante pour colmater toutes les brèches d’accès.

Sources

• Access to AWS accounts owned by third parties, docs.aws.amazon.com
• Creating a Cross-account IAM Role for QDS, docs.qubole.com
• Hackers Exploit Qubole’s Trusted AWS Access to Breach Customer Accounts and Steal Data, The Hacker News, 9 novembre 2026
• Trusted by Default: Qubole Cross-Account Access Abused in the Wild, Wiz, 9 novembre 2026