Atacante verwendet Qubole AWS Anmeldeinformationen, um Rollen in Kundenkonten zu übernehmen und Geheimnisse zu stehlen

Zwischen dem 14. und 26. Oktober nutzte ein Angreifer die Anmeldeinformationen, die mit dem AWS-Konto verbunden sind, und nutzte die Qubole-Plattform, um auf die Umgebungen mehrerer Kunden zuzugreifen und nach der Analyse von Wiz-Forschern Geheimnisse und Daten zu extrahieren. Die verwendete Methode bestand darin, Rollen (AssumeRole) anzunehmen, die Kunden geschaffen hatten, um Qubole innerhalb ihrer Konten handeln zu lassen; diese Rollen vertrauten dem Qubole-Account (ID 805246085872) und forderten eine externe ID, die in diesem Fall der Angreifer korrekt einschließen konnte. Die Forscher dokumentieren auch die frühere Tätigkeit, zwischen dem 8. und 11. Oktober, in der ein anderer Schauspieler - oder möglicherweise das gleiche mit einer anderen Technik - AWS-Zugriffsschlüssel von Kunden verwendet, die für Qubole konfiguriert wurden; diese vorläufige Phase war mit Verpflichtungen in einigen Umgebungen verbunden, aber nicht öffentlich mit dem Missbrauch von AssumeRole, der gefolgt wurde.

Fakten bestätigt: Wiz veröffentlichte einen technischen Bericht, der die Kampagne detailliert beschreibt, und die Untersuchung wurde nach Warnungen von Sentra eingeleitet. Der Angreifer las Lambda-Funktions-Umgebungsvariablen, extrahierte Geheimnisse des AWS Secrets Managers, erhielt Parameter aus dem SSM Parameter Store und heruntergeladene S3 Objekte - manchmal durch das Herunterladen eines gesamten Buckets, wenn die Rolle erlaubt. Um entfernte Anmeldeinformationen zu validieren, verwendet der Angreifer automatisierte Werkzeuge wie TruffleHog. Darüber hinaus identifizierten die Forscher reproduzierbare Betriebssignaturen: das Qubole 8052460872-Konto, zwei relevante Haupt-IAM-IDs (AIDA3W7DIFLYOLTK63SFS, die mit dem Angreifer in den untersuchten Fällen verbunden waren, und AIDAJYRH5Y3A7AAAJM2HW, die von Qubole und auch von dem Angreifer seit 18 Oktober bekannt waren), öffentliche IP-Adressen an OV20

Was erlaubten Zugang und warum es funktionierte: Technisch arbeitet Qubole innerhalb des Kundenkontos durch eine IAM-Rolle, deren Vertrauenspolitik es dem Qubole-Konto ermöglicht, die Rolle zu übernehmen. AWS bestätigt, dass die Anwendung von AssumeRole aus dem zuverlässigen Konto kommt und dass die externe ID übereinstimmt. Das Hauptproblem bei diesem Vorfall war nicht eine Verwundbarkeit in AWS, aber die Anmeldeinformationen, die der Angreifer auf der Seite des Lieferanten hatte (das Qubole-Konto) könnte verwendet werden, um gültige Anwendungen für Rollen, die noch konfiguriert sind, um dieses Konto zu vertrauen. Darüber hinaus ist die externe ID nicht geheim nach AWSs eigener Anleitung: sie wird in CloudTrail aufgezeichnet und ist in Infrastrukturdateien und Vorlagen sichtbar, so dass ihr Wissen durch den Angreifer nicht überraschend ist. Weitere technische Details und allgemeine Empfehlungen zum Verkauf von Rollen finden Sie auf der Wiz-Forschungsseite und der AWS-Dokumentation auf Externer ID ( Wiz Forschung, AWS Externe ID Anleitung)

Für wen sie sich auswirkt und praktischen Umfang: jede Organisation, die Qubole eine IAM-Rolle gegeben hat, auch wenn sie die Plattform nicht mehr aktiv nutzt, ist möglicherweise betroffen. In den untersuchten Umgebungen suchte und nutzte der Angreifer Geheimnisse, die andere Ressourcen und Dienstleistungen entsperren könnten: AWS-Zugriffsschlüssel (die einen direkten Betrieb der API erlauben), Identitätsanbieter Geheimnisse (z.B. eingeben / Okta) und Bewerbungsinformationen. Bei fehlenden detaillierten S3 (S3-Datenereignisse oder Server-Zugriffsprotokollen) konnten die Antwortteams nicht genau bestimmen, welche Objekte gelesen oder kopiert wurden, wodurch das Risiko einer Exposition sensibler Informationen erhöht wurde.

Welche Teile der Geschichte sind noch nicht öffentlich bestätigt: Wiz und die Ermittler haben nicht öffentlich erklärt, wie die Anmeldeinformationen, die dem Angreifer erlaubten, aus dem Qubole-Account zu operieren, zunächst erhalten wurden oder ob diese Anmeldeinformationen bereits widerrufen wurden; weder hatte Qubole noch seine Idera-Matrix zum Zeitpunkt der Überprüfung eine öffentliche Erklärung abgegeben. Es gibt keine öffentliche und bestätigte Verbindung zwischen dieser Kampagne und anderen wichtigen Vorfällen oder schlüssigen Beweisen, dass es sich um eine Operation handelt, die von einem Schauspielerstaat gesponsert wird; Wiz stellt fest, dass die Ziele nicht dem üblichen Muster staatlicher Gruppen entsprechen.

Tatsächliche und potenzielle Folgen: Die Exposition von Geheimnissen und Zugangsschlüsseln kann den seitlichen Kletterangreifer innerhalb von Konten, Beharrlichkeit durch neue Anmeldeinformationen oder Integrationen, Datendiebstahl und in Umgebungen, die mit anderen Wolken oder SaaS, Engagement von föderierten Identitäten integriert. Der Mangel an detaillierten Aufzeichnungen macht es unmöglich, das genaue Ausmaß der Exfiltration in allen Betroffenen zu bestimmen, was die Reaktion und Vermittlung erschwert.

Spezifische und unmittelbare Maßnahmen, die von den von Qubole mit AWS betroffenen oder verwendeten Geräten zu treffen sind: zunächst, verfolgen Sie die Ereignisse in CloudTrail ab 1. Oktober auf der Suche nach AssumeRole, wo Sie Identity.accountId = 805246085872 und Source IPAddress ist keine AWS Adresse; untersuchen Sitzungen, deren Sitzung mit "quiam-", genannt GetCallerIdentity mit user-agent Truffleg und Aktivität von den von den Forschern identifizierten PIs. Aktivieren Sie eine umfassende Überprüfung der Secrets Manager, SSM Parameter Store, Lambda-Umgebungsvariablen und S3 Lesegenehmigungen, die die Rolle erreichen könnte; rollen Sie sofort alle Anmeldeinformationen (Zugriffsschlüssel, Anwendungsgeheimnisse, Clientgeheimnisse), denen die Rolle Sichtbarkeit und Änderung von Passwörtern oder externen Token, die möglicherweise ausgesetzt wurden. Beachten Sie, dass das Verdrehen eines Geheimnisses, das die bereits ausgestellten Zeitsitzungen nicht ungültig macht; um aktive Sitzungen zu blockieren, die Vertrauenspolitik der Rolle zu entfernen oder zu ändern (z.B. durch Entfernen des Qubole-Kontos aus der Treuhandpolitik oder durch Ersetzen des Hauptkontos durch die spezifische MIU, die der Lieferant dokumentiert) und gegebenenfalls Löschen von Rollen, die nicht verwendet werden. Fügen Sie Bedingungen für die Treuhandpolitik, wie aws: Quelle Ip oder aws: SourceVpce, um zu begrenzen, wo die Rollen angenommen werden können - Forscher zeigen, dass in diesem Fall eine IP-Bedingung die beobachteten Annahmen blockiert hätte. Ergänzen Sie einen Organisationspfad und aktivieren Sie S3 Datenereignisse oder dienen Sie Zugriffsprotokollen in sensiblen Eimern, um zukünftige Objektdaten zu überprüfen (siehe CloudTrail Anleitung: AWS Auf der Karte anzeigen)

Schließlich überprüfen und verringern Sie den Umfang der Genehmigungen, die Dritten Rollen gewährt werden: Es ist üblich, die Rolle der Lieferanten mit breiter Lesegenehmigung auf S3, Zugriff auf Secrets Manager und SSM-Parameter "für Bequemlichkeit" zu sehen; begrenzen Sie diese Genehmigungen auf das erforderliche Minimum und setzen Alarme für AssumeRole aus VPS, Hosting-Netzwerke oder VPN PIs nicht vom Lieferanten dokumentiert. Diese Maßnahmen gewährleisten nicht, dass ein vergangenes Engagement keine Konsequenzen mehr hat, sondern das Fenster des zukünftigen Missbrauchs drastisch reduziert und Eindämmung und Audit erleichtert.

Dieser Vorfall unterstreicht, dass das Cross-Trust zwischen Konten und der Verwaltung von Anmeldeinformationen in der Herstellerintegration spezifische Richtlinien und Aufzeichnungen erfordern: Es reicht nicht aus, den Zugang zu delegieren, es ist notwendig, ihn umzusetzen und proaktiv einzuschränken. Halten Sie sich auf offizielle Qubole- oder Idera-Kommunikation und Wiz- technischen Berichten für zusätzliche Updates und Erkennungen im Auge.