GCP - IAM Privesc
Tip
Impara e pratica il hacking AWS:
HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP:HackTricks Training GCP Red Team Expert (GRTE)
Impara e pratica il hacking Azure:
HackTricks Training Azure Red Team Expert (AzRTE)
Supporta HackTricks
- Controlla i piani di abbonamento!
- Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
- Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos su github.
IAM
Per maggiori informazioni su IAM, vedi:
GCP - IAM, Principals & Org Policies Enum
iam.roles.update (iam.roles.get)
Un attaccante con i permessi sopra menzionati potrà aggiornare un ruolo assegnato e concederti permessi aggiuntivi su altre risorse come:
gcloud iam roles update <rol name> --project <project> --add-permissions <permission>
Puoi trovare uno script per automatizzare la creazione, exploit e cleaning di un ambiente vuln qui e uno script python per abusare di questo privilegio here. Per maggiori informazioni consulta la original research.
gcloud iam roles update <Rol_NAME> --project <PROJECT_ID> --add-permissions <Permission>
iam.roles.create & iam.serviceAccounts.setIamPolicy
Il permesso iam.roles.create consente la creazione di ruoli personalizzati in un progetto/organizzazione. Nelle mani di un attacker, questo è pericoloso perché permette di definire nuovi insiemi di permessi che possono poi essere assegnati ad entità (per esempio, usando il permesso iam.serviceAccounts.setIamPolicy) con l’obiettivo di escalating privileges.
gcloud iam roles create <ROLE_ID> \
--project=<PROJECT_ID> \
--title="<Title>" \
--description="<Description>" \
--permissions="permission1,permission2,permission3"
iam.serviceAccounts.getAccessToken (iam.serviceAccounts.get)
Un attacker con le permissions menzionate sarà in grado di richiedere un access token che appartiene a un Service Account, quindi può richiedere un access token di un Service Account con privilegi superiori ai nostri.
gcloud --impersonate-service-account="${victim}@${PROJECT_ID}.iam.gserviceaccount.com" \
auth print-access-token
Puoi trovare uno script per automatizzare la creation, exploit and cleaning of a vuln environment here e uno script python per abusare di questo privilegio here. Per maggiori informazioni consulta la original research.
iam.serviceAccountKeys.create
Un attacker con i permessi menzionati sarà in grado di create a user-managed key for a Service Account, il che ci permetterà di accedere a GCP come quel Service Account.
gcloud iam service-accounts keys create --iam-account <name> /tmp/key.json
gcloud auth activate-service-account --key-file=sa_cred.json
Puoi trovare uno script per automatizzare la creation, exploit and cleaning of a vuln environment here e uno script python per abusare di questo privilegio here. Per maggiori informazioni consulta la original research.
Nota che iam.serviceAccountKeys.update non funzionerà per modificare la key di una SA perché per farlo è necessario anche il permesso iam.serviceAccountKeys.create.
iam.serviceAccounts.implicitDelegation
Se hai il permesso iam.serviceAccounts.implicitDelegation su una Service Account che ha il permesso iam.serviceAccounts.getAccessToken su una terza Service Account, allora puoi usare implicitDelegation per creare un token per quella terza Service Account. Ecco un diagramma per aiutare a spiegare.

Nota che secondo la documentation, la delegazione di gcloud funziona solo per generare un token usando il metodo generateAccessToken(). Quindi qui trovi come ottenere un token usando direttamente l’API:
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"]
}'
Puoi trovare uno script per automatizzare la creation, exploit and cleaning of a vuln environment here e uno script python per sfruttare questo privilegio here. Per maggiori informazioni consulta la original research.
iam.serviceAccounts.signBlob
Un attaccante con i permessi menzionati potrà firmare payload arbitrari in GCP. Quindi sarà possibile creare un JWT non firmato del SA e poi inviarlo come blob per ottenere il JWT firmato dal SA che stiamo prendendo di mira. Per maggiori informazioni read this.
Puoi trovare uno script per automatizzare la creation, exploit and cleaning of a vuln environment here e uno script python per sfruttare questo privilegio here e here. Per maggiori informazioni consulta la original research.
iam.serviceAccounts.signJwt
Un attaccante con i permessi indicati potrà firmare JSON web tokens (JWT) ben formati. La differenza rispetto al metodo precedente è che invece di far firmare a google un blob contenente un JWT, usiamo il metodo signJWT che si aspetta già un JWT. Questo lo rende più semplice da usare, ma permette di firmare solo JWT invece di qualsiasi sequenza di byte.
Puoi trovare uno script per automatizzare la creation, exploit and cleaning of a vuln environment here e uno script python per sfruttare questo privilegio here. Per maggiori informazioni consulta la original research.
iam.serviceAccounts.setIamPolicy
Un attaccante con i permessi indicati potrà aggiungere policy IAM agli account di servizio. Puoi abusarne per assegnarti i permessi necessari a impersonare l’account di servizio. Nell’esempio seguente ci assegniamo il ruolo roles/iam.serviceAccountTokenCreator sull’SA interessato:
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"
Puoi trovare uno script per automatizzare la creation, exploit and cleaning of a vuln environment here.
iam.serviceAccounts.actAs
La iam.serviceAccounts.actAs permission è come la iam:PassRole permission from AWS. È essenziale per eseguire operazioni, come l’avvio di un’istanza Compute Engine, poiché concede la possibilità di “actAs” a una Service Account, garantendo una gestione sicura dei permessi. Senza questa permission, gli utenti potrebbero ottenere accessi indebiti. Inoltre, sfruttare la iam.serviceAccounts.actAs comporta diversi metodi, ognuno richiedente un insieme di permessi, a differenza di altri metodi che ne richiedono solo uno.
Service account impersonation
Impersonare una service account può essere molto utile per ottenere nuovi e migliori privilegi. Ci sono tre modi in cui puoi impersonate another service account:
- Authentication using RSA private keys (trattato sopra)
- Authorization using Cloud IAM policies (trattato qui)
- Deploying jobs on GCP services (più applicabile alla compromissione di un account utente)
iam.serviceAccounts.getOpenIdToken
Un attaccante con i permessi menzionati sarà in grado di generare un OpenID JWT. Questi vengono usati per attestare l’identità e non portano necessariamente con sé alcuna autorizzazione implicita su una risorsa.
Secondo questo interesting post, è necessario indicare l’audience (il servizio dove vuoi utilizzare il token per autenticarti) e riceverai un JWT firmato da google che indica la service account e l’audience del JWT.
Puoi generare un OpenIDToken (se hai l’accesso) con:
# 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
Quindi puoi semplicemente usarlo per accedere al servizio con:
curl -v -H "Authorization: Bearer id_token" https://some-cloud-run-uc.a.run.app
Alcuni servizi che supportano l’autenticazione tramite questo tipo di token sono:
- Google Cloud Run
- Google Cloud Functions
- Google Identity Aware Proxy
- Google Cloud Endpoints (if using Google OIDC)
You can find an example on how to create and OpenID token behalf a service account here.
Riferimenti
Tip
Impara e pratica il hacking AWS:
HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP:HackTricks Training GCP Red Team Expert (GRTE)
Impara e pratica il hacking Azure:
HackTricks Training Azure Red Team Expert (AzRTE)
Supporta HackTricks
- Controlla i piani di abbonamento!
- Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
- Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos su github.
HackTricks Cloud

