GCP - Orgpolicy Privesc

Reading time: 3 minutes

tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

orgpolicy

orgpolicy.policy.set

Um atacante que explora orgpolicy.policy.set pode manipular políticas organizacionais, o que lhe permitirá remover certas restrições que impedem operações específicas. Por exemplo, a restrição appengine.disableCodeDownload normalmente bloqueia o download do código-fonte do App Engine. No entanto, usando orgpolicy.policy.set, um atacante pode desativar essa restrição, obtendo assim acesso para baixar o código-fonte, apesar de ele inicialmente estar protegido.

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

Um script Python para este método pode ser encontrado aqui.

orgpolicy.policy.set, iam.serviceAccounts.actAs

Normalmente não é possível anexar um service account de um projeto diferente a um recurso porque existe uma restrição de policy aplicada chamada iam.disableCrossProjectServiceAccountUsage que impede essa ação.

É possível verificar se essa restrição está aplicada executando o seguinte comando:

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

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

Isso impede que um atacante abuse da permissão iam.serviceAccounts.actAs para se passar por uma conta de serviço de outro projeto sem as permissões adicionais de infra necessárias para iniciar uma nova VM, por exemplo, o que poderia levar à escalada de privilégios.

No entanto, um atacante com a permissão orgpolicy.policy.set pode contornar essa restrição desativando a restrição iam.disableServiceAccountProjectWideAccess. Isso permite que o atacante anexe uma conta de serviço de outro projeto a um recurso em seu próprio projeto, efetivamente elevando seus privilégios.

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

Referências

tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks