Von Mauricio Payne, Sicherheitsanalyst bei Bureau Veritas Cybersecurity

Kompromittierung der Azure-Cloud über sensible API-Berechtigungen

Kürzlich haben die Forscher von Cloudbrothers eine interessante neue Möglichkeit gefunden, von einer lokalen Umgebung in eine Azure-Umgebung zu wechseln und globale Admin-Rechte zu erhalten. In diesem Blog werden wir Ihnen diesen Angriff demonstrieren und erklären. Außerdem stellen wir Ihnen einige Maßnahmen vor, mit denen Sie diesen Angriff erkennen und sich davor schützen können.

Demonstration des Angriffsplans

Forscher von Cloudbrothers entdeckten, dass ein Angreifer, der in der Lage war, das vom AD Connect-Server verwendete AAD Sync-Konto zu kompromittieren, seine Privilegien zum Global Admin ausweiten konnte, indem er Anwendungen mit sensiblen Rechten ausnutzte.

Dies ist möglich, weil das AAD Sync-Konto sowohl über die Berechtigungen 'microsoft.directory/applications/owners/update' als auch 'microsoft.directory/servicePrincipals/owners/update' verfügt. Damit kann es die Eigentümer von registrierten Anwendungen aktualisieren.

Außerdem kann dieses Konto mit der Berechtigung'microsoft.directory/servicePrincipals/credentials/update' direkt Anmeldedaten zu diesen Anwendungen hinzufügen, ohne sich selbst als Eigentümer hinzufügen zu müssen.

Diese Anwendungen können dann zur Eskalation der Privilegien verwendet werden, wenn sie über die entsprechenden Berechtigungen verfügen.

In diesem Blog konzentrieren wir uns auf zwei dieser sensiblen Berechtigungen ('RoleManagement.ReadWrite.Directory' und'AppRoleAssignment.ReadWrite.All') und demonstrieren den Angriffsplan, den ein Angreifer durchlaufen müsste, indem wir die einzelnen Schritte beschreiben.

BEVOR WIR BEGINNEN

Bevor wir beginnen, ist es wichtig, einige der Annahmen zu erörtern, die zur Durchführung dieses Angriffs erforderlich sind.

Die erste Annahme ist, dass es eine auf Azure registrierte Anwendung gibt, die eine der beiden oben erwähnten sensiblen Berechtigungen enthält.

Die zweite Annahme ist, dass es Ihnen gelungen ist, den Server, auf dem AD Connect läuft, vollständig zu kompromittieren und die Anmeldeinformationen für das AAD Sync-Konto zu erbeuten. Sie können die Anmeldeinformationen auf verschiedene Weise auslesen, zum Beispiel mit dem PowerShell-Modul AADInternals. Die Verwendung von Get-AADIntSyncCredentials auf dem AD Connect-Server liefert die Anmeldeinformationen für den AAD Sync-Benutzer:

Sobald diese Anmeldedaten erfasst sind, können wir mit dem eigentlichen Hauptangriff fortfahren. Der erste Schritt besteht darin, sich beim Mandanten als AAD Sync-Benutzer zu authentifizieren:

Mit diesem JWT-Token können wir nun die Microsoft Graph API aufrufen und eine Liste aller registrierten Anwendungen auf dem Tenant erhalten. Dieses JWT-Token kann in einer PowerShell-Variablen gespeichert werden, die als Authentifizierungs-Header verwendet werden kann:

$AuthHeader = @{Authorisation = "Bearer <JWT>"}

Auf diese Weise können wir dann mit PowerShell eine Anfrage an den Endpunkt beta/applications stellen:

Invoke-RestMethod -Headers $AuthHeader -Uri "https://graph.microsoft.com/beta/applications/"

Die folgende Abbildung zeigt die Antwort auf die Anfrage an den Endpunkt beta/applications, der alle registrierten Anwendungen enthält.

Wenn wir uns diese Antwort ansehen, sehen wir eine Menge Informationen über die verschiedenen Anwendungen. Was für uns bei diesem Angriff jedoch wichtig ist, ist das Feld"appID". Diese IDs sollten in einer Liste gespeichert werden, da sie für den nächsten Schritt des Angriffs benötigt werden. In diesem Schritt werden wir die appID verwenden, um eine Anfrage an die Graph API zu stellen und abzufragen, welche Service Principals zu dieser Anwendung gehören.

Unten sehen wir die Antwort auf eine solche Anfrage, die die ID des Service Principals enthält, der zur Anwendung mit der appID 8c3ffdc3-fe9d-47a2-9bbc-3bc49e486c43 gehört. Diese Anfrage kann über die PowerShell mit dem folgenden Befehl ausgeführt werden:

Invoke-RestMethod -Headers $AuthHeader -Uri "https://graph.microsoft.com/beta/servicePrincipals/?`$filter=(appid eq '<appID>')"

Sobald wir die ID dieser Service-Principals haben, können wir nach den ihnen zugewiesenen Rechten suchen. Konkret suchen wir nach einem Recht mit einer appRoleID von "9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8", was der Rolle RoleManagement.ReadWrite.Directory entspricht, oder der appRoleID von "06b708a9-e830-4db3-a914-8e69da51d44f", was der Rolle AppRoleAssignment.ReadWrite.All entspricht.

ROLEMANAGEMENT.READWRITE.DIRECTORY

Die Rolle RoleManagement.ReadWrite.Directory ermöglicht es der Anwendung, sich selbst, anderen Anwendungen oder beliebigen Benutzern zusätzliche Privilegien zu gewähren. Mit der folgenden Anfrage können wir sehen, welche Privilegien dem Dienstprinzipal mit der ID: "9e666f83-8520-4c65-a8e2-e929194839ea" zugewiesen wurden.

Invoke-RestMethod -Headers $AuthHeader -Uri "https://graph.microsoft.com/beta/servicePrincipals/<ServicePrincipalID>/appRoleAssignments"

In der Abbildung unten sehen Sie die Antwort auf die obige Anfrage. In der Antwort sehen wir die oben erwähnte appRoleId, die diese Anwendung anfällig für diesen Angriff macht.

Sobald wir eine Anwendung gefunden haben, die über diese Rolle verfügt, können wir unseren Benutzer (in diesem Fall den AAD Sync-Benutzer) als Eigentümer dieses Dienstprinzipals hinzufügen. In PowerShell würde die Anfrage wie folgt aussehen:

$Reference = @{ "@odata.id" = "https://graph.microsoft.com/beta/directoryObjects/" + <AAD Sync userID> } | | ConvertTo-Json

Invoke-RestMethod -Method Post -Headers $AuthHeader -Uri "https://graph.microsoft.com/beta/servicePrincipals/<ServicePrincipalToTakeover>/owners/`$ref" - Body $Reference -ContentType "application/json" | Out-Null

Die Antwort auf diese Anfrage würde wie folgt aussehen:

Der nächste Schritt besteht darin, dem Dienstprinzipal ein neues Geheimnis hinzuzufügen, das wir später zur Authentifizierung beim Tenant verwenden werden, wenn diese anfällige Anwendung. Es wird eine POST-Anfrage an die Graph-API gestellt, die automatisch ein sicheres Passwort festlegt und es im Parameter "secretText" zurückgibt. Dies geschieht mit dem folgenden PowerShell-Befehl:

Invoke-RestMethod -Method Post -Headers $AuthHeader -Uri "https://graph.microsoft.com/beta/servicePrincipals/" -Body $Reference -ContentType "application/json"

Wie unten gezeigt, gibt die API den secretText zurück:

Indem wir die appID der gefährdeten Anwendung als "Client_Id" und das neu hinzugefügte Geheimnis als "Client_Secret" verwenden, können wir uns beim Tenant als dieser Service Principal authentifizieren und ein neues JWT-Token erhalten.

APPROLEASSIGNMENT.READWRITE.ALL

Die Rolle AppRoleAssignment.ReadWrite.All ermöglicht es der Anwendung, sich selbst zusätzliche Privilegien zu gewähren. Das bedeutet, dass wir der Anwendung die Rolle RoleManagement.ReadWrite.Directory zuweisen und Global Admin-Rechte erhalten können. Unten sehen Sie ein Bild, in dem wir eine anfällige Anwendung mit dieser Rolle identifizieren:

Sobald wir diese Anwendung identifiziert haben, können wir ihr ein Geheimnis hinzufügen, mit dem wir uns als Anwendung beim Azure-Mandanten authentifizieren können:

Wie Sie bereits gesehen haben, wird das Kennwort als Parameter "secretText" zurückgegeben, den wir in Kombination mit der appID zur Authentifizierung beim Mandanten verwenden werden:

Dies gibt ein JWT-Token zurück, das, wie wir sehen können, bei der Dekodierung nur die Rolle"AppRoleAssignment.ReadWrite.All" enthält:

Wenn wir dieses JWT-Token als neues Autorisierungs-Token verwenden, können wir der Anwendung die gewünschte Rolle hinzufügen. Dazu müssen wir die appRoleID der Rolle, die wir hinzufügen möchten, die principalId und die resourceId kennen. Die Anfrage zum Hinzufügen der Rolle RoleManagement.ReadWrite.Directory kann mit den folgenden PowerShell-Befehlen durchgeführt werden:

$params = @{
principalId = <servicePrincipalId>
resourceId = <resourceId>
appRoleId = "9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8"
} ConvertTo-Json

Invoke-RestMethod -Method POST -Headers $AppAuthHeader -Uri "https://graph.microsoft.com/v1.0/servicePrincipals/ <servicePrincipalId>/appRoleAssignments" - Body $params -ContentType "application/json"

Jetzt können wir uns mit demselben Passwort, das wir zuvor hinzugefügt haben, erneut bei der Anwendung authentifizieren. Anhand des neu generierten JWT-Tokens können wir sehen, dass unsere neue Rolle erfolgreich angewendet wurde:

Sie können dies auch über das Azure-Portal überprüfen, indem Sie die Anwendung besuchen:

BENUTZER ALS GLOBALEN ADMINISTRATOR HINZUFÜGEN

Dieses neue JWT ermöglicht es uns, Anfragen als Dienstprinzipal zu stellen. Da es über die Rolle RoleManagement.ReadWrite.Directory verfügt, können wir damit einem Benutzer die Rolle Global Admin zuweisen. In PowerShell geschieht dies, indem Sie die Variable AppAuthHeader auf das neue JWT-Token aktualisieren und die folgenden Befehle ausführen:

$Reference = @{ "@odata.id" = "https://graph.microsoft.com/beta/directoryObjects/" + <UserIDToMakeGlobalAdmin> } } | ConvertTo-Json

Invoke-RestMethod -Method Post -Headers $AppAuthHeader -Uri "https://graph.microsoft.com/beta/directoryRoles/roleTemplateId=62e90394-69f5-4237-9190- 012177145e10/members/`$ref" -Body $Reference -ContentType "application/json"

Im Azure-Portal sehen wir, dass unser Benutzer jetzt zu den globalen Administratoren gehört:

MITIGATIONS

Wenn es darum geht, diesen Angriff zu entschärfen, gibt es keine pauschale Antwort. Es gibt jedoch bestimmte Maßnahmen, die ergriffen werden können, um die Erfolgsquote dieses Angriffs zu verringern.

Die erste und offensichtlichste ist, die Verwendung sensibler Rollen wie RoleManagement.ReadWrite.Directory einzuschränken. In einigen Fällen sind diese Rollen erforderlich; in diesen Szenarien ist es am besten, diese Anwendungen genau zu überwachen und automatische Antworten für den Fall eines anomalen Verhaltens bereit zu haben.

Darüber hinaus würde die Verwendung von Zugangskontrollen die Erfolgsaussichten dieses Angriffs über das Internet verringern. Dies könnte z.B. dadurch geschehen, dass Sie nur Anmeldungen für das AAD Sync-Konto von Ihrem Firmensitz aus zulassen. Jede Unregelmäßigkeit könnte dann dazu verwendet werden, einen Alarm auszulösen und Sie über einen potenziell bösartigen Anmeldeversuch zu informieren. Wie in diesem Beispiel gezeigt, könnte ein Angreifer, der den AD Connect-Server kompromittiert hat, diese Zugriffsrichtlinie jedoch umgehen, indem er den Angriff vom AD Connect-Server aus startet.

Darüber hinaus sollten auf dem AD Connect Server Sicherheitsmaßnahmen eingerichtet werden, um die Art der Aktionen, die auf dem Server durchgeführt werden können, zu überwachen und einzuschränken. Ein Beispiel hierfür wäre die Blockierung der Verwendung von Tools wie AADInternals.

Der springende Punkt bei diesen Abhilfemaßnahmen ist, dass es keine einzelne Lösung für diesen Angriff gibt. Stattdessen sollte es mehrere Verteidigungsschichten geben, die einen Angreifer hoffentlich aufhalten, bevor er überhaupt Zugriff auf den AD Connect-Server erhält.

Weitere Informationen zu diesem Angriff finden Sie hier:

https://cloudbrothers.info/en/prem-global-admin-password-reset/
https://cloudbrothers.info/en/azure-attack-paths/#api-permissions
https://posts.specterops.io/azure-privilege-escalation-via-azure-api-permissions-abuse-74aee1006f48

ÜBER SECURA

Bureau Veritas Cybersecurity ist ein führendes Unternehmen im Bereich der Cybersicherheit. Unsere Kunden reichen von Behörden und dem Gesundheitswesen bis hin zum Finanzwesen und der Industrie. Secura bietet technische Dienstleistungen wie Schwachstellenbewertungen, Penetrationstests und Red Teaming. Außerdem bieten wir Zertifizierungen für IoT- und Industrieumgebungen sowie Audits, forensische Dienstleistungen und Sensibilisierungsschulungen an.

Unser Ziel ist es, Ihre Cyber-Resilienz zu erhöhen. Wir sind ein Unternehmen von Bureau Veritas. Bureau Veritas (BV) ist ein börsennotiertes Unternehmen, das sich auf Tests, Inspektionen und Zertifizierungen spezialisiert hat. Das 1828 gegründete Unternehmen hat über 80.000 Mitarbeiter und ist in 140 Ländern tätig. Bureau Veritas Cybersecurity ist der Eckpfeiler der Cybersicherheitsstrategie von Bureau Veritas.