GCP - IAM Privesc

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstütze HackTricks

IAM

Weitere Informationen zu IAM finden Sie in:

GCP - IAM, Principals & Org Policies Enum

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

Ein Angreifer mit den genannten Berechtigungen kann eine Ihnen zugewiesene Rolle aktualisieren und Ihnen zusätzliche Berechtigungen für andere Ressourcen erteilen, z. B.:

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

Du kannst ein Script finden, das die creation, exploit and cleaning of a vuln environment here automatisiert, und ein python-Skript, um dieses Privileg auszunutzen here. Für mehr 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/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 unter Verwendung der iam.serviceAccounts.setIamPolicy-Berechtigung), mit dem Ziel, privilege escalation durchzuführen.

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, sodass er ein Access-Token eines Service Accounts mit höheren Rechten als unserem erhalten kann.

Für eine resource-driven Variante, bei der von Angreifern kontrollierter Code ein managed Vertex AI Agent Engine runtime token aus dem metadata service stiehlt und es als Vertex AI service agent wiederverwendet, siehe:

GCP - Vertex AI Post Exploitation

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

Du findest ein Skript zur Automatisierung der creation, exploit and cleaning of a vuln environment here und ein Python-Skript, um dieses Privileg zu missbrauchen here. Für mehr Informationen siehe die original research.

iam.serviceAccountKeys.create

Ein Angreifer mit den genannten Berechtigungen kann einen benutzerverwalteten Schlüssel für einen Service Account erstellen, was es uns ermöglicht, auf GCP als dieses Service Account zuzugreifen.

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

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

Sie finden ein Skript zur Automatisierung der Erstellung, exploit und Bereinigung einer vuln-Umgebung hier und ein python-Skript, um dieses Privileg auszunutzen hier. Für weitere Informationen siehe die original research.

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

iam.serviceAccounts.implicitDelegation

Wenn Sie die iam.serviceAccounts.implicitDelegation Berechtigung auf einem Service Account haben, der die iam.serviceAccounts.getAccessToken Berechtigung auf einem dritten Service Account besitzt, dann können Sie implicitDelegation verwenden, um einen Token für diesen dritten Service Account zu erstellen. Hier ist ein Diagramm zur Veranschaulichung.

Beachte, dass laut der Dokumentation die Delegation von gcloud nur funktioniert, um ein Token mit der Methode generateAccessToken() zu erzeugen. Hier sehen Sie, wie man ein 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-Skript, um dieses Privileg auszunutzen here. Für weitere Informationen siehe die original research.

iam.serviceAccounts.signBlob

Ein Angreifer mit den genannten Berechtigungen kann beliebige Payloads in GCP signieren. Damit ist es möglich, einen nicht-signierten JWT des SA zu erstellen und ihn dann als Blob zu senden, damit der Ziel-SA den JWT signiert. 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-Skript, um dieses Privileg auszunutzen here und here. Für weitere 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 signieren zu lassen, das ein JWT enthält, wir die signJWT-Methode verwenden, die bereits ein JWT erwartet. Das macht die Nutzung einfacher, aber man kann nur JWTs signieren statt beliebiger Bytes.

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

iam.serviceAccounts.setIamPolicy

Ein Angreifer mit den genannten Berechtigungen kann IAM-Policies zu Service Accounts hinzufügen. Dies kann ausgenutzt werden, um sich selbst die Berechtigungen zu gewähren, die benötigt werden, um sich als Service Account auszugeben. 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-Berechtigung ist vergleichbar mit der iam:PassRole-Berechtigung von AWS. Sie ist essenziell, um Aktionen auszuführen — z. B. das Starten einer Compute Engine-Instanz — da sie das Recht gewährt, als Service Account “actAs” zu agieren und so Berechtigungen sicher zu verwalten. Ohne diese Berechtigung könnten Benutzer unzulässigen Zugriff erlangen. Außerdem gibt es verschiedene Methoden, die iam.serviceAccounts.actAs auszunutzen; diese erfordern jeweils mehrere Berechtigungen, im Gegensatz zu anderen Methoden, die nur eine einzige Berechtigung benötigen.

Service account impersonation

Die Impersonation eines Service Accounts kann sehr nützlich sein, um neue und bessere Privilegien zu erlangen. Es gibt drei Wege, wie man einen anderen Service Account impersonieren kann:

  • Authentifizierung using RSA private keys (oben behandelt)
  • Autorisierung using Cloud IAM policies (hier behandelt)
  • Deploying jobs on GCP services (eher relevant für die Kompromittierung eines Benutzerkontos)

iam.serviceAccounts.getOpenIdToken

Ein Angreifer mit den genannten Berechtigungen kann ein OpenID JWT erzeugen. Diese werden genutzt, um Identität zu bestätigen, und tragen nicht zwangsläufig eine implizite Autorisierung gegenüber einer Ressource.

Laut diesem interessanten Beitrag muss die audience (der Service, bei dem man das Token zur Authentifizierung verwenden möchte) angegeben werden; man erhält dann ein von Google signiertes JWT, das den Service Account und die audience des JWT ausweist.

Man kann ein OpenIDToken (falls man Zugriff hat) wie folgt erzeugen:

# 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 damit auf den Dienst zuzugreifen:

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

Einige Dienste, 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

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstütze HackTricks