gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-31 15:05:44 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting

Browse Source
This commit is contained in:
Translator
2025-02-26 00:22:06 +00:00
parent 82b4ab92a6
commit 54295ea743
2 changed files with 27 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/README.md
View File

@@ -9,7 +9,7 @@
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**.
> [!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 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 aus einer anderen) zu **imitieren**.
Für weitere Informationen darüber, wie das genau funktioniert, siehe:
@@ -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 delegierter 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 der delegierte 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>
@@ -41,15 +41,15 @@ python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-ke
Dies ist ein Tool, das den Angriff nach diesen Schritten durchführen kann:
1. **GCP-Projekte auflisten** mit der Resource Manager API.
2. Über jedes Projektressource iterieren und **GCP-Servicekonto-Ressourcen auflisten**, auf die der ursprüngliche IAM-Benutzer Zugriff hat, indem _GetIAMPolicy_ verwendet wird.
3. Über **jede Servicekonto-Rolle iterieren** und integrierte, grundlegende und benutzerdefinierte Rollen mit der Berechtigung _**serviceAccountKeys.create**_ auf der Ziel-Servicekonto-Ressource finden. Es sollte beachtet werden, dass die Editor-Rolle diese Berechtigung von Natur aus besitzt.
4. Einen **neuen `KEY_ALG_RSA_2048`** privaten Schlüssel für jede Servicekonto-Ressource erstellen, die mit der relevanten Berechtigung in der IAM-Richtlinie gefunden wurde.
5. Über **jedes neue Servicekonto iterieren und ein `JWT`** **Objekt** dafür erstellen, das aus den SA-Privatschlüssel-Anmeldeinformationen und einem OAuth-Bereich besteht. Der Prozess zur Erstellung eines neuen _JWT_ Objekts wird **über alle bestehenden Kombinationen von OAuth-Bereichen** aus der **oauth_scopes.txt** Liste iterieren, 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, einen **Ziel-Workspace-Benutzer** zu deklarieren, der als _subject_ bezeichnet wird, um JWTs unter DWD zu generieren. Auch wenn dies einen spezifischen Benutzer zu erfordern scheint, ist es wichtig zu erkennen, dass **DWD jede Identität innerhalb einer Domain beeinflusst**. Folglich hat die Erstellung eines JWT für **jeden Domainbenutzer** Auswirkungen auf alle Identitäten in dieser Domain, 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 Domainbenutzer 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.
7. **Ein neues Bearer-Zugriffstoken auflisten und erstellen** für jedes JWT und das Token gegen die tokeninfo API validieren.
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.
#### [Gitlab's Python-Skript](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/gcp_misc/-/blob/master/gcp_delegation.py)
#### [Gitlabs Python-Skript](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:
```bash
@@ -93,7 +93,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.
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.
Daher kann ein Benutzer **ein Projekt erstellen**, die **APIs aktivieren**, um Workspace in seinem neuen Projekt aufzulisten, und versuchen, es zu **enumerieren**.
@@ -127,7 +127,7 @@ gcloud beta identity groups preview --customer <org-cust-id>
Sie finden weitere Informationen zum `gcloud`-Anmeldefluss in:
{{#ref}}
../gcp-persistence/gcp-non-svc-persistance.md
../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.\
@@ -135,7 +135,7 @@ Als Angreifer, wenn Sie den Computer eines Benutzers **physisch** kompromittiert
```bash
gcloud auth login --enable-gdrive-access
```
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:
Wenn ein Angreifer den Computer eines Benutzers kompromittiert, könnte er auch die Datei `google-cloud-sdk/lib/googlecloudsdk/core/config.py` ändern und im **`CLOUDSDK_SCOPES`** den Scope **`'https://www.googleapis.com/auth/drive'`** hinzufügen:
<figure><img src="../../../images/image (342).png" alt="" width="563"><figcaption></figcaption></figure>
@@ -152,7 +152,7 @@ Wenn ein Angreifer vollständigen Zugriff auf GWS hat, kann er auf Gruppen mit p
### Google Groups Privilegieneskalation
Standardmäßig können Benutzer **frei in Workspace-Gruppen der Organisation beitreten**, und diese Gruppen **könnten GCP-Berechtigungen** zugewiesen haben (prüfen Sie Ihre Gruppen in [https://groups.google.com/](https://groups.google.com/)).
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 in [https://groups.google.com/](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.