Verborgene Gefahr in der Cloud: Schwachstelle in AWS-Organisationen ermöglicht umfassende Kontrolle durch Angreifer

Sicherheitsforscher der Firma Cymulate haben eine kritische Schwachstelle in der Struktur von AWS-Organisationen aufgedeckt. Im Rahmen ihrer Analyse zu Kontowechsel- und Kompromittierungsszenarien stießen sie auf ein gravierendes Problem im Umgang mit delegierten Administratorrechten.

Die Forscher unter der Leitung von Ben Zamir fanden heraus, dass fehlerhaft konfigurierte, zu weit gefasste Richtlinien es Angreifern ermöglichen können, administrative Berechtigungen an von ihnen kontrollierte Konten zu delegieren. Dies eröffnet potenziell die Möglichkeit, zentrale Identitätsdienste zu manipulieren oder Schadsoftware in der gesamten Cloud-Umgebung zu platzieren.

Die technische Ausnutzung der Schwachstelle verläuft in mehreren Schritten und zeigt, wie tiefgreifend der Schaden sein kann. Hat ein Angreifer erst einmal Zugriff auf ein kompromittiertes Management-Konto mit einer unsicheren Richtlinie, kann er etwa mit einem einzigen Befehl ein eigenes Konto als delegierten Administrator innerhalb der Organisation eintragen – ein Einfallstor für vollständige Kontrolle über die Infrastruktur.

Wie die Verkettung von delegierten Administratorrechten mit einer falsch konfigurierten verwalteten Richtlinie die Eskalation von einem kompromittierten Konto zur vollständigen Kontrolle über die AWS-Organisation ermöglichte.

Diese Untersuchung befasst sich mit dem Cross-Account-Pivoting und der Kompromittierung von AWS-Organisationen durch den Missbrauch falsch konfigurierter Delegierungsmechanismen und deckt auf, wie Angreifer legitime Funktionen missbrauchen können, um sich in einer AWS-Umgebung mit mehreren Konten dauerhaft zu etablieren, sich lateral zu bewegen und Berechtigungen zu eskalieren. Darüber hinaus wurde in dieser Untersuchung eine schwerwiegende Sicherheitslücke in der Richtlinie entdeckt, die unter bestimmten Umständen eine vollständige Übernahme der Organisation von einem kompromittierten Mitgliedskonto aus ermöglichen könnte, einschließlich der Kontrolle über das Verwaltungskonto. AWS hat die verwaltete Richtlinie korrigiert, um das subtile Problem mit dem Geltungsbereich zu beheben, und hat proaktiv Kunden benachrichtigt, deren Umgebungen aufgrund einer sehr spezifischen, aber folgenschweren Konfiguration, die diesen Angriffsvektor ausnutzbar machte, möglicherweise gefährdet waren.

Wichtigste Erkenntnisse:

• Obwohl Delegierungsarchitekturen (wie jedes System) als bewährte Vorgehensweise empfohlen werden, können sie bei falscher Konfiguration dennoch anfällig sein, sodass Angreifer Delegierungsmechanismen ausnutzen und den Zugriff auf mehrere Konten erweitern können.
• Konten sollten anhand der ihnen von den delegierten Diensten gewährten Berechtigungen in geeignete Sensitivitätsstufen eingeteilt werden.
• Eine zuvor zu weit gefasste, von AWS verwaltete Richtlinie hätte unter bestimmten Bedingungen die vollständige Kompromittierung der Organisation von einem authentifizierten Zugangspunkt aus ermöglichen können. AWS hat inzwischen eine aktualisierte Richtlinie veröffentlicht, um das Problem zu beheben. Unternehmen sollten sicherstellen, dass nur die korrigierte Version verwendet wird.

Diese Ergebnisse zeigen eine kritische und oft übersehene Angriffsfläche in AWS-Organisationen auf: die Risiken, die mit Delegierungskonfigurationen und falsch festgelegten Berechtigungen verbunden sind. Selbst in gut konzipierten Umgebungen können diese Designentscheidungen unbeabsichtigt Eskalationspfade aus bestehenden Angriffspunkten offenlegen.

Empfohlene Maßnahmen:

1. Alle Delegierungen überprüfen: Delegierte Administratorkonten auflisten und deren Dienstzugriff organisationsweit zuordnen. Behandeln Sie sensible Dienstdelegierungen als Risiko der entsprechenden Stufe.
2. Überwachen Sie Delegierungsereignisse: Verfolgen und melden Sie alle RegisterDelegatedAdministrator-, EnableOrganizationAdminAccount- und damit verbundenen Ereignisse über CloudTrail.
3. Validieren Sie die Gefährdung: Es wird dringend empfohlen, Angriffsszenarien zu simulieren, insbesondere durch Testen von Delegierungskonfigurationen, Pivoting-Techniken und potenziellen organisationsweiten Eskalationspfaden in einer kontrollierten Umgebung, um Transparenz und Abwehrbereitschaft sicherzustellen.
4. Schwachstellen in AWS-verwalteten Richtlinien beheben: Identifizieren Sie alle Prinzipale, die AmazonGuardDutyFullAccess v1 verwenden, und erwägen Sie, wenn möglich, die erneute Zuordnung von v2 oder die Anwendung benutzerdefinierter Richtlinien mit geringsten Berechtigungen.

Das Cymulate Research Labs hat eine Angriffssimulation entwickelt, die den Missbrauch von Fehlkonfigurationen delegierter Administratoren für die organisationsweite Eskalation von Berechtigungen mit einem Ausnutzungsszenario der verwalteten Richtlinie AmazonGuardDutyFullAccess (Version 1) kombiniert. Auf diese Weise können Unternehmen genau sehen, wie ihre Erkennungs- und Präventionskontrollen mit einem solchen Szenario umgehen, sodass sie ihre Kontrollen optimieren können, wenn ihre Abwehrmaßnahmen Lücken aufweisen.

Delegierte Administratoren in AWS: Mehr Flexibilität, aber auch mehr Verantwortung

Mit der Funktion „Delegierter Administrator“ bietet AWS Organizations eine Möglichkeit, bestimmte Verwaltungsaufgaben innerhalb einer Cloud-Organisation gezielt zu verteilen. Statt dass das zentrale Verwaltungskonto alle Aufgaben übernimmt, können ausgewählte Konten für die Steuerung einzelner AWS-Dienste autorisiert werden.

Ziel dieser Funktion ist es, die Abhängigkeit vom hochprivilegierten Management-Konto zu verringern und Verwaltungsverantwortung sicher zu delegieren – etwa an spezialisierte Teams oder Abteilungen. Wird ein Konto einmal als delegierter Administrator für einen Dienst registriert, erhält es organisationsweite Kontrolle über diesen Dienst.

Doch mit der neuen Flexibilität kommen auch sicherheitsrelevante Aspekte ins Spiel: Delegierte Administratoren erhalten automatisch Lesezugriff auf Organisationsdaten wie die Liste aller Konten und Organisationseinheiten (OUs). Dies soll laut AWS die effektive Verwaltung der Dienststruktur ermöglichen – bringt jedoch auch ein erhöhtes Risiko mit sich. Denn solche Konten gelten als besonders sensibel und sollten entsprechend streng überwacht und abgesichert werden.

Weitere Informationen und technische Details zur Rolle des delegierten Administrators stellt AWS in der offiziellen Dokumentation zur Verfügung:
https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_delegated_admin.html

So funktioniert die Delegierung von Administratorrechten in AWS

Die Delegierung von Administratorrechten ist ein zentrales Feature in AWS Organizations, das Organisationen mehr Flexibilität und Sicherheit bei der Verwaltung ihrer Cloud-Dienste bietet. Statt alle Aufgaben über das hochprivilegierte Verwaltungskonto abzuwickeln, können bestimmte Dienste gezielt an andere Konten übertragen werden – sogenannte „delegierte Administratoren“.

Der Einrichtungsprozess erfolgt in zwei Schritten:
Zunächst muss das Verwaltungskonto den sogenannten „vertrauenswürdigen Zugriff“ für den gewünschten AWS-Dienst aktivieren. Dies erlaubt dem Dienst die Integration mit der gesamten Organisation. Technisch geschieht das über den API-Befehl organizations:EnableAWSServiceAccess oder über die entsprechende Einstellung in der AWS-Konsole.

Anschließend wird ein Mitgliedskonto als administrativer Ansprechpartner für den jeweiligen Dienst registriert. Hierbei gibt es zwei gängige Verfahren:

• Dienstspezifische Methode: Einige Dienste wie GuardDuty oder Security Hub bieten eigene APIs, beispielsweise guardduty:EnableOrganizationAdminAccount.

• Zentrales Organisationsmodell: Für andere Dienste, etwa CloudFormation StackSets, kommt die generische Methode organizations:RegisterDelegatedAdministrator zum Einsatz.

Nach erfolgreicher Delegierung erhält das ausgewählte Konto umfassende Verwaltungsrechte für den jeweiligen Dienst – und zwar organisationsweit. Das bedeutet: Identitäten innerhalb dieses Kontos können den Dienst auch in anderen Konten der Organisation zentral steuern.

Zusätzlich erhält das delegierte Konto laut AWS-Dokumentation standardmäßig Lesezugriff auf Organisationsinformationen, etwa die Struktur der Konten und Organisationseinheiten. Dies soll die Übersicht und effiziente Verwaltung erleichtern.

AWS empfiehlt ausdrücklich, das Management-Konto nur sparsam zu verwenden. Stattdessen sollen administrative Aufgaben über delegierte Administratoren verteilt werden. Dieser Ansatz folgt dem Sicherheitsprinzip der „geringstmöglichen Berechtigungen“ und minimiert das Risiko, das mit einem einzigen, allmächtigen Konto verbunden ist.

Hinweis: Ein Benutzerkonto kann standardmäßig die Organisationsstruktur nicht auflisten oder lesen. Durch den Erhalt von Lesezugriff über ein delegiertes Administratorkonto wird die Organisationsstruktur sichtbar (aus Sicht eines Angreifers).

Ressourcenbasierte Delegierung

AWS hat eine weitere Funktion eingeführt, mit der Administratorrechte für die AWS-Organisation delegiert werden können. Im Gegensatz zur dienstspezifischen Delegierung, die vollständige Administratorrechte für diesen Dienst gewährt, verwendet diese Funktion eine fein abgestufte Richtlinienstruktur für die Organisation, um einem Mitgliedskonto eingeschränkte Berechtigungen auf Organisationsebene zu gewähren.

Mit dieser Funktion können einige Aufgaben der Organisationsverwaltung gemeinsam genutzt werden, z. B. das Anzeigen von Kontodetails und Tags sowie die Verwaltung von SCPs aus anderen Konten heraus. Beispielsweise können Sie die Verwaltung von OU-spezifischen SCPs an ein Konto delegieren, das als Richtlinienverwaltungskonto dient. Durch diesen granularen Ansatz können mehreren Konten unterschiedliche Organisationsrechte zugewiesen werden.

Insgesamt sind delegierte Administratoren ein leistungsstarker Mechanismus in AWS-Umgebungen mit mehreren Konten. Sie verbessern zwar die Sicherheit durch die Durchsetzung des Prinzips der geringsten Rechte und die Isolierung des Verwaltungskontos, bringen jedoch auch neue Sicherheitsaspekte und potenzielle Angriffsflächen mit sich. In den folgenden Abschnitten werden wir erläutern, welche Dienste die Delegierung unterstützen, und bekannte Missbrauchspfade untersuchen, wenn die Delegierung missbraucht oder kompromittiert wird.

Delegierungen aus der Perspektive eines Angreifers

Das Verständnis des beabsichtigten Designs und der Implementierung der Delegierung der Kontoverwaltung in AWS Organizations offenbart eine zusätzliche Angriffsfläche und potenzielle Angriffsvektoren. Es ist wichtig zu erkennen, wie diese Funktionen bei falscher Konfiguration oder Kompromittierung ausgenutzt werden können, um einen breiteren Zugriff auf die gesamte Organisation zu erlangen. Wie bereits erwähnt, gewährt die Kontrolle über ein delegiertes Konto vollständige Transparenz über die gesamte Organisation (unabhängig davon, welcher Dienst delegiert wurde), einschließlich des Zugriffs auf das gesamte Konto und die Hierarchie der Organisationseinheiten (OU). Allein dadurch lässt sich die Struktur der Umgebung viel besser verstehen, was die Situationserkennung verbessert und die Definition hochwertiger Ziele sowie die Planung von Vorgehensweisen erleichtert.

Ein delegiertes Administratorkonto verfügt über organisationsweite Berechtigungen für bestimmte Dienste. Angenommen, ein solches Konto wird kompromittiert, insbesondere wenn ein sensibler Dienst delegiert ist. In diesem Fall kann ein Angreifer seinen umfassenden Zugriff auf die gesamte Organisation missbrauchen, Berechtigungen eskalieren und sich lateral auf alle Konten ausbreiten.

Als Red-Teamer ist es bei der Bewertung der Angriffsfläche einer AWS-Organisation von entscheidender Bedeutung, zu ermitteln, welche Mitgliedskonten als delegierte Administratoren für bestimmte Dienste benannt wurden. Delegierte Administratorkonten verfügen per Definition über zusätzliche Berechtigungen, die es einem Angreifer bei Kompromittierung ermöglichen könnten, sich lateral in der Organisation zu bewegen.

Wichtig: Unternehmen klassifizieren delegierte Administratorkonten möglicherweise nicht entsprechend ihrer tatsächlichen Sensibilität, was zu unzureichenden Schutzmaßnahmen führt. Beispielsweise sollte ein delegiertes Konto für AWS IAM Identity Center (ehemals AWS SSO) als Asset der Stufe 0 behandelt werden. Die Kompromittierung solcher Konten kann direkten Zugriff auf Identitätsquellen oder die Infrastrukturautomatisierung gewähren und möglicherweise eine Eskalation von Berechtigungen im gesamten Unternehmen ermöglichen. Diese Funktion erfordert eine strengere Isolierung und Überwachung.

Persistenz und Privilegieneskalation / Quelle.:Cymulate

AWS Identity Center (ehemals SSO)

Das AWS IAM Identity Center ermöglicht eine zentralisierte Zugriffsverwaltung über Konten innerhalb einer AWS-Organisation hinweg, indem Sie Identitäten lokal erstellen und verwalten können:

Grafik Quelle: Cymulate

Mit dem AWS IAM Identity Center können Sie auch eine Verbindung zu bestehenden Identitätsquellen wie Active Directory oder Entra ID herstellen, um Identitäten aus anderen Umgebungen zu replizieren. Darüber hinaus erleichtert es die Erstellung und Verwaltung von Berechtigungssätzen für das gesamte Unternehmen, die Gruppen zugeordnet werden können, und Identitäten können diesen Gruppen entsprechend zugewiesen werden:

Grafik Quelle: Cymulate

Wenn der Identitätscenter-Dienst an ein Konto delegiert wird, kann der Zugriff für die gesamte Organisation verwaltet werden.

Durch Ändern von Berechtigungssätzen und Gruppenmitgliedschaften kann ein Angreifer möglicherweise seinen eigenen Zugriff ändern und so die Berechtigungen für alle Konten innerhalb der Organisation effektiv erweitern.

AWS CloudFormation StackSets

AWS CloudFormation StackSets ermöglichen die Erstellung und Bereitstellung von organisationsweiten Stacks für alle Mitgliedskonten mit Ausnahme des Verwaltungskontos. Die Möglichkeit, StackSets in fast jedem Konto zu erstellen, zu ändern und bereitzustellen, führt zu subtilen, aber leistungsstarken Angriffsvektoren und Persistenzmechanismen.

AWS Service Catalog

Die Verwendung des Zugriffs auf verwendete Portfolios kann eine Eskalation von Berechtigungen über verschiedene Konten hinweg ermöglichen, indem das Portfolio geändert wird, um eine Hintertür zu schaffen.

Eine vollständige Liste finden Sie unter dem folgenden Link: AWS-Services, die Sie mit AWS Organizations verwenden können – AWS Organizations

Beispiel für die Nutzung als Waffe: Ausnutzung von Organisationen: RegisterDelegatedAdministrator-Berechtigung

Angenommen, ein Angreifer erhält Zugriff auf eine Rolle oder einen Benutzer innerhalb des Verwaltungskontos mit der Berechtigung „organizations:RegisterDelegatedAdministrator“. In diesem Fall kann er ein bereits kompromittiertes Konto als delegierten Administrator für sensible Dienste registrieren.

Durch diese Aktion erhält er möglicherweise erweiterte Berechtigungen für die gesamte Organisation und kann in einigen Fällen das Verwaltungskonto weiter kompromittieren.

Hier ein Beispielszenario:

1. Voraussetzung 1: Während des Engagements hat der Angreifer eine Rolle/einen Benutzer im Verwaltungskonto mit dem Verbund „organizations:RegisterDelegatedAdministrator“ kompromittiert.
2. Voraussetzung 2: Der Angreifer hat ein Konto innerhalb der AWS-Organisation kompromittiert. Dazu reicht ein beliebiges Mitgliedskonto aus. Beispielsweise kann die Kompromittierung eines Sandbox-Kontos einfacher sein, da diese Umgebungen in der Regel von der Produktion isoliert sind, keine sensiblen Daten enthalten und Identitäten darin häufig zu Testzwecken mit umfassenden Administratorrechten ausgestattet sind.
3. Hinweis: Die Delegierung ist nur erfolgreich, wenn der ausgewählte Dienst noch nicht delegiert wurde. In diesem Fall darf das Identity Center noch nicht delegiert sein. Ist dies der Fall, sollte ein anderer nicht delegierter sensibler Dienst verwendet werden.
4. Der Angreifer nutzt das Verb, um den Identity Center-Dienst an das kompromittierte Konto zu delegieren.
5. Der Angreifer kann nun SSO, PrivSets und Gruppen innerhalb der Organisation verwalten.
6. Der Angreifer fügt einen kompromittierten Benutzer zu einer Gruppe mit hohen Berechtigungen hinzu oder setzt das Passwort eines Benutzers mit Administratorzugriff auf das Verwaltungskonto zurück.
7. Der Angreifer hat die gesamte Organisation kompromittiert.

Grafik Quelle: Cymulate

Aktueller Status und weitere Vorgehensweise

Nachdem Cymulate das Problem gemeldet hatten, hat AWS Version 2 der betroffenen verwalteten Richtlinie herausgegeben, deren Geltungsbereich eingeschränkt und die Lücke für die Ausweitung von Berechtigungen geschlossen. Da jedoch möglicherweise Produktionsworkflows vorhanden sind, die vom bisherigen Verhalten abhängen, hat AWS die Kunden nicht automatisch auf die neue Richtlinie aktualisiert. Daher werden bestehende Rollen und Benutzer nicht automatisch aktualisiert und verwenden weiterhin Version 1, bis Administratoren die aktualisierte Richtlinie manuell erneut zuweisen. Dadurch bleibt die Organisation bis zur Durchführung der Änderung ungeschützt.

Wichtiger Hinweis: Es ist wichtig, zunächst in einer Nicht-Produktionsumgebung zu testen, um sicherzustellen, dass die neuere Version 2 die derzeit erforderlichen Berechtigungen nicht beeinträchtigt.

Was AWS behoben hat: Veröffentlichung der verwalteten Richtlinie v2 mit strengeren Ressourcenbeschränkungen, die den Eskalationspfad eliminieren.

Was sich nicht geändert hat: Rollen und Benutzer, die bereits mit v1 verknüpft sind, werden nicht automatisch aktualisiert. AWS hat potentiell betroffene Kunden proaktiv benachrichtigt.

Was ist das Risiko: Alle Anhänge, die noch auf v1 verweisen, behalten die übermäßigen Berechtigungen und das Risiko einer Übernahme der gesamten Organisation.

Zusammenfassung

Eine falsch festgelegte Aktion in der veralteten AWS-verwalteten Richtlinie „AmazonGuardDutyFullAccess“ ermöglicht es jedem Prinzipal im Verwaltungskonto, das diese Richtlinie enthält, einen beliebigen delegierten Administrator für jeden in Organizations integrierten Dienst zu registrieren. Durch die Verkettung mit hochprivilegierten Diensten wie IAM Identity Center (SSO) oder CloudFormation StackSets kann ein Angreifer von einem einzelnen kompromittierten Benutzer oder einer Rolle des Verwaltungskontos die vollständige Kontrolle über alle Konten in der Organisation erlangen, einschließlich Persistenzmechanismen.

Quelle: Cymulate

---