GCP <--> Workspace Pivoting
Last updated
Last updated
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Die domänenweite Delegation von Google Workspace ermöglicht es einem Identitätsobjekt, entweder einer externen App aus dem Google Workspace Marketplace oder einem internen GCP-Dienstkonto, Daten im gesamten Workspace im Namen von Benutzern zuzugreifen.
Das bedeutet im Grunde, dass Dienstkonten innerhalb von GCP-Projekten einer Organisation in der Lage sein könnten, Workspace-Benutzer derselben Organisation (oder sogar einer anderen) zu imitieren.
Für weitere Informationen darüber, wie dies genau funktioniert, siehe:
GCP - Understanding Domain-Wide DelegationWenn ein Angreifer Zugriff auf GCP kompromittiert hat und eine gültige Workspace-Benutzer-E-Mail (vorzugsweise Super Admin) des Unternehmens kennt, könnte er alle Projekte auflisten, auf die er Zugriff hat, alle SAs der Projekte auflisten, überprüfen, auf welche Dienstkonten er Zugriff hat, und alle diese Schritte mit jedem SA wiederholen, den er imitieren kann. Mit einer Liste aller Dienstkonten, auf die er Zugriff hat, und der Liste der Workspace E-Mails könnte der Angreifer versuchen, Benutzer mit jedem Dienstkonto zu imitieren.
Beachte, dass bei der Konfiguration der domänenweiten Delegation kein Workspace-Benutzer benötigt wird, daher reicht es aus, einen gültigen zu kennen, um die Imitation durchzuführen. Die Befugnisse des imitierten Benutzers werden jedoch verwendet, also wenn es ein Super Admin ist, wirst du Zugriff auf alles haben. Wenn es keinen Zugriff hat, wird dies nutzlos sein.
Dieses einfache Skript wird ein OAuth-Token als der delegierte Benutzer generieren, das du dann verwenden kannst, um auf andere Google APIs mit oder ohne gcloud zuzugreifen:
Dies ist ein Tool, das den Angriff nach diesen Schritten durchführen kann:
GCP-Projekte auflisten mit der Resource Manager API.
Iteriere über jede Projektressource und enumerate GCP-Dienstkonto-Ressourcen, auf die der ursprüngliche IAM-Benutzer Zugriff hat, unter Verwendung von GetIAMPolicy.
Iteriere über jede Dienstkonto-Rolle und finde integrierte, grundlegende und benutzerdefinierte Rollen mit der Berechtigung serviceAccountKeys.create auf der Ziel-Dienstkonto-Ressource. Es sollte beachtet werden, dass die Editor-Rolle diese Berechtigung von Natur aus besitzt.
Erstelle einen neuen KEY_ALG_RSA_2048 privaten Schlüssel für jede Dienstkonto-Ressource, die mit der relevanten Berechtigung in der IAM-Richtlinie gefunden wurde.
Iteriere über jedes neue Dienstkonto und erstelle ein JWT Objekt dafür, das aus den SA-Privatschlüssel-Anmeldeinformationen und einem OAuth-Bereich besteht. Der Prozess zur Erstellung eines neuen JWT Objekts wird alle bestehenden Kombinationen von OAuth-Bereichen aus der oauth_scopes.txt Liste durchlaufen, um alle Delegationsmöglichkeiten zu finden. Die Liste oauth_scopes.txt wird mit allen OAuth-Bereichen aktualisiert, die wir als relevant für den Missbrauch von Workspace-Identitäten erachtet haben.
Die Methode _make_authorization_grant_assertion zeigt die Notwendigkeit an, einen Ziel-Workspace-Benutzer zu deklarieren, der als subject bezeichnet wird, um JWTs unter DWD zu generieren. Während dies spezifisch erscheinen mag, ist es wichtig zu erkennen, dass DWD jede Identität innerhalb einer Domain beeinflusst. Folglich hat die Erstellung eines JWT für jeden Domain-Benutzer Auswirkungen auf alle Identitäten in dieser Domain, was mit unserer Kombinationen-Enumeration-Überprüfung übereinstimmt. Einfach ausgedrückt, ein gültiger Workspace-Benutzer reicht aus, um fortzufahren.
Dieser Benutzer kann in DeleFriend’s config.yaml Datei definiert werden. Wenn ein Ziel-Workspace-Benutzer noch nicht bekannt ist, erleichtert das Tool die automatische Identifizierung gültiger Workspace-Benutzer, indem es Domain-Benutzer mit Rollen auf GCP-Projekten scannt. Es ist wichtig zu beachten (nochmals), dass JWTs domainspezifisch sind und nicht für jeden Benutzer generiert werden; daher zielt der automatische Prozess auf eine einzige eindeutige Identität pro Domain ab.
Enumerate und erstelle ein neues Bearer-Zugriffstoken für jedes JWT und validiere das Token gegen die tokeninfo API.
Gitlab hat dieses Python-Skript erstellt, das zwei Dinge tun kann - das Benutzerverzeichnis auflisten und ein neues Administratorkonto erstellen, während es ein JSON mit SA-Anmeldeinformationen und dem Benutzer angibt, den man nachahmen möchte. So würden Sie es verwenden:
Es ist möglich, Domain Wide Delegations in https://admin.google.com/u/1/ac/owl/domainwidedelegation** zu überprüfen.**
Ein Angreifer mit der Fähigkeit, Dienstkonten in einem GCP-Projekt zu erstellen und Super-Admin-Rechten für GWS könnte eine neue Delegation erstellen, die es SAs ermöglicht, einige GWS-Benutzer zu impersonieren:
Generierung eines neuen Dienstkontos und des entsprechenden Schlüsselpaares: In GCP können neue Dienstkonto-Ressourcen entweder interaktiv über die Konsole oder programmgesteuert mithilfe direkter API-Aufrufe und CLI-Tools erstellt werden. Dies erfordert die Rolle iam.serviceAccountAdmin oder eine benutzerdefinierte Rolle, die mit der iam.serviceAccounts.create Berechtigung ausgestattet ist. Sobald das Dienstkonto erstellt ist, fahren wir fort, ein verwandtes Schlüsselpaar zu generieren (iam.serviceAccountKeys.create Berechtigung).
Erstellung einer neuen Delegation: Es ist wichtig zu verstehen, dass nur die Super-Admin-Rolle die Fähigkeit hat, globale Domain-Wide-Delegationen in Google Workspace einzurichten und Domain-Wide-Delegationen können nicht programmgesteuert eingerichtet werden. Sie können nur manuell über die Google Workspace Konsole erstellt und angepasst werden.
Die Erstellung der Regel kann auf der Seite API-Kontrollen → Domain-Wide-Delegation in der Google Workspace Admin-Konsole verwalten gefunden werden.
Anfügen von OAuth-Scopes-Berechtigungen: Bei der Konfiguration einer neuen Delegation benötigt Google nur 2 Parameter, die Client-ID, die die OAuth-ID des GCP-Dienstkontos ist, und OAuth-Scopes, die definieren, welche API-Aufrufe die Delegation benötigt.
Die vollständige Liste der OAuth-Scopes finden Sie hier, aber hier ist eine Empfehlung: https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/admin.directory.group, https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.domain, https://mail.google.com/, https://www.googleapis.com/auth/drive, openid
Im Namen der Zielidentität handeln: An diesem Punkt haben wir ein funktionierendes delegiertes Objekt in GWS. Jetzt können wir mit dem privaten Schlüssel des GCP-Dienstkontos API-Aufrufe durchführen (im Bereich, der im OAuth-Scopes-Parameter definiert ist), um es auszulösen und im Namen jeder Identität zu handeln, die in Google Workspace existiert. Wie wir gelernt haben, generiert das Dienstkonto Zugriffstoken nach Bedarf und gemäß den Berechtigungen, die es für REST-API-Anwendungen hat.
Überprüfen Sie den vorherigen Abschnitt für einige Tools, um diese Delegation zu nutzen.
Die OAuth SA-ID ist global und kann für Cross-Organizational Delegation verwendet werden. Es wurden keine Einschränkungen implementiert, um eine cross-global Delegation zu verhindern. Einfach ausgedrückt, können Dienstkonten aus verschiedenen GCP-Organisationen verwendet werden, um eine domainweite Delegation in anderen Workspace-Organisationen zu konfigurieren. Dies würde bedeuten, dass nur Super-Admin-Zugriff auf Workspace erforderlich ist und nicht der Zugriff auf dasselbe GCP-Konto, da der Angreifer Dienstkonten und private Schlüssel in seinem persönlich kontrollierten GCP-Konto erstellen kann.
Standardmäßig haben Workspace-Benutzer die Berechtigung, neue Projekte zu erstellen, und wenn ein neues Projekt erstellt wird, erhält der Ersteller die Rolle Owner über dieses.
Daher kann ein Benutzer ein Projekt erstellen, die APIs aktivieren, um Workspace in seinem neuen Projekt aufzulisten, und versuchen, es zu enumerieren.
Damit ein Benutzer Workspace auflisten kann, benötigt er auch genügend Workspace-Berechtigungen (nicht jeder Benutzer kann das Verzeichnis auflisten).
Überprüfen Sie weitere Aufzählungen in:
GCP - IAM, Principals & Org Policies EnumSie finden weitere Informationen zum gcloud-Fluss für die Anmeldung in:
Wie dort erklärt, kann gcloud den Scope https://www.googleapis.com/auth/drive anfordern, der es einem Benutzer ermöglichen würde, auf das Laufwerk des Benutzers zuzugreifen.
Als Angreifer, wenn Sie den Computer eines Benutzers physisch kompromittiert haben und der Benutzer noch mit seinem Konto angemeldet ist, könnten Sie sich anmelden, indem Sie ein Token mit Zugriff auf das Laufwerk generieren mit:
Wenn ein Angreifer den Computer eines Benutzers kompromittiert, könnte er auch die Datei google-cloud-sdk/lib/googlecloudsdk/core/config.py ändern und in die CLOUDSDK_SCOPES den Scope 'https://www.googleapis.com/auth/drive' hinzufügen:
Daher wird der Benutzer beim nächsten Login ein Token mit Zugriff auf Drive erstellen, das der Angreifer missbrauchen könnte, um auf Drive zuzugreifen. Offensichtlich wird der Browser anzeigen, dass das generierte Token Zugriff auf Drive hat, aber da der Benutzer selbst gcloud auth login aufruft, wird er wahrscheinlich nichts Verdächtiges ahnen.
Um Drive-Dateien aufzulisten: curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"
Wenn ein Angreifer vollständigen Zugriff auf GWS hat, kann er auf Gruppen mit privilegiertem Zugriff auf GCP oder sogar auf Benutzer zugreifen. Daher ist der Übergang von GWS zu GCP normalerweise "einfacher", nur weil Benutzer in GWS hohe Privilegien über GCP haben.
Standardmäßig können Benutzer frei in Workspace-Gruppen der Organisation beitreten, und diese Gruppen könnten GCP-Berechtigungen zugewiesen haben (überprüfen Sie Ihre Gruppen unter https://groups.google.com/).
Durch den Missbrauch der Google Groups Privesc könnten Sie in der Lage sein, zu einer Gruppe mit einer Art von privilegiertem Zugriff auf GCP zu eskalieren.
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
