German - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

GCP <--> Workspace Pivoting

Support HackTricks

Von GCP zu GWS

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.

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 Delegation

Bestehende Delegation kompromittieren

Wenn ein Angreifer Zugriff über 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.

GCP Generiere Delegationstoken

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:

# Impersonate indicated user
python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-key-file>

# 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"

DeleFriend

Dies ist ein Tool, das den Angriff nach diesen Schritten durchführen kann:

  1. GCP-Projekte auflisten mit der Resource Manager API.

  2. Iteriere über jede Projektressource und enumerate GCP-Dienstkonto-Ressourcen, auf die der ursprüngliche IAM-Benutzer Zugriff hat, mit GetIAMPolicy.

  3. 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.

  4. 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.

  5. 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.

  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 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.

  7. Enumerate und erstelle ein neues Bearer-Zugriffstoken für jedes JWT und validiere das Token gegen die tokeninfo API.

Gitlabs Python-Skript

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:

# Install requirements
pip install --upgrade --user oauth2client

# Validate access only
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com

# List the directory
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com \
--list

# Create a new admin account
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com \
--account pwned

Erstellen einer neuen Delegation (Persistenz)

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:

  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).

  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 dass Domain-Wide-Delegationen nicht programmgesteuert eingerichtet werden können. Sie kann 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.

  1. 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 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

  1. 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.

Cross-Organizational Delegation

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 domainweite Delegationen 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.

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.

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).

# Create project
gcloud projects create <uniq-projec-name> --name=proj-name
# Set project
gcloud config set project <uniq-projec-name>
# Enable svcs
gcloud services enable admin.googleapis.com
gcloud services enable cloudidentity.googleapis.com
# Get org ID
gcloud organizations list
# Get currents email user groups (at least you can check the groups and members of the groups you belong to)
gcloud identity groups memberships search-transitive-groups --member-email <email> --labels=cloudidentity.googleapis.com/groups.discussion_forum
gcloud identity groups memberships list --group-email=g<group-email>

# FROM HERE THE USER NEEDS TO HAVE ENOUGH WORKSPACE ACCESS
gcloud beta identity groups preview --customer <org-cust-id>

Überprüfen Sie weitere Aufzählungen in:

GCP - IAM, Principals & Org Policies Enum

Missbrauch von Gcloud-Anmeldeinformationen

Sie finden weitere Informationen zum gcloud-Anmeldefluss in:

GCP - Token Persistance

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:

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:

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"

Von GWS zu GCP

Zugriff auf privilegierte GCP-Benutzer

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.

Google Groups Privilegieneskalation

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.

Referenzen

Support HackTricks
PreviousGCP - Workflows EnumNextGCP - Understanding Domain-Wide Delegation

Last updated