GCP - IAM Privesc

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

IAM

Weitere Informationen zu IAM finden Sie in:

GCP - IAM, Principals & Org Policies Enum

iam.roles.update (iam.roles.get)

Ein attacker mit den genannten Berechtigungen kann eine Rolle, die Ihnen zugewiesen ist, aktualisieren und Ihnen zusätzliche Berechtigungen für andere Ressourcen wie:

gcloud iam roles update <rol name> --project <project> --add-permissions <permission>

Du findest ein Script, um die Erstellung, exploit und Bereinigung einer vuln-Umgebung hier zu automatisieren und ein python script, um dieses Privileg auszunutzen here. Für weitere Informationen siehe die original research.

gcloud iam roles update <Rol_NAME> --project <PROJECT_ID> --add-permissions <Permission>

iam.roles.create & iam.serviceAccounts.setIamPolicy

Die iam.roles.create-Berechtigung erlaubt die Erstellung benutzerdefinierter Rollen in einem Projekt oder einer Organisation. In den Händen eines Angreifers ist das gefährlich, da es ihm ermöglicht, neue Berechtigungssätze zu definieren, die später Entitäten zugewiesen werden können (zum Beispiel mithilfe der iam.serviceAccounts.setIamPolicy-Berechtigung), mit dem Ziel der privilege escalation.

gcloud iam roles create <ROLE_ID> \
--project=<PROJECT_ID> \
--title="<Title>" \
--description="<Description>" \
--permissions="permission1,permission2,permission3"

iam.serviceAccounts.getAccessToken (iam.serviceAccounts.get)

Ein Angreifer mit den genannten Berechtigungen kann ein access token anfordern, das zu einem Service Account gehört, daher ist es möglich, ein access token eines Service Account anzufordern, das mehr Berechtigungen hat als unseres.

gcloud --impersonate-service-account="${victim}@${PROJECT_ID}.iam.gserviceaccount.com" \
auth print-access-token

Du findest ein Skript, um die Erstellung, exploit und Bereinigung einer verwundbaren Umgebung hier zu automatisieren und ein Python-Skript, um dieses Privileg hier auszunutzen. Für weitere Informationen siehe die Originalforschung.

iam.serviceAccountKeys.create

Ein Angreifer mit den genannten Berechtigungen kann einen vom Benutzer verwalteten Schlüssel für ein Service Account erstellen, wodurch wir uns als dieses Service Account bei GCP anmelden können.

gcloud iam service-accounts keys create --iam-account <name> /tmp/key.json

gcloud auth activate-service-account --key-file=sa_cred.json

Du findest ein Script, um die creation, exploit and cleaning of a vuln environment here zu automatisieren, und ein Python-Script, um dieses Privileg auszunutzen, here. Für mehr Informationen siehe die original research.

Beachte, dass iam.serviceAccountKeys.update nicht funktioniert, um den Schlüssel eines SA zu ändern, da dafür die Berechtigung iam.serviceAccountKeys.create ebenfalls benötigt wird.

iam.serviceAccounts.implicitDelegation

Wenn du die Berechtigung iam.serviceAccounts.implicitDelegation auf einem Service Account hast, der die Berechtigung iam.serviceAccounts.getAccessToken auf einem dritten Service Account besitzt, kannst du implicitDelegation verwenden, um einen Token für diesen dritten Service Account zu erstellen. Hier ist ein Diagramm zur Veranschaulichung.

Beachte, dass laut der documentation die Delegation von gcloud nur funktioniert, um einen Token mit der Methode generateAccessToken() zu erzeugen. Hier siehst du, wie man einen Token direkt über die API erhält:

curl -X POST \
'https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/'"${TARGET_SERVICE_ACCOUNT}"':generateAccessToken' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer '"$(gcloud auth print-access-token)" \
-d '{
"delegates": ["projects/-/serviceAccounts/'"${DELEGATED_SERVICE_ACCOUNT}"'"],
"scope": ["https://www.googleapis.com/auth/cloud-platform"]
}'

Du findest ein Skript, um die creation, exploit and cleaning of a vuln environment here zu automatisieren und ein python script, um dieses Privileg zu missbrauchen here. Für mehr Informationen siehe die original research.

iam.serviceAccounts.signBlob

Ein Angreifer mit den genannten Berechtigungen kann beliebige Payloads in GCP signieren. Somit ist es möglich, einen unsigned JWT des SA zu erstellen und ihn dann als Blob zu senden, damit der JWT vom SA signiert wird. Für mehr Informationen read this.

Du findest ein Skript, um die creation, exploit and cleaning of a vuln environment here zu automatisieren und ein python script, um dieses Privileg zu missbrauchen here und here. Für mehr Informationen siehe die original research.

iam.serviceAccounts.signJwt

Ein Angreifer mit den genannten Berechtigungen kann wohlgeformte JSON web tokens (JWTs) signieren. Der Unterschied zur vorherigen Methode ist, dass anstatt google ein Blob zu signieren, das ein JWT enthält, wir die signJWT-Methode verwenden, die bereits ein JWT erwartet. Das macht die Nutzung einfacher, aber du kannst nur JWTs signieren anstatt beliebiger Bytes.

Du findest ein Skript, um die creation, exploit and cleaning of a vuln environment here zu automatisieren und ein python script, um dieses Privileg zu missbrauchen here. Für mehr Informationen siehe die original research.

iam.serviceAccounts.setIamPolicy

Ein Angreifer mit den genannten Berechtigungen kann IAM policies zu service accounts hinzufügen. Du kannst das ausnutzen, um dir die Berechtigungen zu gewähren, die du benötigst, um den service account zu impersonate. Im folgenden Beispiel gewähren wir uns die Rolle roles/iam.serviceAccountTokenCreator für den interessanten SA:

gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \
--member="user:username@domain.com" \
--role="roles/iam.serviceAccountTokenCreator"

# If you still have prblem grant yourself also this permission
gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \ \
--member="user:username@domain.com" \
--role="roles/iam.serviceAccountUser"

You can find a script to automate the creation, exploit and cleaning of a vuln environment here.

iam.serviceAccounts.actAs

Die iam.serviceAccounts.actAs permission ist wie die iam:PassRole permission from AWS. Sie ist essenziell, um Aufgaben auszuführen — z. B. das Starten einer Compute Engine-Instanz — da sie die Fähigkeit gewährt, als “actAs” ein Service Account zu agieren und so ein sicheres permission-Management ermöglicht. Ohne diese könnten Benutzer unberechtigten Zugriff erlangen. Außerdem umfasst das Ausnutzen von iam.serviceAccounts.actAs verschiedene Methoden, die jeweils mehrere permissions erfordern, im Gegensatz zu anderen Methoden, die nur eine benötigen.

Service account impersonation

Impersonating a service account kann sehr nützlich sein, um neue und bessere privileges zu erhalten. Es gibt drei Wege, wie man impersonate another service account:

  • Authentication using RSA private keys (oben behandelt)
  • Authorization using Cloud IAM policies (hier behandelt)
  • Deploying jobs on GCP services (mehr anwendbar auf die Kompromittierung eines Benutzerkontos)

iam.serviceAccounts.getOpenIdToken

Ein Angreifer mit den genannten permissions kann ein OpenID JWT erzeugen. Diese werden benutzt, um Identität zu bestätigen, tragen jedoch nicht notwendigerweise eine implizite Autorisierung gegen eine Ressource.

Laut diesem interesting post muss die audience angegeben werden (der Service, bei dem du das Token zur Authentifizierung verwenden möchtest) und du erhältst ein von google signiertes JWT, das das Service Account und die audience des JWT angibt.

You can generate an OpenIDToken (if you have the access) with:

# First activate the SA with iam.serviceAccounts.getOpenIdToken over the other SA
gcloud auth activate-service-account --key-file=/path/to/svc_account.json
# Then, generate token
gcloud auth print-identity-token "${ATTACK_SA}@${PROJECT_ID}.iam.gserviceaccount.com" --audiences=https://example.com

Dann kannst du es einfach verwenden, um mit folgendem Befehl auf den Dienst zuzugreifen:

curl -v -H "Authorization: Bearer id_token" https://some-cloud-run-uc.a.run.app

Einige Dienste, die Authentifizierung über solche Token unterstützen, sind:

Ein Beispiel, wie man ein OpenID-Token im Namen eines Service-Accounts erstellt, finden Sie hier.

Referenzen

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks