mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-30 22:50:43 -08:00
Translated ['src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting
This commit is contained in:
Translator
@@ -6,10 +6,10 @@
|
||||
|
||||
### **Grundlagen der domänenweiten Delegation**
|
||||
|
||||
Die domänenweite Delegation von Google Workspace ermöglicht 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**.
|
||||
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**.
|
||||
|
||||
> [!NOTE]
|
||||
> Das bedeutet im Grunde, dass **Dienstkonten** innerhalb von GCP-Projekten einer Organisation in der Lage sein könnten, **Workspace-Benutzer** derselben Organisation (oder sogar aus einer anderen) zu **imitieren**.
|
||||
> Das bedeutet im Grunde, dass **Dienstkonten** innerhalb von GCP-Projekten einer Organisation in der Lage sein könnten, **Workspace-Benutzer** derselben Organisation (oder sogar von einer anderen) zu **imitieren**.
|
||||
|
||||
Für weitere Informationen darüber, wie das genau funktioniert, siehe:
|
||||
|
||||
@@ -19,7 +19,7 @@ gcp-understanding-domain-wide-delegation.md
|
||||
|
||||
### Bestehende Delegation kompromittieren
|
||||
|
||||
Wenn 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.\
|
||||
Wenn 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**.
|
||||
|
||||
> [!CAUTION]
|
||||
@@ -28,7 +28,7 @@ Mit einer **Liste aller Dienstkonten**, auf die er **Zugriff** hat, und der List
|
||||
|
||||
#### [GCP Generiere Delegationstoken](https://github.com/carlospolop/gcp_gen_delegation_token)
|
||||
|
||||
Dieses einfache Skript wird **ein OAuth-Token als der delegierte Benutzer generieren**, das Sie dann verwenden können, um auf andere Google APIs mit oder ohne `gcloud` zuzugreifen:
|
||||
Dieses einfache Skript wird **ein OAuth-Token als delegierter Benutzer generieren**, das Sie dann verwenden können, um auf andere Google APIs mit oder ohne `gcloud` zuzugreifen:
|
||||
```bash
|
||||
# Impersonate indicated user
|
||||
python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-key-file>
|
||||
@@ -36,22 +36,26 @@ python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-ke
|
||||
# Impersonate indicated user and add additional scopes
|
||||
python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-key-file> --scopes "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"
|
||||
```
|
||||
#### [**DelePwn**](https://github.com/n0tspam/delepwn)
|
||||
|
||||
Basierend auf dem folgenden DeleFriend-Tool, aber mit einigen Ergänzungen wie der Möglichkeit, die Domain, das Laufwerk, Gmail, den Kalender zu enumerieren und andere Operationen durchzuführen.
|
||||
|
||||
#### [**DeleFriend**](https://github.com/axon-git/DeleFriend)
|
||||
|
||||
Dies ist ein Tool, das den Angriff nach diesen Schritten durchführen kann:
|
||||
|
||||
1. **GCP-Projekte auflisten** mit der Resource Manager API.
|
||||
2. Iterieren Sie über jede Projektressource und **listen Sie die GCP-Servicekontenressourcen** auf, auf die der ursprüngliche IAM-Benutzer Zugriff hat, indem Sie _GetIAMPolicy_ verwenden.
|
||||
3. Iterieren Sie über **jede Rolle des Dienstkontos** und finden Sie integrierte, grundlegende und benutzerdefinierte Rollen mit der Berechtigung _**serviceAccountKeys.create**_ auf der Ziel-Dienstkontoressource. Es sollte beachtet werden, dass die Editor-Rolle diese Berechtigung von Natur aus besitzt.
|
||||
4. Erstellen Sie einen **neuen `KEY_ALG_RSA_2048`** privaten Schlüssel für jede Dienstkontoressource, die mit der relevanten Berechtigung in der IAM-Richtlinie gefunden wurde.
|
||||
5. Iterieren Sie über **jedes neue Dienstkonto und erstellen Sie 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.
|
||||
6. 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. Auch wenn dies einen bestimmten Benutzer zu erfordern scheint, ist es wichtig zu erkennen, dass **DWD jede Identität innerhalb einer Domäne beeinflusst**. Folglich hat die Erstellung eines JWT für **jeden Domänenbenutzer** Auswirkungen auf alle Identitäten in dieser Domäne, was mit unserer Kombinationen-Zählung ü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 Domänenbenutzer mit Rollen in GCP-Projekten scannt. Es ist wichtig zu beachten (nochmals), dass JWTs domänenspezifisch sind und nicht für jeden Benutzer generiert werden; daher zielt der automatische Prozess auf eine einzige eindeutige Identität pro Domäne ab.
|
||||
7. **Auflisten und erstellen Sie ein neues Bearer-Zugriffstoken** für jedes JWT und validieren Sie das Token gegen die tokeninfo API.
|
||||
1. **Enumerate GCP Projects** unter Verwendung der Resource Manager API.
|
||||
2. Iterieren Sie über jede Projektressource und **enumerate GCP Service account resources**, auf die der ursprüngliche IAM-Benutzer Zugriff hat, unter Verwendung von _GetIAMPolicy_.
|
||||
3. Iterieren Sie über **jede Service-Account-Rolle** und finden Sie integrierte, grundlegende und benutzerdefinierte Rollen mit der Berechtigung _**serviceAccountKeys.create**_ auf der Ziel-Service-Account-Ressource. Es sollte beachtet werden, dass die Editor-Rolle diese Berechtigung von Natur aus besitzt.
|
||||
4. Erstellen Sie einen **neuen `KEY_ALG_RSA_2048`** privaten Schlüssel für jede Service-Account-Ressource, die mit der relevanten Berechtigung in der IAM-Richtlinie gefunden wurde.
|
||||
5. Iterieren Sie über **jeden neuen Service-Account und erstellen Sie ein `JWT`** **object** 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.
|
||||
6. Die Methode `_make_authorization_grant_assertion` zeigt die Notwendigkeit an, einen **target workspace user** zu deklarieren, der als _subject_ bezeichnet wird, um JWTs unter DWD zu generieren. Auch wenn dies einen bestimmten Benutzer zu erfordern scheint, ist es wichtig zu erkennen, dass **DWD jede Identität innerhalb einer Domain beeinflusst**. Folglich wirkt sich die Erstellung eines JWT für **jeden Domain-Benutzer** auf alle Identitäten in dieser Domain aus, was mit unserer Kombinationen-Enumerationsprü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 in 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.
|
||||
7. **Enumerate and create a new bearer access token** für jedes JWT und validieren Sie das Token gegen die tokeninfo API.
|
||||
|
||||
#### [Gitlabs Python-Skript](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/gcp_misc/-/blob/master/gcp_delegation.py)
|
||||
#### [Gitlab's Python script](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/gcp_misc/-/blob/master/gcp_delegation.py)
|
||||
|
||||
Gitlab hat [dieses Python-Skript](https://gitlab.com/gitlab-com/gl-security/gl-redteam/gcp_misc/blob/master/gcp_delegation.py) 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:
|
||||
Gitlab hat [dieses Python-Skript](https://gitlab.com/gitlab-com/gl-security/gl-redteam/gcp_misc/blob/master/gcp_delegation.py) 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. Hier ist, wie Sie es verwenden würden:
|
||||
```bash
|
||||
# Install requirements
|
||||
pip install --upgrade --user oauth2client
|
||||
@@ -79,11 +83,11 @@ Es ist möglich, **Domain Wide Delegations in** [**https://admin.google.com/u/1/
|
||||
|
||||
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:**
|
||||
|
||||
1. **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).
|
||||
1. **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 **Berechtigung `iam.serviceAccounts.create`** ausgestattet ist. Sobald das Dienstkonto erstellt ist, fahren wir fort, ein **verwandtes Schlüsselpaar** zu generieren (**Berechtigung `iam.serviceAccountKeys.create`**).
|
||||
2. **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.
|
||||
3. **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 der GCP-Dienstkonto-Ressource** ist, und **OAuth-Scopes**, die definieren, welche API-Aufrufe die Delegation benötigt.
|
||||
- Die **vollständige Liste der OAuth-Scopes** kann [**hier**](https://developers.google.com/identity/protocols/oauth2/scopes) gefunden werden, 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`
|
||||
- Die **vollständige Liste der OAuth-Scopes** finden Sie [**hier**](https://developers.google.com/identity/protocols/oauth2/scopes), 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`
|
||||
4. **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 Umfang, 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.
|
||||
|
||||
@@ -93,7 +97,7 @@ Die OAuth SA-ID ist global und kann für **Cross-Organizational Delegation** ver
|
||||
|
||||
### Erstellen eines Projekts zur Aufzählung von Workspace
|
||||
|
||||
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 Projekt.
|
||||
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**.
|
||||
|
||||
@@ -124,14 +128,14 @@ gcloud beta identity groups preview --customer <org-cust-id>
|
||||
|
||||
### Missbrauch von Gcloud-Anmeldeinformationen
|
||||
|
||||
Sie finden weitere Informationen zum `gcloud`-Anmeldefluss in:
|
||||
Sie finden weitere Informationen zum `gcloud`-Anmeldefluss unter:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-persistence/gcp-non-svc-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
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:
|
||||
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:
|
||||
```bash
|
||||
gcloud auth login --enable-gdrive-access
|
||||
```
|
||||
@@ -140,7 +144,7 @@ Wenn ein Angreifer den Computer eines Benutzers kompromittiert, könnte er auch
|
||||
<figure><img src="../../../images/image (342).png" alt="" width="563"><figcaption></figcaption></figure>
|
||||
|
||||
> [!WARNING]
|
||||
> Daher wird der Benutzer beim nächsten Login ein **Token mit Zugriff auf Drive** erstellen, das der Angreifer missbrauchen könnte, um auf das 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.**
|
||||
> Daher wird der Benutzer beim nächsten Login ein **Token mit Zugriff auf Drive** erstellen, das der Angreifer missbrauchen könnte, um auf das 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 bemerken.**
|
||||
>
|
||||
> Um Drive-Dateien aufzulisten: **`curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"`**
|
||||
|
||||
|
||||
Reference in New Issue
Block a user