# GCP - IAM Privesc

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

## IAM

Vind meer inligting oor IAM in:

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

### `iam.roles.update` (`iam.roles.get`)

'n aanvaller met die genoemde permissies kan 'n rol wat aan jou toegeken is wysig en jou ekstra permissies gee vir ander hulpbronne soos:
```bash
gcloud iam roles update <rol name> --project <project> --add-permissions <permission>
```
Jy kan 'n skrip vind om die **skepping, exploit en skoonmaak van 'n vuln-omgewing hier** te outomatiseer en 'n python-skrip om hierdie privilege te misbruik [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.roles.update.py). Vir meer inligting, sien die [**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`
Die iam.roles.create-permissie maak die skepping van pasgemaakte rolle in 'n projek/organisasie moontlik. In die hande van 'n aanvaller is dit gevaarlik, omdat dit hulle in staat stel om nuwe stelle toestemmings te definieer wat later aan entiteite toegeken kan word (byvoorbeeld deur gebruik te maak van die iam.serviceAccounts.setIamPolicy-permissie) met die doel van privilege escalation.
```bash
gcloud iam roles create <ROLE_ID> \
--project=<PROJECT_ID> \
--title="<Title>" \
--description="<Description>" \
--permissions="permission1,permission2,permission3"
```
### `iam.serviceAccounts.getAccessToken` (`iam.serviceAccounts.get`)

'n aanvaller met die genoemde toestemmings sal in staat wees om **request an access token that belongs to a Service Account**, dus is dit moontlik om 'n access token van 'n Service Account te versoek wat meer bevoegdhede het as ons s'n.
```bash
gcloud --impersonate-service-account="${victim}@${PROJECT_ID}.iam.gserviceaccount.com" \
auth print-access-token
```
Jy kan 'n skrip vind om die [**skepping, uitbuiting en skoonmaak van 'n kwesbare omgewing hier**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/4-iam.serviceAccounts.getAccessToken.sh) te outomatiseer en 'n python-skrip om hierdie voorreg [**hier**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getAccessToken.py) te misbruik. Vir meer inligting, sien die [**oorspronklike navorsing**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).

### `iam.serviceAccountKeys.create`

'n aanvaller met die genoemde toestemmings sal in staat wees om **'n gebruikersbeheerde sleutel vir 'n Service Account te skep**, wat ons sal toelaat om toegang tot GCP te kry as daardie 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
```
Jy kan 'n skrip vind om die [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/3-iam.serviceAccountKeys.create.sh) te outomatiseer en 'n python-skrip om hierdie voorreg te misbruik [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccountKeys.create.py). Vir meer inligting sien die [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).

Let wel dat **`iam.serviceAccountKeys.update` nie sal werk om die sleutel van 'n SA te wysig nie** omdat die toestemming `iam.serviceAccountKeys.create` ook nodig is.

### `iam.serviceAccounts.implicitDelegation`

As jy die **`iam.serviceAccounts.implicitDelegation`** toestemming op 'n Service Account het wat die **`iam.serviceAccounts.getAccessToken`** toestemming op 'n derde Service Account het, kan jy implicitDelegation gebruik om **'n token te skep vir daardie derde Service Account**. Hier is 'n diagram om dit te verduidelik.

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

Let wel dat volgens die [**documentation**](https://cloud.google.com/iam/docs/understanding-service-accounts), die delegasie van `gcloud` slegs werk om 'n token te genereer deur gebruik te maak van die [**generateAccessToken()**](https://cloud.google.com/iam/credentials/reference/rest/v1/projects.serviceAccounts/generateAccessToken) metode. Hier is hoe om 'n token direk met die API te kry:
```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"]
}'
```
Jy kan 'n script vind om die [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/5-iam.serviceAccounts.implicitDelegation.sh) te outomatiseer en 'n python script om hierdie voorreg te misbruik [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.implicitDelegation.py). Vir meer inligting kyk die [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).

### `iam.serviceAccounts.signBlob`

'n Aanvaller met die genoemde permissies sal in staat wees om **arbitêre payloads in GCP te onderteken**. Dit maak dit moontlik om **'n ongetekende JWT van die SA te skep en dit dan as 'n blob te stuur om die JWT deur die teiken-SA te laat onderteken**. Vir meer inligting [**read this**](https://medium.com/google-cloud/using-serviceaccountactor-iam-role-for-account-impersonation-on-google-cloud-platform-a9e7118480ed).

Jy kan 'n script vind om die [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/6-iam.serviceAccounts.signBlob.sh) te outomatiseer en 'n python script om hierdie voorreg te misbruik [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-accessToken.py) en [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-gcsSignedUrl.py). Vir meer inligting kyk die [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).

### `iam.serviceAccounts.signJwt`

'n Aanvaller met die genoemde permissies sal in staat wees om **well-formed JSON web tokens (JWTs) te onderteken**. Die verskil met die vorige metode is dat **in plaas daarvan om Google 'n blob wat 'n JWT bevat te laat onderteken, ons die signJWT-metode gebruik wat reeds 'n JWT verwag**. Dit maak dit makliker om te gebruik maar jy kan slegs JWTs teken in plaas van ewekansige bytes.

Jy kan 'n script vind om die [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/7-iam.serviceAccounts.signJWT.sh) te outomatiseer en 'n python script om hierdie voorreg te misbruik [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signJWT.py). Vir meer inligting kyk die [**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>

'n Aanvaller met die genoemde permissies sal in staat wees om **IAM-beleid by service accounts te voeg**. Jy kan dit misbruik om jouself die permissies te gee wat jy nodig het om die service account na te boots. In die volgende voorbeeld gee ons onsself die `roles/iam.serviceAccountTokenCreator` rol oor die interessante SA:
```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"
```
Jy kan 'n skrip vind om die [**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`

Die **iam.serviceAccounts.actAs permission** is soortgelyk aan die **iam:PassRole permission from AWS**. Dit is noodsaaklik vir die uitvoer van take, soos om 'n Compute Engine-instansie te begin, aangesien dit die vermoë gee om as 'n Service Account te "actAs", wat veilige bestuur van permissies moontlik maak. Sonder hierdie toestemming kan gebruikers ongewensde toegang kry. Verder behels die uitbuiting van die **iam.serviceAccounts.actAs** verskeie metodes, wat elk 'n stel toestemmings vereis, in teenstelling met ander metodes wat net een benodig.

#### Service account impersonation <a href="#service-account-impersonation" id="service-account-impersonation"></a>

Die impersonasie van 'n Service Account kan baie nuttig wees om **nuwe en beter bevoegdhede te verkry**. Daar is drie maniere waarop jy 'n [impersonate another service account](https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating_a_service_account):

- Outentisering **using RSA private keys** (hierbo gedek)
- Magtiging **using Cloud IAM policies** (hier gedek)
- **Deploying jobs on GCP services** (meer toepaslik by die kompromittering van 'n gebruikersrekening)

### `iam.serviceAccounts.getOpenIdToken`

'n Aanvaller met die genoemde toestemmings sal 'n OpenID JWT kan genereer. Hierdie tokens word gebruik om identiteit te bevestig en dra nie noodwendig enige implisiete magtiging teenoor 'n bron nie.

Volgens hierdie [**interesting post**](https://medium.com/google-cloud/authenticating-using-google-openid-connect-tokens-e7675051213b), is dit nodig om die audience aan te dui (die diens waarby jy die token wil gebruik om te autentiseer) en jy sal 'n JWT ontvang wat deur google onderteken is en wat die service account en die audience van die JWT aandui.

Jy kan 'n OpenIDToken (as jy die toegang het) genereer met:
```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
```
Dan kan jy dit net gebruik om toegang tot die diens te kry met:
```bash
curl -v -H "Authorization: Bearer id_token" https://some-cloud-run-uc.a.run.app
```
Sommige dienste wat verifikasie via hierdie soort tokens ondersteun, is:

- [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)

Jy kan 'n voorbeeld vind van hoe om 'n OpenID token namens 'n service account te skep [**here**](https://github.com/carlospolop-forks/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getOpenIdToken.py).

## Verwysings

- [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}}
