Italian - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

GCP - IAM Privesc

Supporta HackTricks

IAM

Trova maggiori informazioni su IAM in:

GCP - IAM, Principals & Org Policies Enum

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

Un attaccante con i permessi menzionati sarà in grado di aggiornare un ruolo assegnato a te e darti permessi extra ad altre risorse come:

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

Puoi trovare uno script per automatizzare la creazione, sfruttamento e 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.getAccessToken (iam.serviceAccounts.get)

Un attaccante con i permessi menzionati sarà in grado di richiedere un token di accesso che appartiene a un Service Account, quindi è possibile richiedere un token di accesso di un Service Account con più privilegi del nostro.

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

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

iam.serviceAccountKeys.create

Un attaccante con i permessi menzionati sarà in grado di creare una chiave gestita dall'utente per un 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 creazione, sfruttamento e pulizia di un ambiente vulnerabile qui e uno script python per abusare di questo privilegio qui. Per maggiori informazioni consulta la ricerca originale.

Nota che iam.serviceAccountKeys.update non funzionerà per modificare la chiave di un SA perché per farlo è necessario anche 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. Ecco un diagramma per aiutare a spiegare.

Nota che secondo la documentazione, la delegazione di gcloud funziona solo per generare un token usando il metodo generateAccessToken(). Quindi ecco 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 creazione, sfruttamento e 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. Sarà quindi 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 leggi questo.

Puoi trovare uno script per automatizzare la creazione, sfruttamento e 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 token (JWT) ben formati. La differenza con il metodo precedente è che invece di far firmare a Google un blob contenente un JWT, utilizziamo il metodo signJWT che si aspetta già un JWT. Questo lo rende più facile da usare ma puoi firmare solo JWT invece di qualsiasi byte.

Puoi trovare uno script per automatizzare la creazione, sfruttamento e 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 politiche IAM agli account di servizio. Puoi abusarne per concederti i permessi necessari per impersonare l'account di servizio. Nel seguente esempio ci stiamo concedendo il ruolo roles/iam.serviceAccountTokenCreator sul SA interessante:

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, sfruttamento e pulizia di un ambiente vulnerabile qui.

iam.serviceAccounts.actAs

Il permesso iam.serviceAccounts.actAs è simile al permesso iam:PassRole di AWS. È essenziale per eseguire compiti, come avviare un'istanza Compute Engine, poiché concede la capacità di "actAs" un Service Account, garantendo una gestione sicura dei permessi. Senza questo, gli utenti potrebbero ottenere accessi indebiti. Inoltre, sfruttare il iam.serviceAccounts.actAs implica vari metodi, ciascuno richiedendo un set di permessi, a differenza di altri metodi che ne richiedono solo uno.

Impersonazione di un service account

Impersonare un service account può essere molto utile per ottenere nuovi e migliori privilegi. Ci sono tre modi in cui puoi impersonare un altro service account:

  • Autenticazione usando chiavi private RSA (coperto sopra)

  • Autorizzazione usando politiche Cloud IAM (coperto qui)

  • Distribuzione di lavori su servizi GCP (più applicabile al compromesso di un account utente)

iam.serviceAccounts.getOpenIdToken

Un attaccante con i permessi menzionati sarà in grado di generare un OpenID JWT. Questi sono usati per affermare l'identità e non necessariamente portano alcuna autorizzazione implicita contro una risorsa.

Secondo questo post interessante, è necessario indicare l'audience (servizio dove 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 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
Poi 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 token OpenID per conto di un service account qui.

Riferimenti

Supporta HackTricks
PreviousGCP - Deploymentmaneger PrivescNextGCP - KMS Privesc

Last updated