Des attaquants abusent de la relation de confiance du rôle AWS de Qubole pour accéder aux comptes de clients et voler des données

Wiz indique que l’attaquant a utilisé les identifiants d’un compte AWS qu’utilise la plateforme de Qubole pour accéder aux environnements AWS des clients. La manière dont l’attaquant a obtenu ces identifiants n’a pas été divulguée. La plupart des rôles IAM que l’attaquant a assumés étaient inutilisés, mais chacun faisait toujours confiance au compte de Qubole, de sorte que les requêtes AssumeRole ont été acceptées. Sentra a alerté les chercheurs après avoir repéré cette activité dans les environnements de plusieurs de ses clients.

Dans les comptes examinés par les chercheurs, l’attaquant a lu les variables d’environnement de fonctions Lambda, extrait des secrets de Secrets Manager, lu des valeurs du SSM Parameter Store et testé les identifiants trouvés avec TruffleHog. L’attaquant a également copié des données de compartiments S3 auxquels un rôle pouvait accéder. Les chercheurs indiquent que le ciblage ne correspond pas à ce que poursuivent habituellement les groupes soutenus par des États et n’ont pas relié la campagne à d’autres activités rendues publiques. Ni Qubole ni Idera n’avait publié de déclaration au sujet de l’attaque lorsque The Hacker News a vérifié.

Les chercheurs recommandent aux organisations d’examiner les journaux CloudTrail à partir du 1 octobre pour y repérer les requêtes AssumeRole émanant du compte de Qubole, 805246085872, et provenant d’une adresse extérieure à AWS. Ils conseillent également de renouveler les secrets accessibles par tout rôle affecté, de révoquer les sessions actives, de supprimer les rôles Qubole inutiles, de restreindre les politiques de confiance au moyen de conditions sur l’adresse IP source et d’examiner ce à quoi chaque rôle de fournisseur peut accéder.

Pourquoi c’est important Toute organisation ayant connecté Qubole à AWS, y compris celle qui ne l’utilise plus, peut détenir un rôle qui fait encore confiance au compte de Qubole et qu’un attaquant peut assumer. Comme l’External ID n’est pas un secret et peut être consulté dans CloudTrail, il ne protège pas un rôle à lui seul. Les investigateurs devraient vérifier dans CloudTrail les indicateurs répertoriés, examiner chaque session qui a suivi et considérer comme exposés les secrets accessibles par les rôles affectés tant qu’ils n’ont pas été renouvelés.