German - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

GCP - IAM Privesc

Unterstütze HackTricks

IAM

Finde mehr Informationen über IAM in:

GCP - IAM, Principals & Org Policies Enum

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

Ein Angreifer mit den genannten Berechtigungen kann eine dir zugewiesene Rolle aktualisieren und dir zusätzliche Berechtigungen für andere Ressourcen geben wie:

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

Du findest ein Skript zur Automatisierung der Erstellung, Ausnutzung und Bereinigung einer verwundbaren Umgebung hier und ein Python-Skript zur Ausnutzung dieses Privilegs hier. Für weitere Informationen siehe die Originalforschung.

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

Ein Angreifer mit den genannten Berechtigungen wird in der Lage sein, ein Zugriffstoken anzufordern, das zu einem Service Account gehört, sodass es möglich ist, ein Zugriffstoken eines Service Accounts mit mehr Privilegien als unseren anzufordern.

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

Du findest ein Skript zur Automatisierung der Erstellung, Ausnutzung und Bereinigung einer verwundbaren Umgebung hier und ein Python-Skript zum Missbrauch dieses Privilegs hier. Für weitere Informationen siehe die Originalforschung.

iam.serviceAccountKeys.create

Ein Angreifer mit den genannten Berechtigungen wird in der Lage sein, einen benutzerverwalteten Schlüssel für ein Service Account zu erstellen, was uns den Zugriff auf GCP als dieses Service Account ermöglicht.

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 Skript zur Automatisierung der Erstellung, Ausnutzung und Bereinigung einer verwundbaren Umgebung hier und ein Python-Skript zur Ausnutzung dieses Privilegs hier. Für weitere Informationen siehe die Originalforschung.

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

iam.serviceAccounts.implicitDelegation

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

Beachte, dass laut der Dokumentation die Delegation von gcloud nur funktioniert, um einen Token mit der generateAccessToken()-Methode zu generieren. Hier ist, wie du einen Token direkt über die API erhältst:

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 zur Automatisierung der Erstellung, Ausnutzung und Bereinigung einer verwundbaren Umgebung hier und ein Python-Skript zum Missbrauch dieses Privilegs hier. Für weitere Informationen siehe die Originalforschung.

iam.serviceAccounts.signBlob

Ein Angreifer mit den genannten Berechtigungen wird in der Lage sein, beliebige Nutzlasten in GCP zu signieren. Es wird also möglich sein, ein unsigniertes JWT des SA zu erstellen und es dann als Blob zu senden, um das JWT vom anvisierten SA signieren zu lassen. Für weitere Informationen lies dies.

Du findest ein Skript zur Automatisierung der Erstellung, Ausnutzung und Bereinigung einer verwundbaren Umgebung hier und ein Python-Skript zum Missbrauch dieses Privilegs hier und hier. Für weitere Informationen siehe die Originalforschung.

iam.serviceAccounts.signJwt

Ein Angreifer mit den genannten Berechtigungen wird in der Lage sein, wohlgeformte JSON Web Tokens (JWTs) zu signieren. Der Unterschied zur vorherigen Methode besteht darin, dass anstatt Google einen Blob signieren zu lassen, der ein JWT enthält, verwenden wir die signJWT-Methode, die bereits ein JWT erwartet. Dies macht es einfacher zu verwenden, aber man kann nur JWTs und keine beliebigen Bytes signieren.

Du findest ein Skript zur Automatisierung der Erstellung, Ausnutzung und Bereinigung einer verwundbaren Umgebung hier und ein Python-Skript zum Missbrauch dieses Privilegs hier. Für weitere Informationen siehe die Originalforschung.

iam.serviceAccounts.setIamPolicy

Ein Angreifer mit den genannten Berechtigungen wird in der Lage sein, IAM-Richtlinien zu Servicekonten hinzuzufügen. Du kannst dies ausnutzen, um dir selbst die Berechtigungen zu erteilen, die du benötigst, um das Servicekonto zu imitieren. Im folgenden Beispiel gewähren wir uns selbst die Rolle roles/iam.serviceAccountTokenCreator über das interessante 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"

Du findest ein Skript zur Automatisierung der Erstellung, Ausnutzung und Bereinigung einer verwundbaren Umgebung hier.

iam.serviceAccounts.actAs

Die iam.serviceAccounts.actAs-Berechtigung ist wie die iam:PassRole-Berechtigung von AWS. Sie ist wesentlich für die Ausführung von Aufgaben, wie das Starten einer Compute Engine-Instanz, da sie die Fähigkeit verleiht, als Service Account zu agieren und so ein sicheres Berechtigungsmanagement gewährleistet. Ohne diese Berechtigung könnten Benutzer ungebührlichen Zugriff erlangen. Darüber hinaus umfasst die Ausnutzung der iam.serviceAccounts.actAs verschiedene Methoden, die jeweils eine Reihe von Berechtigungen erfordern, im Gegensatz zu anderen Methoden, die nur eine benötigen.

Service Account-Impersonation

Das Nachahmen eines Service Accounts kann sehr nützlich sein, um neue und bessere Privilegien zu erlangen. Es gibt drei Möglichkeiten, wie du einen anderen Service Account nachahmen kannst:

  • Authentifizierung mit RSA-Privatschlüsseln (oben behandelt)

  • Autorisierung mit Cloud IAM-Richtlinien (hier behandelt)

  • Bereitstellung von Jobs auf GCP-Diensten (mehr anwendbar auf die Kompromittierung eines Benutzerkontos)

iam.serviceAccounts.getOpenIdToken

Ein Angreifer mit den genannten Berechtigungen wird in der Lage sein, ein OpenID JWT zu generieren. Diese werden verwendet, um Identität zu bestätigen und tragen nicht notwendigerweise eine implizite Autorisierung gegen eine Ressource.

Laut diesem interessanten Beitrag ist es notwendig, das Publikum (den Dienst, bei dem du das Token zur Authentifizierung verwenden möchtest) anzugeben, und du erhältst ein von Google signiertes JWT, das den Service Account und das Publikum des JWT angibt.

Du kannst ein OpenIDToken (wenn du den Zugriff hast) mit folgendem Befehl generieren:

# 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 können Sie es einfach verwenden, um auf den Dienst zuzugreifen mit:

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

Einige Dienste, die die Authentifizierung über diese Art von Tokens unterstützen, sind:

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

Referenzen

Unterstütze HackTricks
PreviousGCP - Deploymentmaneger PrivescNextGCP - KMS Privesc

Last updated