GCP - IAM Privesc

Impara l'hacking di AWS da zero a esperto con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

• Se vuoi vedere la tua azienda pubblicizzata in HackTricks o scaricare HackTricks in PDF Controlla i PACCHETTI DI ABBONAMENTO!

• Ottieni il merchandising ufficiale di PEASS & HackTricks

• Scopri The PEASS Family, la nostra collezione di esclusive NFT

• Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.

• Condividi i tuoi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud github repos.

IAM

Trova ulteriori informazioni su IAM in:

pageGCP - 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 ulteriori permessi su altre risorse come:

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

Puoi trovare uno script per automatizzare la creazione, l'exploit e la 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.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 privilegi superiori ai nostri.

Puoi trovare uno script per automatizzare la creazione, l'exploit e la pulizia di un ambiente vulnerabile qui e uno script python per abusare di questo privilegio qui. Per ulteriori 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, 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 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 utilizzare l'implicitDelegation per creare un token per quel terzo Service Account. Qui c'è un diagramma per aiutare a spiegare.

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.

Nota che secondo la documentazione, la delega funziona solo per generare un token utilizzando il metodo generateAccessToken().

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 dell'SA e quindi inviarlo come un blob per ottenere il JWT firmato dall'SA che stiamo mirando. 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 JSON web token (JWT) ben formati. La differenza con il metodo precedente è che anziché far firmare a Google un blob contenente un JWT, utilizziamo il metodo signJWT che si aspetta già un JWT. Questo rende più facile da usare ma è possibile firmare solo JWT anziché 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 sfruttarlo per concederti i permessi necessari per impersonare l'account di servizio. Nell'esempio seguente ci stiamo concedendo il ruolo roles/iam.serviceAccountTokenCreator sull'account di servizio interessante:

gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \
--member="user:[e-mail]" \
--role="roles/iam.serviceAccountTokenCreator"

Puoi trovare uno script per automatizzare la creazione, l'exploit e la pulizia di un ambiente vulnerabile qui.

iam.serviceAccounts.actAs

Il permesso iam.serviceAccounts.actAs è simile al permesso iam:PassRole di AWS. È essenziale per eseguire attività, come l'avvio di un'istanza di Compute Engine, in quanto concede la possibilità di "agire come" un Service Account, garantendo una gestione sicura delle autorizzazioni. Senza questo permesso, gli utenti potrebbero ottenere accessi indebiti. Inoltre, lo sfruttamento di iam.serviceAccounts.actAs prevede vari metodi, ognuno dei quali richiede un insieme di autorizzazioni, a differenza di altri metodi che ne richiedono solo uno.

Impersonificazione di un service account

L'impersonificazione di 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 (descritto sopra)

• Autorizzazione utilizzando le politiche di Cloud IAM (descritto qui)

• Esecuzione di lavori su servizi GCP (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 utilizzati per affermare l'identità e non necessariamente comportano alcuna autorizzazione implicita nei confronti di una risorsa.

Secondo questo interessante post, è necessario indicare l'audience (servizio in cui si desidera utilizzare il token per l'autenticazione) 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

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 (se si utilizza Google OIDC)

È possibile trovare un esempio su come creare un token OpenID a nome di un service account qui.

Riferimenti

• https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/

Impara l'hacking di AWS da zero a esperto con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

• Se vuoi vedere la tua azienda pubblicizzata in HackTricks o scaricare HackTricks in PDF, controlla i PACCHETTI DI ABBONAMENTO!

• Ottieni il merchandising ufficiale di PEASS & HackTricks

• Scopri The PEASS Family, la nostra collezione di esclusive NFT

• Unisciti al 💬 gruppo Discord o al gruppo Telegram o seguici su Twitter 🐦 @hacktricks_live.

• Condividi i tuoi trucchi di hacking inviando PR ai repository di HackTricks e HackTricks Cloud github.