Atacante a utilisé Qubole AWS pour assumer des rôles dans les comptes clients et voler des secrets

Entre le 14 et le 26 octobre, un attaquant a exploité les identifiants associés au compte AWS en utilisant la plateforme Qubole pour accéder aux environnements de plusieurs clients et extraire des secrets et des données, selon l'analyse des chercheurs de Wiz. La méthode utilisée était d'assumer des rôles (AssumeRole) que les clients avaient créés pour permettre à Qubole d'agir dans leurs comptes; ces rôles faisaient confiance au compte Qubole (ID 805246085872) et nécessitaient un ID externe, que l'attaquant pourrait inclure correctement. Les chercheurs documentent également l'activité antérieure, du 8 au 11 octobre, dans laquelle un autre acteur - ou peut-être le même avec une technique différente - utilisait les clés d'accès AWS des clients configurés pour Qubole; cette phase préliminaire était liée à des engagements dans certains environnements, mais n'a pas été publiquement corrélée avec l'abus d'AssumeRole qui a suivi.

Faits confirmés : Wiz a publié un rapport technique détaillant la campagne, et l'enquête a été ouverte à la suite d'alertes de Sentra. L'attaquant a lu des variables d'environnement de fonction Lambda, extrait des secrets de AWS Secrets Manager, obtenu des paramètres du SSM Parameter Store et téléchargé des objets S3 - parfois en téléchargeant un seau entier si le rôle le permettait. Pour valider les identifiants supprimés, l'attaquant a utilisé des outils automatisés comme TruffleHog. En outre, les chercheurs ont identifié des signatures opérationnelles reproductibles : le compte Qubole 8052460872, deux principaux ID IAM pertinents (AIDA3W7DIFLYOLTK63SFS, associés à l'attaquant dans les cas examinés, et AIDAJYRH5Y3A7AAAJM2HW, utilisés par Qubole et aussi par l'attaquant depuis le 18 octobre), des adresses IP publiques liées à des serveurs OVH et VPN (par exemple 57.129.54.120 et 45.83.220211), qui ont commencé par des noms et qui, par exemple, étaient connus sous le nom de "le""" et "" Haukrayr "dont",

Ce qui a permis l'accès et pourquoi il a fonctionné: Techniquement, Qubole travaille dans le compte du client à travers un rôle IAM dont la politique de confiance permet au compte Qubole de prendre en charge le rôle. AWS valide que l'application AssumeRole provient du compte fiable et que l'ID externe correspond. Le problème clé dans cet incident n'était pas une vulnérabilité dans AWS, mais les références que l'attaquant avait du côté du fournisseur (le compte Qubole) pourraient être utilisées pour émettre des applications valides aux rôles encore configurés pour faire confiance à ce compte. De plus, l'ID externe n'est pas secret selon le propre guide d'AWS : il est enregistré dans CloudTrail et visible dans les fichiers d'infrastructure et les modèles, donc sa connaissance par l'attaquant n'est pas surprenante. Plus de détails techniques et de recommandations générales sur les rôles de vente se trouvent sur la page de recherche Wiz et la documentation AWS sur ID externe ( Recherche Wiz, AWS Guide d'identification externe).

À qui elle touche et portée pratique: toute organisation qui a donné un rôle IAM à Qubole, même si elle n'utilise plus activement la plateforme, est potentiellement touchée. Dans les environnements examinés, l'attaquant a cherché et profité de secrets qui pourraient débloquer d'autres ressources et services : les clés d'accès AWS (qui permettent le fonctionnement direct de l'API), les secrets de fournisseur d'identité (par exemple entrer / Okta) et les identifiants d'application. Lorsqu'il n'y avait pas de données S3 détaillées (événements de données S3 ou journaux d'accès au serveur), les équipes de réponse n'ont pas pu déterminer précisément quels objets ont été lus ou copiés, ce qui a accru le risque d'exposition à des informations sensibles.

Quelles parties de l'histoire ne sont toujours pas publiquement confirmées: Wiz et les enquêteurs n'ont pas déclaré publiquement comment les pouvoirs qui ont permis à l'agresseur d'opérer à partir du compte Qubole ont été initialement obtenus ou si ces pouvoirs ont déjà été révoqués; ni Qubole ni sa matrice Idera n'avaient publié de déclaration publique au moment de la vérification de l'information. Il n'y a pas de lien public et confirmé entre cette campagne et d'autres incidents majeurs ou des preuves concluantes qu'il s'agit d'une opération parrainée par un État acteur; Wiz note que les objectifs ne sont pas conformes au modèle habituel des groupes étatiques.

Conséquences réelles et potentielles: L'exposition de secrets et de clés d'accès peut permettre à l'attaquant latéral d'escalade dans les comptes, la persistance par de nouvelles identités ou intégrations, le vol de données, et dans des environnements intégrés avec d'autres nuages ou SaaS, l'engagement des identités fédérées. L'absence de documents détaillés rend impossible de déterminer l'ampleur exacte de l'exfiltration chez toutes les personnes touchées, ce qui complique la réponse et la médiation.

Mesures spécifiques et immédiates à prendre par tout équipement affecté ou utilisé par Qubole avec AWS: d'abord, suivre les événements dans CloudTrail à partir du 1er octobre à la recherche d'AssumeRole où vous allez Identity.accountId = 805246085872 et IPAddress source n'est pas une adresse AWS; enquêter sur les sessions dont la session commence par "quiam-", appelé GetCallerIdentity avec l'utilisateur-agent Truffleg et l'activité des PI identifiés par les chercheurs. Activer un examen complet du Secrets Manager, du SSM Parameter Store, des variables d'environnement Lambda et des permissions de lecture S3 que le rôle pourrait atteindre; lancer immédiatement tous les identifiants (clés d'accès, secrets d'application, secrets de client) auxquels le rôle avait une visibilité et changer des mots de passe ou des jetons externes qui auraient pu être exposés. Notez que la rotation d'un secret qui n'invalide pas les sessions de temps déjà émises; bloquer les sessions actives, supprimer ou modifier la politique de confiance du rôle (par exemple en supprimant le compte Qubole de la politique de confiance ou en remplaçant le compte principal par le compte MIU spécifique que le fournisseur documente) et, le cas échéant, supprimer les rôles qui ne sont pas utilisés. Ajouter des conditions à la politique de fiducie, comme aws : Source Ip ou aws: SourceVpce, pour limiter l'endroit où les rôles peuvent être assumés - les chercheurs indiquent que dans ce cas une condition de PI aurait bloqué les hypothèses observées. Mettre en place une piste organisationnelle et activer les événements de données S3 ou servir des journaux d'accès dans des seaux sensibles pour vérifier les futures lectures d'objets (voir le guide CloudTrail : AWS Trail Nucléaire).

Enfin, revoyez et réduisez la portée des permis accordés aux rôles de tiers : il est courant de voir le rôle des fournisseurs avec une large autorisation de lecture sur S3, l'accès aux paramètres Secrets Manager et SSM "pour plus de commodité" ; limiter ces permis au minimum nécessaire et mettre en place des alertes pour AssumeRole provenant de VPS, des réseaux d'hébergement ou des IP VPN non documentés par le fournisseur. Ces mesures n'assurent pas qu'un engagement passé n'aura plus de conséquences, mais réduisent considérablement le champ des futurs abus et facilitent le confinement et la vérification.

Cet incident souligne que la confiance réciproque entre les comptes et la gestion des pouvoirs dans l'intégration des fournisseurs nécessite des politiques et des dossiers spécifiques : il ne suffit pas de déléguer l'accès, il faut le mettre en œuvre et le limiter de manière proactive. Gardez un œil sur les communications officielles Qubole ou Idera et les rapports techniques Wiz pour des mises à jour et des détections supplémentaires.