# GCP - IAM Privesc

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

## IAM

Trouvez plus d'informations sur IAM dans :

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

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

Un attaquant avec les permissions mentionnées pourra mettre à jour un rôle qui vous est attribué et vous donner des permissions supplémentaires sur d'autres ressources comme :
```bash
gcloud iam roles update <rol name> --project <project> --add-permissions <permission>
```
Vous pouvez trouver un script pour automatiser la **création, l'exploitation et le nettoyage d'un environnement vulnérable ici** et un script python pour abuser de ce privilège [**ici**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.roles.update.py). Pour plus d'informations, consultez la [**recherche originale**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).

### `iam.serviceAccounts.getAccessToken` (`iam.serviceAccounts.get`)

Un attaquant avec les permissions mentionnées sera capable de **demander un jeton d'accès qui appartient à un compte de service**, il est donc possible de demander un jeton d'accès d'un compte de service avec plus de privilèges que les nôtres.
```bash
gcloud --impersonate-service-account="${victim}@${PROJECT_ID}.iam.gserviceaccount.com" \
auth print-access-token
```
Vous pouvez trouver un script pour automatiser la [**création, l'exploitation et le nettoyage d'un environnement vulnérable ici**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/4-iam.serviceAccounts.getAccessToken.sh) et un script python pour abuser de ce privilège [**ici**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getAccessToken.py). Pour plus d'informations, consultez la [**recherche originale**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).

### `iam.serviceAccountKeys.create`

Un attaquant avec les permissions mentionnées sera en mesure de **créer une clé gérée par l'utilisateur pour un compte de service**, ce qui nous permettra d'accéder à GCP en tant que ce compte de service.
```bash
gcloud iam service-accounts keys create --iam-account <name> /tmp/key.json

gcloud auth activate-service-account --key-file=sa_cred.json
```
Vous pouvez trouver un script pour automatiser la [**création, l'exploitation et le nettoyage d'un environnement vulnérable ici**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/3-iam.serviceAccountKeys.create.sh) et un script python pour abuser de ce privilège [**ici**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccountKeys.create.py). Pour plus d'informations, consultez la [**recherche originale**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).

Notez que **`iam.serviceAccountKeys.update` ne fonctionnera pas pour modifier la clé** d'un SA car pour cela, les permissions `iam.serviceAccountKeys.create` sont également nécessaires.

### `iam.serviceAccounts.implicitDelegation`

Si vous avez la permission **`iam.serviceAccounts.implicitDelegation`** sur un compte de service qui a la permission **`iam.serviceAccounts.getAccessToken`** sur un troisième compte de service, alors vous pouvez utiliser implicitDelegation pour **créer un jeton pour ce troisième compte de service**. Voici un diagramme pour aider à expliquer.

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

Notez qu' selon la [**documentation**](https://cloud.google.com/iam/docs/understanding-service-accounts), la délégation de `gcloud` ne fonctionne que pour générer un jeton en utilisant la méthode [**generateAccessToken()**](https://cloud.google.com/iam/credentials/reference/rest/v1/projects.serviceAccounts/generateAccessToken). Voici donc comment obtenir un jeton en utilisant l'API directement :
```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"]
}'
```
Vous pouvez trouver un script pour automatiser la [**création, l'exploitation et le nettoyage d'un environnement vulnérable ici**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/5-iam.serviceAccounts.implicitDelegation.sh) et un script python pour abuser de ce privilège [**ici**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.implicitDelegation.py). Pour plus d'informations, consultez la [**recherche originale**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).

### `iam.serviceAccounts.signBlob`

Un attaquant avec les permissions mentionnées pourra **signer des charges utiles arbitraires dans GCP**. Il sera donc possible de **créer un JWT non signé du SA et de l'envoyer en tant que blob pour obtenir le JWT signé** par le SA que nous ciblons. Pour plus d'informations [**lisez ceci**](https://medium.com/google-cloud/using-serviceaccountactor-iam-role-for-account-impersonation-on-google-cloud-platform-a9e7118480ed).

Vous pouvez trouver un script pour automatiser la [**création, l'exploitation et le nettoyage d'un environnement vulnérable ici**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/6-iam.serviceAccounts.signBlob.sh) et un script python pour abuser de ce privilège [**ici**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-accessToken.py) et [**ici**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-gcsSignedUrl.py). Pour plus d'informations, consultez la [**recherche originale**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).

### `iam.serviceAccounts.signJwt`

Un attaquant avec les permissions mentionnées pourra **signer des jetons web JSON (JWT) bien formés**. La différence avec la méthode précédente est que **au lieu de faire signer un blob contenant un JWT par Google, nous utilisons la méthode signJWT qui attend déjà un JWT**. Cela rend l'utilisation plus facile mais vous ne pouvez signer que des JWT au lieu de n'importe quel octet.

Vous pouvez trouver un script pour automatiser la [**création, l'exploitation et le nettoyage d'un environnement vulnérable ici**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/7-iam.serviceAccounts.signJWT.sh) et un script python pour abuser de ce privilège [**ici**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signJWT.py). Pour plus d'informations, consultez la [**recherche originale**](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 attaquant avec les permissions mentionnées pourra **ajouter des politiques IAM aux comptes de service**. Vous pouvez en abuser pour **vous accorder** les permissions dont vous avez besoin pour usurper le compte de service. Dans l'exemple suivant, nous nous accordons le rôle `roles/iam.serviceAccountTokenCreator` sur le SA intéressant :
```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"
```
Vous pouvez trouver un script pour automatiser la [**création, l'exploitation et le nettoyage d'un environnement vulnérable ici**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/d-iam.serviceAccounts.setIamPolicy.sh)**.**

### `iam.serviceAccounts.actAs`

La **permission iam.serviceAccounts.actAs** est comme la **permission iam:PassRole d'AWS**. Elle est essentielle pour exécuter des tâches, comme initier une instance Compute Engine, car elle accorde la capacité d'"agir en tant que" un compte de service, garantissant une gestion sécurisée des permissions. Sans cela, les utilisateurs pourraient obtenir un accès indû. De plus, exploiter le **iam.serviceAccounts.actAs** implique diverses méthodes, chacune nécessitant un ensemble de permissions, contrairement à d'autres méthodes qui n'ont besoin que d'une seule.

#### Usurpation de compte de service <a href="#service-account-impersonation" id="service-account-impersonation"></a>

Usurper un compte de service peut être très utile pour **obtenir de nouveaux et meilleurs privilèges**. Il existe trois façons d'[usurper un autre compte de service](https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating_a_service_account) :

- Authentification **à l'aide de clés privées RSA** (couverte ci-dessus)
- Autorisation **à l'aide de politiques Cloud IAM** (couverte ici)
- **Déploiement de tâches sur les services GCP** (plus applicable à la compromission d'un compte utilisateur)

### `iam.serviceAccounts.getOpenIdToken`

Un attaquant avec les permissions mentionnées sera capable de générer un OpenID JWT. Ceux-ci sont utilisés pour affirmer l'identité et ne portent pas nécessairement d'autorisation implicite contre une ressource.

Selon ce [**post intéressant**](https://medium.com/google-cloud/authenticating-using-google-openid-connect-tokens-e7675051213b), il est nécessaire d'indiquer l'audience (service où vous souhaitez utiliser le token pour vous authentifier) et vous recevrez un JWT signé par google indiquant le compte de service et l'audience du JWT.

Vous pouvez générer un OpenIDToken (si vous avez l'accès) avec :
```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
```
Vous pouvez alors l'utiliser pour accéder au service avec :
```bash
curl -v -H "Authorization: Bearer id_token" https://some-cloud-run-uc.a.run.app
```
Certains services qui prennent en charge l'authentification via ce type de jetons sont :

- [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) (si vous utilisez Google OIDC)

Vous pouvez trouver un exemple sur la façon de créer un jeton OpenID au nom d'un compte de service [**ici**](https://github.com/carlospolop-forks/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getOpenIdToken.py).

## Références

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