Supply-Chain-Angriff auf Qubole legt AWS-Secrets über vertrauenswürdige IAM-Rollen offen

Zwischen dem 14. und dem 26. Oktober 2026 kompromittierte ein Angreifer mehrere AWS-Konten von Kunden der Data-Lake-Plattform Qubole, die im Besitz von Idera ist. Das Cloud-Sicherheitsunternehmen Wiz berichtete, dass der Eindringling gestohlene Zugangsdaten aus dem eigenen AWS-Konto von Qubole nutzte, um Sicherheitskontrollen zu umgehen und auf Kundenumgebungen zuzugreifen.

Die Sicherheitsverletzung hebt eine kritische Schwachstelle in der Art hervor, wie Drittanbietern Zugriff auf Cloud-Infrastrukturen gewährt wird. Durch die Ausnutzung vertrauenswürdiger Identity-and-Access-Management-(IAM)-Rollen konnte der Angreifer sensible Secrets extrahieren und große Datenmengen kopieren, ohne individuelle Benutzerpasswörter knacken oder Fehler auf Anwendungsebene ausnutzen zu müssen.

Was passiert ist

Qubole operiert innerhalb der AWS-Konten seiner Kunden, indem es IAM-Rollen übernimmt, die Kunden speziell für die Plattform erstellen. Diese Rollen enthalten eine Vertrauensrichtlinie (Trust Policy), die dem AWS-Konto von Qubole erlaubt, die Berechtigungen der Rolle anzunehmen. Zur Validierung dieser Anforderungen verlangt AWS eine External ID, einen von Qubole bereitgestellten Code. Der Angreifer erlangte Zugangsdaten für das zentrale AWS-Konto von Qubole und nutzte sie, um AssumeRole-Anfragen an Kundenkonten zu senden.

Wiz-Forscher bemerkten, dass viele der kompromittierten Rollen von den Kunden nicht mehr genutzt wurden, aber in ihren Konfigurationen weiterhin aktiv waren. Da die Vertrauensbeziehung noch bestand, wurden die Anfragen des Angreifers akzeptiert, solange sie die korrekte External ID enthielten. Dies ermöglichte es dem Eindringling, sich während des zweiwöchigen Zeitfensters lateral durch mehrere Kundenumgebungen zu bewegen.

Neben der rollenbasierten Intrusion fand eine separate, aber nicht verknüpfte Aktivität zwischen dem 8. und 11. Oktober statt. In diesem Zeitraum nutzte ein Angreifer AWS-Zugangsschlüssel, bei denen angenommen wird, dass sie für Qubole eingerichtet wurden, um einige Cloud-Umgebungen zu kompromittieren. Wiz hat dieses frühere Ereignis nicht mit der Hauptkampagne im Zusammenhang gebracht, die den Missbrauch von AssumeRole betraf.

Wie es funktioniert

Der Kernmechanismus dieses Angriffs basierte auf dem Standardmuster für den kontospezifischen Zugriff in AWS. Wenn ein Anbieter wie Qubole Ressourcen im Konto eines Kunden verwalten muss, erstellt der Kunde eine IAM-Rolle mit einer Vertrauensrichtlinie, die auf die Konten-ID des Anbieters zeigt. Der Anbieter nutzt dann den API-Aufruf AssumeRole, um diese Berechtigungen vorübergehend zu erhalten. Die External ID soll Probleme mit sogenannten Confused Deputies verhindern, ist jedoch kein Geheimnis. Sie ist in CloudTrail-Protokollen sichtbar und oft in Infrastructure-as-Code-Dateien gespeichert.

Sobald der Angreifer im System war, musste er keine Passwörter erraten. Er begann sofort damit, vorhandene Zugangsdaten zu sammeln. Der Eindringling las Umgebungsvariablen aus Lambda-Funktionen, zog Secrets aus AWS Secrets Manager und griff auf Werte im SSM Parameter Store zu. Um zu überprüfen, welche Zugangsdaten gültig waren, nutzte der Angreifer TruffleHog, ein Open-Source-Tool zur Erkennung von Secrets, um AWS-Zugangsschlüssel, Entra-ID-Client-Secrets und Okta-Client-Zugangsdaten zu testen.

Die Datenexfiltration war breit angelegt und nicht gezielt. Der Angreifer kopierte Daten aus jedem S3-Bucket, auf den die übernommene Rolle zugreifen konnte. In einigen Fällen wurden ganze Buckets in einer einzigen Sitzung heruntergeladen. Da die Rollen aus Bequemlichkeit oft weitreichende Leseberechtigungen hatten, konnte der Angreifer erhebliche Mengen gespeicherter Informationen abrufen, ohne weitere Privilegien eskalieren zu müssen.

Wichtige Details

• Angreifer-Konto: Die bösartigen AssumeRole-Anfragen stammten von der AWS-Konten-ID 805246085872, die zu Qubole gehört.
• Zeitraum: Der primäre rollenbasierte Angriff fand zwischen dem 14. und 26. Oktober 2026 statt.
• Indicators of Compromise: Achten Sie auf AssumeRole-Anfragen vom Konto 805246085872 mit Quell-IP-Adressen außerhalb von AWS, insbesondere aus IP-Bereichen von OVH oder Mullvad VPN.
• Spezifische IAM-Benutzer: Untersuchen Sie Aktivitäten von IAM-Principal-IDs AIDA3W7DIFLYOLTK63SFS und AIDAJYRRH5Y3A7AAJM2HW, wenn diese von Nicht-AWS-IPs stammen.
• Tools: Der Angreifer nutzte TruffleHog zur Validierung gestohlener Zugangsdaten, erkennbar am User-Agent in GetCallerIdentity-Aufrufen.
• Protokollierungslücken: Viele Opfer verfügten nicht über S3-Datenereignisse oder Serverzugriffsprotokolle, wodurch es unmöglich war, genau festzustellen, welche Objekte gelesen wurden.

Warum das wichtig ist

Für Engineering-Teams unterstreicht dieser Vorfall das Risiko schlafender Anbieterzugriffe. Selbst wenn ein Dienst nicht mehr aktiv genutzt wird, bleiben IAM-Rollen und Vertrauensrichtlinien oft bestehen. Diese vergessenen Verbindungen schaffen eine breite Angriffsfläche, die Angreifer nutzen können, falls die zentralen Zugangsdaten des Anbieters kompromittiert werden. Es verlagert die Sicherheitslast davon, nur den eigenen Perimeter zu schützen, hin zur Überprüfung der Hygiene jeder Drittanbieterintegration.

Der Angriff demonstriert auch die Grenzen von External IDs als Sicherheitskontrolle. Da sie keine Geheimnisse sind, können sie unbefugten Zugriff nicht verhindern, wenn die Zugangsdaten des vertrauenden Kontos gestohlen werden. Ingenieure müssen Anbieterrollen mit derselben Sorgfalt behandeln wie interne Admin-Rollen und strenge Netzwerkbedingungen sowie das Prinzip der geringsten Rechte (Least Privilege) anwenden. Das Verlassen auf Standard-Einrichtungsanleitungen, die oft weitreichende S3-Lesezugriffe gewähren, kann zu katastrophalem Datenverlust führen, wenn diese Rollen missbraucht werden.

Was Sie tun können

• Überprüfen Sie CloudTrail-Protokolle ab dem 1. Oktober 2026 auf AssumeRole-Anfragen vom Konto 805246085872, die von Nicht-AWS-IP-Adressen stammen.
• Rotieren Sie alle Secrets, Parameter und Lambda-Umgebungsvariablen, die von einer Qubole-Rolle mit Kompromittierungsanzeichen zugänglich sind, und widerrufen Sie aktive Sitzungen.
• Entfernen Sie alle Qubole-IAM-Rollen, die nicht mehr benötigt werden, oder aktualisieren Sie die Vertrauensrichtlinie, um die Konten-ID von Qubole zu entfernen, falls der Dienst eingestellt wird.
• Fügen Sie Bedingungen wie aws:SourceIp oder aws:SourceVpce zu Vertrauensrichtlinien von Anbieterrollen hinzu, um den Zugriff auf dokumentierte Netzwerk-Bereiche des Anbieters zu beschränken.
• Aktivieren Sie S3-Datenereignisse oder Serverzugriffsprotokolle für alle Buckets, die sensible Daten enthalten, um zukünftige Sichtbarkeit auf Objektzugriffsebene zu gewährleisten.
• Ersetzen Sie den kontoweiten :root-Principal in Vertrauensrichtlinien durch spezifische IAM-Principals, wo unterstützt, und verwenden Sie eindeutige External IDs für jede Rolle.