GCP - Orgpolicy Privesc

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, permitindo-lhe 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. Contudo, ao usar orgpolicy.policy.set, o atacante pode desativar essa restrição, ganhando assim acesso para baixar o código-fonte, mesmo que inicialmente estivesse protegido.

Obter informações da org policy e desativar a aplicação ```bash # Get info gcloud resource-manager org-policies describe [--folder | --organization | --project ]

Disable

gcloud resource-manager org-policies disable-enforce [–folder | –organization | –project ]

</details>

Um script python para este método pode ser encontrado [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/orgpolicy.policy.set.py).

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

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

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

<details>
<summary>Verificar restrição de service account entre projetos</summary>
```bash
gcloud resource-manager org-policies describe \
constraints/iam.disableCrossProjectServiceAccountUsage \
--project=<project-id> \
--effective

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

Isto 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 de infraestrutura adicionais necessárias para, por exemplo, iniciar uma nova VM, o que poderia levar a uma escalada de privilégios.

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

Desativar restrição de conta de serviço entre projetos ```bash gcloud resource-manager org-policies disable-enforce \ iam.disableCrossProjectServiceAccountUsage \ --project= ```

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