Sponsored

GCP - Orgpolicy Privesc

orgpolicy

orgpolicy.policy.set

An attacker with orgpolicy.policy.set can update organization policies and turn off guardrails that block otherwise permitted operations. This permission is required to call the Organization Policy setOrgPolicy method, and disabling a boolean constraint can reopen the blocked operation.^[1][7]

For example, constraints/appengine.disableCodeDownload disables downloads of source code previously uploaded to App Engine. If enforced, an attacker who can change the policy can disable enforcement and then download that source code.^[1][3]

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

The describe command can show a policy at folder, organization, or project scope, while disable-enforce turns off enforcement of a boolean constraint at that resource.^[4][5]

A Python script for this method can be found here.^[2]

orgpolicy.policy.set, iam.serviceAccounts.actAs

Normally, a service account in one project cannot be attached to a resource in another project when its project enforces iam.disableCrossProjectServiceAccountUsage. This constraint is enforced by default and is configured on the project containing the service account.^[6]

Use the --effective flag to inspect the inherited policy for the project containing the service account.^[4][6]

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

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

The permission iam.serviceAccounts.actAs is required to attach a service account to a resource, and code running on that resource uses the attached service account as its identity. An attacker who already has the permissions needed to create a resource, such as a VM, may therefore use a cross-project privileged service account for escalation if this constraint is not enforced; the constraint blocks that attachment path.^[6]

An attacker with orgpolicy.policy.set can bypass this restriction by disabling iam.disableCrossProjectServiceAccountUsage in the project containing the service account. This re-enables attaching that service account to a resource in another project, potentially escalating privileges when the attacker also has iam.serviceAccounts.actAs and resource-creation permissions.^[5][6][7]

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

References

• [1] Privilege Escalation in Google Cloud Platform - Part 2 (Non-IAM) - Rhino Security Labs
• [2] orgpolicy.policy.set.py - Rhino Security Labs
• [3] Organization policy constraints - Google Cloud Documentation
• [4] gcloud resource-manager org-policies describe - Google Cloud SDK
• [5] gcloud resource-manager org-policies disable-enforce - Google Cloud SDK
• [6] Attach service accounts to resources - Google Cloud Documentation
• [7] Method: organizations.setOrgPolicy - Google Cloud Documentation

[!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)
Browse the full HackTricks Training catalog.

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.

Sponsored