Une attaque de la chaîne d'approvisionnement sur Qubole expose des secrets AWS via des rôles IAM approuvés

Entre le 14 et le 26 octobre 2026, un attaquant a compromis plusieurs comptes AWS appartenant à des clients de Qubole, une plateforme de data lake détenue par Idera. La société de cybersécurité cloud Wiz a rapporté que l'intrus a utilisé des identifiants volés depuis le propre compte AWS de Qubole pour contourner les contrôles de sécurité et accéder aux environnements clients.

Cette violation met en évidence une vulnérabilité critique dans la manière dont les accès sont accordés aux fournisseurs tiers sur l'infrastructure cloud. En exploitant des rôles Identity and Access Management (IAM) approuvés, l'attaquant a pu extraire des secrets sensibles et copier de grands volumes de données sans avoir besoin de casser les mots de passe individuels des utilisateurs ni d'exploiter des failles au niveau de l'application.

Ce qui s'est passé

Qubole opère au sein des comptes AWS de ses clients en usurpant des rôles IAM créés spécifiquement pour la plateforme par ces derniers. Ces rôles incluent une politique de confiance autorisant le compte AWS de Qubole à prendre les permissions du rôle. Pour valider ces demandes, AWS exige un External ID, un code fourni par Qubole. L'attaquant a obtenu les identifiants du compte AWS central de Qubole et les a utilisés pour envoyer des demandes AssumeRole vers les comptes clients.

Les chercheurs de Wiz ont noté que beaucoup des rôles compromis étaient inutilisés par les clients mais restaient actifs dans leurs configurations. Comme la relation de confiance était toujours en place, les demandes de l'attaquant ont été acceptées dès lors qu'elles incluaient le bon External ID. Cela a permis à l'intrus de se déplacer latéralement à travers plusieurs environnements clients durant cette fenêtre de deux semaines.

En plus de cette intrusion basée sur les rôles, une activité distincte mais non liée s'est produite entre le 8 et le 11 octobre. Durant cette période, un attaquant a utilisé des clés d'accès AWS présumées configurées pour Qubole pour compromettre quelques environnements cloud. Wiz n'a pas établi de lien entre cet événement antérieur et la campagne principale impliquant l'abus d'AssumeRole.

Comment cela fonctionne

Le mécanisme central de cette attaque reposait sur le modèle standard d'accès inter-comptes AWS. Lorsqu'un fournisseur comme Qubole doit gérer des ressources dans le compte d'un client, ce dernier crée un rôle IAM avec une politique de confiance pointant vers l'ID du compte du fournisseur. Le fournisseur utilise ensuite l'appel API AssumeRole pour obtenir temporairement ces permissions. L'External ID est destiné à prévenir les problèmes de « deputy confusion », mais il ne constitue pas un secret. Il est visible dans les journaux CloudTrail et souvent stocké dans des fichiers d'infrastructure-as-code.

Une fois à l'intérieur, l'attaquant n'avait pas besoin de deviner les mots de passe. Il a immédiatement commencé à collecter les identifiants existants. L'intrus a lu les variables d'environnement des fonctions Lambda, extrait des secrets depuis AWS Secrets Manager et accédé aux valeurs dans le SSM Parameter Store. Pour vérifier quels identifiants étaient valides, l'attaquant a utilisé TruffleHog, un outil open source de détection de secrets, pour tester les clés d'accès AWS, les secrets clients Entra ID et les identifiants clients Okta.

L'exfiltration de données a été large plutôt que ciblée. L'attaquant a copié des données depuis tout bucket S3 accessible par le rôle usurpé. Dans certains cas, des buckets entiers ont été téléchargés lors d'une seule session. Comme les rôles avaient souvent des permissions de lecture larges pour des raisons de commodité, l'attaquant pouvait accéder à des quantités significatives d'informations stockées sans avoir besoin d'escalader davantage ses privilèges.

Détails clés

• Compte attaquant : Les demandes AssumeRole malveillantes provenaient de l'ID de compte AWS 805246085872, qui appartient à Qubole.
• Période : L'attaque principale basée sur les rôles s'est déroulée entre le 14 et le 26 octobre 2026.
• Indicateurs de compromission : Recherchez les demandes AssumeRole provenant du compte 805246085872 avec des adresses IP sources hors d'AWS, notamment depuis les plages OVH ou Mullvad VPN.
• Utilisateurs IAM spécifiques : Examinez l'activité des principaux IAM IDs AIDA3W7DIFLYOLTK63SFS et AIDAJYRRH5Y3A7AAJM2HW si elle provient d'IP non-AWS.
• Outils : L'attaquant a utilisé TruffleHog pour valider les identifiants volés, identifiable par son user agent dans les appels GetCallerIdentity.
• Manques de journalisation : Beaucoup de victimes manquaient de journaux d'événements de données S3 ou de journaux d'accès serveur, rendant impossible la détermination exacte des objets lus.

Pourquoi c'est important

Pour les équipes d'ingénierie, cet incident souligne le risque lié aux accès dormants des fournisseurs. Même si un service n'est plus activement utilisé, les rôles IAM et les politiques de confiance restent souvent en place. Ces connexions oubliées créent une large surface d'attaque que les pirates peuvent exploiter si les identifiants centraux du fournisseur sont compromis. Cela déplace la charge de sécurité de la simple protection de votre propre périmètre à la vérification de l'hygiène de chaque intégration tierce.

L'attaque démontre également les limites des External IDs en tant que contrôle de sécurité. Puisqu'ils ne sont pas des secrets, ils ne peuvent pas empêcher un accès non autorisé si les identifiants du compte faisant confiance sont volés. Les ingénieurs doivent traiter les rôles fournisseurs avec la même rigueur que les rôles administratifs internes, en appliquant des conditions réseau strictes et le principe du moindre privilège. Se fier aux guides d'installation par défaut, qui accordent souvent un accès en lecture large à S3, peut entraîner une perte catastrophique de données lorsque ces rôles sont abusés.

Ce que vous pouvez faire

• Auditez les journaux CloudTrail à partir du 1er octobre 2026 pour repérer les demandes AssumeRole provenant du compte 805246085872 initiées depuis des adresses IP non-AWS.
• Faites pivoter tous les secrets, paramètres et variables d'environnement Lambda accessibles par tout rôle Qubole montrant des signes de compromission, et révoquez les sessions actives.
• Supprimez tout rôle IAM Qubole qui n'est plus nécessaire ou mettez à jour la politique de confiance pour retirer l'ID du compte Qubole si le service est discontinué.
• Ajoutez des conditions aws:SourceIp ou aws:SourceVpce aux politiques de confiance des rôles fournisseurs pour restreindre l'accès aux plages réseau documentées du fournisseur.
• Activez les événements de données S3 ou les journaux d'accès serveur pour tous les buckets contenant des données sensibles afin de garantir une visibilité future sur l'accès au niveau objet.
• Remplacez le principal :root global au compte dans les politiques de confiance par des principaux IAM spécifiques là où c'est pris en charge, et utilisez des External IDs uniques pour chaque rôle.