German - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

GCP <--> Workspace Pivoting

Erlernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

Von GCP zu GWS

Grundlagen der Domain-weiten Delegation

Die Domain-weite Delegation von Google Workspace ermöglicht es einem Identitätsobjekt, entweder einer externen App aus dem Google Workspace Marketplace oder einem internen GCP-Servicekonto, Daten im gesamten Workspace im Namen von Benutzern zuzugreifen.

Dies bedeutet im Wesentlichen, dass Servicekonten innerhalb von GCP-Projekten einer Organisation in der Lage sein könnten, Workspace-Benutzer der gleichen Organisation (oder sogar einer anderen) zu imitieren.

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

pageGCP - Understanding Domain-Wide Delegation

Kompromittierung bestehender Delegation

Wenn ein Angreifer einen gewissen Zugriff auf GCP kompromittiert hat und die E-Mail-Adresse eines gültigen Workspace-Benutzers kennt (vorzugsweise Super-Admin) des Unternehmens, könnte er alle Projekte auflisten, auf die er Zugriff hat, alle SAs der Projekte auflisten, überprüfen, auf welche Servicekonten er Zugriff hat, und alle diese Schritte mit jedem SA wiederholen können. Mit einer Liste aller Servicekonten, auf die er Zugriff hat, und der Liste der Workspace-E-Mails könnte der Angreifer versuchen, sich mit jedem Servicekonto als Benutzer auszugeben.

Beachten Sie, dass bei der Konfiguration der domainweiten Delegation kein Workspace-Benutzer erforderlich ist, daher reicht es aus, einen gültigen Benutzer zu kennen und für die Imitation erforderlich zu sein. Die Berechtigungen des imitierten Benutzers werden jedoch verwendet, sodass Sie bei einem Super-Admin auf alles zugreifen können. Wenn er keine Berechtigungen hat, ist dies nutzlos.

GCP Generate Delegation Token

Dieses einfache Skript wird ein OAuth-Token als der delegierte Benutzer generieren, den 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"

DeleFriend

Dies ist ein Tool, das den Angriff gemäß der folgenden Schritte durchführen kann:

  1. Aufzählen von GCP-Projekten mithilfe der Resource Manager API.

  2. Iterieren Sie über jeden Projektressource und zählen Sie GCP-Servicekontenressourcen auf, auf die der anfängliche IAM-Benutzer Zugriff hat, indem Sie GetIAMPolicy verwenden.

  3. Iterieren Sie über jede Servicekontenrolle und finden Sie eingebaute, grundlegende und benutzerdefinierte Rollen mit der Berechtigung serviceAccountKeys.create auf der Ziel-Servicekontenressource. Es sollte beachtet werden, dass die Editor-Rolle diese Berechtigung von Natur aus besitzt.

  4. Erstellen Sie einen neuen privaten Schlüssel KEY_ALG_RSA_2048 für jede Servicekontenressource, die mit der relevanten Berechtigung in der IAM-Richtlinie gefunden wurde.

  5. Iterieren Sie über jedes neue Servicekonto und erstellen Sie ein JWT-Objekt dafür, das aus den SA-privaten Schlüsselinformationen und einem OAuth-Bereich besteht. Der Prozess der Erstellung eines neuen JWT-Objekts wird alle vorhandenen Kombinationen von OAuth-Bereichen aus der Liste oauth_scopes.txt durchlaufen, um alle Delegierungsmöglichkeiten zu finden. Die Liste oauth_scopes.txt wird mit allen von uns als relevant für den Missbrauch von Workspace-Identitäten gefundenen OAuth-Bereichen aktualisiert.

  6. Die Methode _make_authorization_grant_assertion zeigt die Notwendigkeit auf, einen Ziel-Workspace-Benutzer zu deklarieren, der als subject bezeichnet wird, um JWTs unter DWD zu generieren. Obwohl dies zunächst nach einem spezifischen Benutzer zu verlangen scheint, ist es wichtig zu erkennen, dass DWD jede Identität innerhalb einer Domäne beeinflusst. Folglich beeinflusst das Erstellen eines JWT für einen beliebigen Domänenbenutzer alle Identitäten in dieser Domäne, im Einklang mit unserer Kombinationsaufzählungsprüfung. Einfach ausgedrückt, ist ein gültiger Workspace-Benutzer ausreichend, um fortzufahren. Dieser Benutzer kann in der config.yaml-Datei von DeleFriend definiert werden. Wenn ein Ziel-Workspace-Benutzer noch nicht bekannt ist, erleichtert das Tool die automatische Identifizierung gültiger Workspace-Benutzer durch Scannen von Domänenbenutzern mit Rollen in GCP-Projekten. Es ist wichtig zu beachten (erneut), dass JWTs domänenspezifisch sind und nicht für jeden Benutzer generiert werden; daher zielt der automatische Prozess auf eine einzelne eindeutige Identität pro Domäne ab.

  7. Zählen und Erstellen eines neuen Bearer-Zugriffstokens für jedes JWT und Validieren des Tokens gegen die tokeninfo API.

Gitlab's Python-Skript

Gitlab hat dieses Python-Skript erstellt, das zwei Dinge tun kann - das Benutzerverzeichnis auflisten und ein neues Administratorkonto erstellen, während ein JSON mit SA-Anmeldeinformationen und dem zu imitierenden Benutzer angegeben wird. 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-weite Delegationen unter https://admin.google.com/u/1/ac/owl/domainwidedelegation** zu überprüfen**.

Ein Angreifer mit der Fähigkeit, Service-Konten in einem GCP-Projekt zu erstellen und Super-Admin-Berechtigungen für GWS zu haben, könnte eine neue Delegation erstellen, die es Service-Konten ermöglicht, einige GWS-Benutzer zu impersonieren:

  1. Generierung eines neuen Service-Kontos und entsprechendes Schlüsselpaar: Auf GCP können neue Ressourcen für Service-Konten entweder interaktiv über die Konsole oder programmgesteuert über direkte API-Aufrufe und CLI-Tools erstellt werden. Hierfür sind die Rolle iam.serviceAccountAdmin oder eine benutzerdefinierte Rolle mit der Berechtigung iam.serviceAccounts.create erforderlich. Sobald das Service-Konto erstellt ist, fahren wir fort, um ein zugehöriges Schlüsselpaar zu generieren (Berechtigung iam.serviceAccountKeys.create).

  2. Erstellung einer neuen Delegation: Es ist wichtig zu verstehen, dass nur die Rolle des Super-Admins die Fähigkeit besitzt, eine globale Domain-weite Delegation in Google Workspace einzurichten und Domain-weite Delegation nicht programmgesteuert eingerichtet werden kann. Sie kann nur manuell über die Google Workspace Konsole erstellt und angepasst werden.

  • Die Erstellung der Regel findet sich unter der Seite API-Steuerungen → Verwalten der Domain-weiten Delegation in der Google Workspace Admin-Konsole.

  1. Anhängen der Berechtigung für OAuth-Bereiche: Bei der Konfiguration einer neuen Delegation erfordert Google nur 2 Parameter, die Client-ID, die die OAuth-ID der GCP-Service-Konto-Ressource ist, und OAuth-Bereiche, die definieren, welche API-Aufrufe die Delegation erfordert.

  • Die vollständige Liste der OAuth-Bereiche 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. Handeln im Namen der Zielidentität: Zu diesem Zeitpunkt haben wir ein funktionierendes delegiertes Objekt in GWS. Jetzt können wir unter Verwendung des privaten Schlüssels des GCP-Service-Kontos API-Aufrufe (im Umfang, der im OAuth-Bereichsparameter definiert ist) durchführen, um es auszulösen und im Namen einer beliebigen Identität, die in Google Workspace existiert, zu handeln. Wie wir gelernt haben, wird das Service-Konto Zugriffstoken entsprechend seinen Anforderungen generieren 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-Organisationale Delegation

Die OAuth SA-ID ist global und kann für cross-organisationale Delegation verwendet werden. Es wurde keine Einschränkung implementiert, um eine Delegation über Organisationen hinweg zu verhindern. Einfach ausgedrückt können Service-Konten aus verschiedenen GCP-Organisationen verwendet werden, um domain-weite Delegationen in anderen Workspace-Organisationen zu konfigurieren. Dies würde dazu führen, dass nur der Zugriff eines Super-Admins auf Workspace erforderlich ist, und nicht der Zugriff auf dasselbe GCP-Konto, da der Angreifer Service-Konten und private Schlüssel in seinem persönlich kontrollierten GCP-Konto erstellen kann.

Erstellen eines Projekts zur Auflistung 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 Eigentümerrolle darüber.

Daher kann ein Benutzer ein Projekt erstellen, die APIs aktivieren, um Workspace in seinem neuen Projekt aufzulisten und versuchen, es aufzulisten.

Damit ein Benutzer Workspace auflisten kann, benötigt er auch ausreichende Workspace-Berechtigungen (nicht jeder Benutzer wird in der Lage sein, das Verzeichnis aufzulisten).

# 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 Enumerationen in:

pageGCP - IAM, Principals & Org Policies Enum

Ausnutzen von Gcloud

Weitere Informationen zum gcloud-Ablauf zur Anmeldung finden Sie unter:

pageGCP - Non-svc Persistance

Wie dort erklärt, kann gcloud den Bereich https://www.googleapis.com/auth/drive anfordern, der einem Benutzer den Zugriff auf das Laufwerk des Benutzers ermöglichen würde. Als Angreifer könnten Sie, wenn Sie den Computer eines Benutzers physisch kompromittiert haben und der Benutzer immer noch mit seinem Konto angemeldet ist, sich anmelden und ein Token generieren, das Zugriff auf das Laufwerk gewährt, indem Sie:

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

Daher wird beim nächsten Mal, wenn sich der Benutzer anmeldet, ein Token mit Zugriff auf Drive erstellt, den der Angreifer missbrauchen könnte, um auf das Laufwerk zuzugreifen. Offensichtlich wird der Browser anzeigen, dass das generierte Token Zugriff auf Drive haben wird, aber da der Benutzer wahrscheinlich selbst gcloud auth login aufruft, wird er wahrscheinlich nichts Verdächtiges vermuten.

Um Laufwerksdateien 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 Benutzer zugreifen. Daher ist der Übergang von GWS zu GCP in der Regel "einfacher", einfach weil Benutzer in GWS über hohe Berechtigungen für GCP verfügen.

Google Groups Privilege Escalation

Standardmäßig können Benutzer frei Workspace-Gruppen der Organisation beitreten und diese Gruppen können GCP-Berechtigungen zugewiesen haben (überprüfen Sie Ihre Gruppen unter https://groups.google.com/).

Durch Ausnutzen der google groups privesc könnten Sie in der Lage sein, zu einer Gruppe mit einer Art privilegiertem Zugriff auf GCP zu eskalieren.

Referenzen

Erlernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

PreviousGCP - Storage EnumNextGCP - Understanding Domain-Wide Delegation

Last updated