GCP <--> Workspace Pivoting

Reading time: 11 minutes

Von GCP zu GWS

Grundlagen der domänenweiten Delegation

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.

Für weitere Informationen darüber, wie das genau funktioniert, siehe:

GCP - Understanding Domain-Wide Delegation

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

GCP Generiere Delegationstoken

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:

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

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

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

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.

Gitlab's Python script

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. Hier ist, wie Sie es verwenden würden:

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

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.

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.

# 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 unter:

GCP - Token Persistence

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:

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 im CLOUDSDK_SCOPES den Scope 'https://www.googleapis.com/auth/drive' hinzufügen:

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

• https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover