GCP - IAM Privesc

Support HackTricks

IAM

Trova ulteriori 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 su 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 ulteriori informazioni, controlla 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 dei nostri.

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 ulteriori informazioni, controlla 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, 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 ulteriori informazioni, controlla la ricerca originale.

Nota che iam.serviceAccountKeys.update non funzionerà per modificare la chiave di un SA perché per farlo sono necessarie anche le autorizzazioni 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 delega di gcloud funziona solo per generare un token utilizzando il metodo generateAccessToken(). Quindi qui hai come ottenere un token utilizzando 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 ulteriori 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 ottenere il JWT firmato dal SA che stiamo prendendo di mira. Per ulteriori 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 ulteriori informazioni consulta la ricerca originale.

iam.serviceAccounts.signJwt

Un attaccante con i permessi menzionati sarà in grado di firmare token web JSON (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 già si aspetta un JWT. Questo rende più facile l'uso, ma puoi solo firmare 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 ulteriori 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 di cui hai bisogno per impersonare l'account di servizio. Nel seguente esempio ci stiamo concedendo il ruolo roles/iam.serviceAccountTokenCreator sull'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 di Compute Engine, poiché concede la possibilità di "agire come" un Service Account, garantendo una gestione sicura dei permessi. Senza questo, gli utenti potrebbero ottenere accessi indebiti. Inoltre, sfruttare il iam.serviceAccounts.actAs comporta vari metodi, ognuno dei quali richiede un insieme di permessi, a differenza di altri metodi che necessitano solo di uno.

Impersonificazione 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 utilizzando chiavi private RSA (trattato sopra)

  • Autorizzazione utilizzando politiche Cloud IAM (trattato qui)

  • Distribuzione di lavori sui 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 vengono utilizzati per affermare l'identità e non portano necessariamente alcuna autorizzazione implicita contro una risorsa.

Secondo questo interessante post, è necessario indicare il pubblico (servizio in cui si desidera utilizzare il token per autenticarsi) e si riceverà un JWT firmato da google che indica il service account e il pubblico 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

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 account di servizio qui.

Riferimenti

Supporta HackTricks

Last updated