# GCP - Orgpolicy Privesc

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

## orgpolicy

### `orgpolicy.policy.set`

An attacker leveraging **orgpolicy.policy.set** can manipulate organizational policies, which will allow him to remove certain restrictions impeding specific operations. For instance, the constraint **appengine.disableCodeDownload** usually blocks downloading of App Engine source code. However, by using **orgpolicy.policy.set**, an attacker can deactivate this constraint, thereby gaining access to download the source code, despite it initially being protected.

<details>
<summary>Get org policy info and disable enforcement</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>

A python script for this method can be found [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/orgpolicy.policy.set.py).

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

uusally it's not possible to attach a service account from a different project to a resource becasue there is a policy constraint enforced named **`iam.disableCrossProjectServiceAccountUsage`** that prevents this action.

It's possible to verify if this constraint is enforced by running the following command:

<details>
<summary>Verify cross-project service account constraint</summary>

```bash
gcloud resource-manager org-policies describe \
  constraints/iam.disableCrossProjectServiceAccountUsage \
  --project=<project-id> \
  --effective

booleanPolicy:
  enforced: true
constraint: constraints/iam.disableCrossProjectServiceAccountUsage
```

</details>

This prevents an attacker from abusing the permission **`iam.serviceAccounts.actAs`** to impersonate a service account from another project without needed further infra permissions to start a new VM for example, which could lead to privilege escalation.

However, an attacker with the permissions **`orgpolicy.policy.set`** can bypass this restriction by disabling the constraint **`iam.disableServiceAccountProjectWideAccess`**. This allows the attacker to attach a service account from another project to a resource in his own project, effectively escalating his privileges.

<details>
<summary>Disable cross-project service account constraint</summary>

```bash
gcloud resource-manager org-policies disable-enforce \
  iam.disableCrossProjectServiceAccountUsage \
  --project=<project-id>
```

</details>

## References

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



