Compromission de Qubole, une attaque chaîne d'approvisionnement expose des dizaines de clients

Contexte de l'attaque

Sentra a détecté une campagne de compromission qui a traversé plus d'une douzaine d'organisations via les rôles AWS accordés à Qubole, une plateforme de big‑data. Les victimes n'ont jamais été directement pénétrées ; l'accès provient d'une clé d'identité volée appartenant à Qubole. L'attaquant a exploité ce privilège pendant moins de 24 heures, lisant environ 100 mots de passe et clés en 7 minutes, sans aucune action d'écriture, ce qui a rendu la fuite difficile à repérer.

Mécanisme d'exploitation

Chaque rôle Qubole était protégé par un ExternalId, exigé par AWS pour valider l'identité du fournisseur. L'assaillant a présenté le même code que Qubole, de sorte que les journaux AWS ont indiqué un accès légitime. Les sessions ont été initiées depuis un serveur OVH loué et le VPN Mullvad, aucune activité n'étant apparue depuis le réseau interne de Qubole.

Après un test initial sur un rôle à faible valeur, l'attaquant a déclenché un assume‑role en ≈ 1 s, lui permettant de passer d'une organisation à l'autre quasi instantanément. Il a ensuite procédé à des téléchargements massifs depuis les buckets S3, incluant des sauvegardes de bases de production, avant de cesser toute activité, laissant les rôles actifs mais inactifs.

Analyse des vecteurs et limites

Les vecteurs de vol de secrets comprennent :

- Extraction en masse depuis AWS Secrets Manager (identifiants de CI, bases, tokens).
- Lecture de paramètres décryptés dans SSM Parameter Store (clés d'agents de surveillance).
- Capture des variables d'environnement Lambda, puis basculement vers l'extraction depuis les métadonnées EC2 (user‑data).
Ces sources contiennent souvent des informations d'identité non rotatives, ce qui augmente la surface d'attaque.

Un point critique est la persistance des rôles Qubole « dormants » depuis le printemps, pourtant toujours capables de lire la quasi‑totalité des données. L'absence de rotation ou de désactivation de ces rôles a fourni une porte d'entrée permanente.

Leçons et recommandations

Le scénario montre que le respect des meilleures pratiques AWS (ExternalId, politiques de moindre privilège) ne suffit pas lorsqu'un fournisseur est compromis. Deux mesures sont indispensables :

1. Zero‑trust : restreindre chaque rôle à un sous‑ensemble de ressources strictement nécessaires, afin qu'une clé volée ne permette pas l'accès à l'ensemble du data lake.
2. Détection d'anomalies d'utilisation des identités : surveiller le volume, la fréquence et la localisation des accès. Dans ce cas, le passage d'un rôle dormant à un flux de lecture intensif aurait pu déclencher une alerte.

Enfin, les organisations doivent auditer régulièrement les rôles tiers, désactiver ceux qui ne sont plus utilisés et appliquer la rotation automatisée des clés d'accès.