Angreifer missbrauchen Qubole-Zugang zu AWS-Konten von Kunden und stehlen Secrets und Daten

Qubole gehört zu Idera und arbeitet direkt in den AWS-Konten seiner Kunden. Dafür legt der Kunde eine IAM-Rolle an, also eine AWS-Identität mit eigenen Berechtigungen. Die Vertrauensrichtlinie (Trust Policy) dieser Rolle erlaubt es dem AWS-Konto von Qubole, die Rolle zu übernehmen und deren Rechte zu nutzen. Jede solche AssumeRole-Anfrage muss einen passenden Code von Qubole enthalten, die sogenannte External ID.

Nach Angaben der Wiz-Forscher waren die meisten der übernommenen Rollen abgesehen vom Angriff ungenutzt. Da sie dem Qubole-Konto aber weiterhin vertrauten, waren die Anfragen des Angreifers erfolgreich. In ihrer technischen Analyse schreiben die Forscher, dass jede dem Angreifer zugeordnete AssumeRole-Anfrage eine External ID enthielt und angenommen wurde. AWS akzeptiert eine solche Anfrage, wenn sie aus dem vertrauenswürdigen Konto stammt und die korrekte External ID mitbringt. Laut der AWS-Dokumentation gilt dieser Code nicht als Geheimnis; jeder mit Zugriff auf die Rolle kann ihn einsehen.

Aufgefallen war die Aktivität dem Sicherheitsunternehmen Sentra in den Umgebungen mehrerer seiner Kunden, das daraufhin Wiz alarmierte. Ob die Zugangsdaten inzwischen gesperrt wurden oder die Aktivität beendet ist, sagten die Forscher nicht. Weder Qubole noch Idera hatten zum Zeitpunkt der Veröffentlichung eine Stellungnahme auf ihren Websites veröffentlicht.

In den untersuchten Konten suchte der Angreifer gezielt nach gespeicherten Zugangsdaten: Er las Umgebungsvariablen von Lambda-Funktionen aus, zog Secrets aus dem Secrets Manager und las Werte aus dem SSM Parameter Store. Die gefundenen Zugangsdaten – AWS-Zugriffsschlüssel der Opfer, Client-Secrets für Entra ID und Client-Zugangsdaten für Okta – prüfte er anschließend mit dem Werkzeug TruffleHog auf ihre Gültigkeit. Zudem kopierte er Daten aus S3, und zwar wahllos aus jedem Bucket, auf den eine Rolle Zugriff hatte; mitunter lud er einen kompletten Bucket in einer einzigen Sitzung herunter.

Mit anderen öffentlich bekannten Aktivitäten haben die Forscher die Kampagne nicht in Verbindung gebracht. Die Zielauswahl passe nicht zu dem, was staatlich unterstützte Gruppen üblicherweise anvisieren.

Qubole erlaubt Kunden auch eine Anbindung per AWS-Zugriffsschlüssel statt per Rolle. Vom 8. bis 11. Oktober nutzte ein Angreifer solche kundeneigenen Schlüssel, die nach Einschätzung der Forscher für Qubole eingerichtet worden waren, und kompromittierte damit einige Cloud-Umgebungen der Opfer. Eine Verbindung zum Missbrauch von AssumeRole wurde bislang nicht hergestellt.

Wiz rät allen Organisationen, die Qubole je mit AWS verbunden haben, die CloudTrail-Protokolle ab dem 1. Oktober in jedem Konto mit einer Qubole-Rolle zu prüfen. Hinweise auf eine Kompromittierung sind:

• AssumeRole-Anfragen mit userIdentity.accountId 805246085872 (das Konto der Qubole-Plattform), deren sourceIPAddress nicht zu AWS gehört; legitimer Qubole-Verkehr kam laut den Forschern ausschließlich aus AWS.
• Jede Aktivität der IAM-Principal-ID AIDA3W7DIFLYOLTK63SFS, die in den untersuchten Konten nur der Angreifer nutzte.
• Die IAM-Principal-ID AIDAJYRRH5Y3A7AAJM2HW bei Quelladressen außerhalb von AWS; der Angreifer nutzte diesen IAM-Nutzer ab dem 18. Oktober, er wird aber auch für regulären Qubole-Verkehr verwendet.
• Die bei OVH gehosteten Adressen 57.129.54[.]120 und 2001:41d0:70d[:]7800::.
• Die Mullvad-VPN-Adressen 45.83.220[.]211, 185.209.199[.]73 und 89.37.63[.]175; da andere VPN-Nutzer sie teilen, ist ein Treffer allein kein Beweis.
• Rollensitzungen, deren Name mit „quiam-“ beginnt, etwa „quiam-enum“.
• Der User-Agent TruffleHog bei GetCallerIdentity-Aufrufen von einer der genannten Adressen; derselbe User-Agent sollte auch in den Anmeldeprotokollen des Identitätsanbieters gesucht werden.

Für jede verdächtige Sitzung sollten alle nachfolgenden Aktionen geprüft werden, besonders in Secrets Manager, SSM Parameter Store, Lambda und S3. CloudTrail-Management-Events erfassen zwar jede AssumeRole-Anfrage und jede Bucket-Auflistung, nicht aber, welche S3-Objekte gelesen wurden. Dafür sind S3-Data-Events oder S3-Server-Access-Logs nötig. Mehreren Opfern fehlten diese Protokolle, sodass sich nicht feststellen ließ, welche Objekte der Angreifer gelesen hatte.

Zur Absicherung empfehlen die Forscher:

• Wurde eine Qubole-Rolle übernommen, alle Secrets, Parameter und Lambda-Umgebungsvariablen rotieren, auf die sie Zugriff hatte, und aktive Sitzungen der Rolle widerrufen – eine Rotation beendet bereits ausgestellte Sitzungen nicht.
• Nicht mehr benötigte Qubole-Rollen löschen oder das Qubole-Konto aus der Trust Policy entfernen.
• Wo Qubole es unterstützt, den kontoweiten :root-Principal durch den konkreten IAM-Principal von Qubole ersetzen.
• Eine Bedingung aws:SourceIp oder aws:SourceVpce ergänzen, die AssumeRole auf die dokumentierten Netzbereiche des Anbieters beschränkt. „Eine Bedingung auf die Quell-IP allein hätte jede von uns beobachtete Rollenübernahme blockiert“, so die Forscher.
• Die External ID nicht als einzige Kontrolle nutzen: Sie wird in CloudTrail im Klartext protokolliert und oft bei Anbietern und in Infrastructure-as-Code-Dateien gespeichert. Nach einem solchen Vorfall sollte sie geändert und möglichst pro Rolle unterschiedlich vergeben werden.
• Die Reichweite jeder Anbieterrolle prüfen. Die Einrichtungsanleitung von Qubole enthält eine Beispiel-S3-Richtlinie, die das Lesen aller Buckets im Konto erlaubt. Laut den Forschern erhalten Anbieterrollen aus Bequemlichkeit oft Zugriff auf Lambda-Einstellungen, Secrets Manager, SSM-Parameter und weitreichende S3-Leserechte.
• Alarme für AssumeRole-Anfragen aus einem Anbieterkonto einrichten, die über ein VPN oder einen bislang nicht genutzten Hoster eintreffen.
• Alle Konten und Regionen mit einem Organization Trail protokollieren und S3-Data-Events oder Server-Access-Logs für Buckets mit sensiblen Daten aktivieren.