mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-02-05 11:26:11 -08:00
Translated ['src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting
This commit is contained in:
Translator
@@ -4,12 +4,12 @@
|
||||
|
||||
## **De GCP para GWS**
|
||||
|
||||
### **Noções básicas de Delegação em Domínio**
|
||||
### **Noções básicas de Delegação em Larga Escala**
|
||||
|
||||
A delegação em domínio do Google Workspace permite que um objeto de identidade, seja um **aplicativo externo** do Google Workspace Marketplace ou uma **Conta de Serviço GCP** interna, **acesse dados em todo o Workspace em nome dos usuários**.
|
||||
A delegação em larga escala do Google Workspace permite que um objeto de identidade, seja um **aplicativo externo** do Google Workspace Marketplace ou uma **Conta de Serviço GCP** interna, **acesse dados em todo o Workspace em nome dos usuários**.
|
||||
|
||||
> [!NOTE]
|
||||
> Isso basicamente significa que **contas de serviço** dentro dos projetos GCP de uma organização podem ser capazes de **fingir ser usuários do Workspace** da mesma organização (ou até mesmo de uma diferente).
|
||||
> Isso basicamente significa que **contas de serviço** dentro dos projetos GCP de uma organização podem ser capazes de **impersonar usuários do Workspace** da mesma organização (ou até mesmo de uma diferente).
|
||||
|
||||
Para mais informações sobre como isso funciona exatamente, consulte:
|
||||
|
||||
@@ -19,11 +19,11 @@ gcp-understanding-domain-wide-delegation.md
|
||||
|
||||
### Comprometendo a delegação existente
|
||||
|
||||
Se um atacante **comprometeu algum acesso ao GCP** e **conhece um e-mail de usuário válido do Workspace** (preferencialmente **super admin**) da empresa, ele poderia **enumerar todos os projetos** aos quais tem acesso, **enumerar todas as SAs** dos projetos, verificar a quais **contas de serviço ele tem acesso** e **repetir** todas essas etapas com cada SA que pode fingir.\
|
||||
Com uma **lista de todas as contas de serviço** às quais ele tem **acesso** e a lista de **e-mails do Workspace**, o atacante poderia tentar **fingir ser o usuário com cada conta de serviço**.
|
||||
Se um atacante **comprometeu algum acesso ao GCP** e **conhece um e-mail de usuário válido do Workspace** (preferencialmente **super admin**) da empresa, ele poderia **enumerar todos os projetos** aos quais tem acesso, **enumerar todas as SAs** dos projetos, verificar a quais **contas de serviço ele tem acesso** e **repetir** todas essas etapas com cada SA que pode impersonar.\
|
||||
Com uma **lista de todas as contas de serviço** às quais ele tem **acesso** e a lista de **e-mails do Workspace**, o atacante poderia tentar **impersonar o usuário com cada conta de serviço**.
|
||||
|
||||
> [!CAUTION]
|
||||
> Note que ao configurar a delegação em domínio, nenhum usuário do Workspace é necessário, portanto, apenas saber que **um válido é suficiente e necessário para a impersonação**.\
|
||||
> Note que ao configurar a delegação em larga escala, nenhum usuário do Workspace é necessário, portanto, apenas saber **um válido é suficiente e necessário para a impersonação**.\
|
||||
> No entanto, os **privilégios do usuário impersonado serão utilizados**, então se for Super Admin, você poderá acessar tudo. Se não tiver nenhum acesso, isso será inútil.
|
||||
|
||||
#### [GCP Generate Delegation Token](https://github.com/carlospolop/gcp_gen_delegation_token)
|
||||
@@ -36,22 +36,26 @@ python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-ke
|
||||
# Impersonate indicated user and add additional scopes
|
||||
python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-key-file> --scopes "https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/admin.directory.group, https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.domain, https://mail.google.com/, https://www.googleapis.com/auth/drive, openid"
|
||||
```
|
||||
#### [**DelePwn**](https://github.com/n0tspam/delepwn)
|
||||
|
||||
Baseado na ferramenta DeleFriend, mas com algumas adições, como a capacidade de enumerar o domínio, drive, gmail, calendário e realizar outras operações.
|
||||
|
||||
#### [**DeleFriend**](https://github.com/axon-git/DeleFriend)
|
||||
|
||||
Esta é uma ferramenta que pode realizar o ataque seguindo estes passos:
|
||||
|
||||
1. **Enumerar Projetos GCP** usando a API Resource Manager.
|
||||
2. Iterar sobre cada recurso do projeto e **enumerar recursos de conta de serviço GCP** aos quais o usuário IAM inicial tem acesso usando _GetIAMPolicy_.
|
||||
3. Iterar sobre **cada função de conta de serviço** e encontrar funções integradas, básicas e personalizadas com permissão _**serviceAccountKeys.create**_ no recurso de conta de serviço alvo. Deve-se notar que a função Editor possui essa permissão por padrão.
|
||||
4. Criar uma **nova chave privada `KEY_ALG_RSA_2048`** para cada recurso de conta de serviço que for encontrado com a permissão relevante na política IAM.
|
||||
2. Iterar sobre cada recurso do projeto e **enumerar os recursos da conta de serviço GCP** aos quais o usuário IAM inicial tem acesso usando _GetIAMPolicy_.
|
||||
3. Iterar sobre **cada função da conta de serviço** e encontrar funções integradas, básicas e personalizadas com permissão _**serviceAccountKeys.create**_ no recurso da conta de serviço alvo. Deve-se notar que a função Editor possui inerentemente essa permissão.
|
||||
4. Criar uma **nova chave privada `KEY_ALG_RSA_2048`** para cada recurso da conta de serviço que for encontrado com a permissão relevante na política IAM.
|
||||
5. Iterar sobre **cada nova conta de serviço e criar um `JWT`** **objeto** para ela, que é composto pelas credenciais da chave privada da SA e um escopo OAuth. O processo de criação de um novo objeto _JWT_ irá **iterar sobre todas as combinações existentes de escopos OAuth** da lista **oauth_scopes.txt**, a fim de encontrar todas as possibilidades de delegação. A lista **oauth_scopes.txt** é atualizada com todos os escopos OAuth que consideramos relevantes para abusar das identidades do Workspace.
|
||||
6. O método `_make_authorization_grant_assertion` revela a necessidade de declarar um **usuário de workspace alvo**, referido como _subject_, para gerar JWTs sob DWD. Embora isso possa parecer exigir um usuário específico, é importante perceber que **DWD influencia toda identidade dentro de um domínio**. Consequentemente, criar um JWT para **qualquer usuário de domínio** afeta todas as identidades nesse domínio, consistente com nossa verificação de enumeração de combinações. Simplificando, um usuário válido do Workspace é suficiente para prosseguir.\
|
||||
Esse usuário pode ser definido no arquivo _config.yaml_ do DeleFriend. Se um usuário de workspace alvo não for conhecido, a ferramenta facilita a identificação automática de usuários válidos do workspace, escaneando usuários de domínio com funções em projetos GCP. É fundamental notar (novamente) que os JWTs são específicos do domínio e não gerados para cada usuário; portanto, o processo automático visa uma única identidade única por domínio.
|
||||
6. O método `_make_authorization_grant_assertion` revela a necessidade de declarar um **usuário de workspace alvo**, referido como _subject_, para gerar JWTs sob DWD. Embora isso possa parecer exigir um usuário específico, é importante perceber que **DWD influencia toda identidade dentro de um domínio**. Consequentemente, criar um JWT para **qualquer usuário do domínio** afeta todas as identidades nesse domínio, consistente com nossa verificação de enumeração de combinações. Simplificando, um usuário válido do Workspace é suficiente para prosseguir.\
|
||||
Esse usuário pode ser definido no arquivo _config.yaml_ do DeleFriend. Se um usuário de workspace alvo não for conhecido, a ferramenta facilita a identificação automática de usuários válidos do workspace, escaneando usuários do domínio com funções em projetos GCP. É fundamental notar (novamente) que os JWTs são específicos do domínio e não gerados para cada usuário; portanto, o processo automático visa uma única identidade única por domínio.
|
||||
7. **Enumerar e criar um novo token de acesso bearer** para cada JWT e validar o token contra a API tokeninfo.
|
||||
|
||||
#### [Script Python do Gitlab](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/gcp_misc/-/blob/master/gcp_delegation.py)
|
||||
|
||||
O Gitlab criou [este script Python](https://gitlab.com/gitlab-com/gl-security/gl-redteam/gcp_misc/blob/master/gcp_delegation.py) que pode fazer duas coisas - listar o diretório de usuários e criar uma nova conta administrativa enquanto indica um json com credenciais de SA e o usuário a ser personificado. Aqui está como você o utilizaria:
|
||||
O Gitlab criou [este script Python](https://gitlab.com/gitlab-com/gl-security/gl-redteam/gcp_misc/blob/master/gcp_delegation.py) que pode fazer duas coisas - listar o diretório de usuários e criar uma nova conta administrativa enquanto indica um json com credenciais SA e o usuário a ser personificado. Aqui está como você o utilizaria:
|
||||
```bash
|
||||
# Install requirements
|
||||
pip install --upgrade --user oauth2client
|
||||
@@ -77,9 +81,9 @@ pip install --upgrade --user oauth2client
|
||||
|
||||
É possível **verificar Delegações de Domínio Amplo em** [**https://admin.google.com/u/1/ac/owl/domainwidedelegation**](https://admin.google.com/u/1/ac/owl/domainwidedelegation)**.**
|
||||
|
||||
Um atacante com a capacidade de **criar contas de serviço em um projeto GCP** e **privilégios de super administrador no GWS poderia criar uma nova delegação permitindo que SAs impersonem alguns usuários do GWS:**
|
||||
Um atacante com a capacidade de **criar contas de serviço em um projeto GCP** e **privilégios de super administrador no GWS pode criar uma nova delegação permitindo que SAs se façam passar por alguns usuários do GWS:**
|
||||
|
||||
1. **Gerando uma Nova Conta de Serviço e Par de Chaves Correspondente:** No GCP, novos recursos de conta de serviço podem ser produzidos interativamente via console ou programaticamente usando chamadas diretas de API e ferramentas CLI. Isso requer o **papel `iam.serviceAccountAdmin`** ou qualquer papel personalizado equipado com a **permissão `iam.serviceAccounts.create`**. Uma vez que a conta de serviço é criada, procederemos a gerar um **par de chaves relacionado** (**permissão `iam.serviceAccountKeys.create`**).
|
||||
1. **Gerando uma Nova Conta de Serviço e Par de Chaves Correspondente:** No GCP, novos recursos de conta de serviço podem ser produzidos interativamente via console ou programaticamente usando chamadas diretas de API e ferramentas de CLI. Isso requer o **papel `iam.serviceAccountAdmin`** ou qualquer papel personalizado equipado com a **permissão `iam.serviceAccounts.create`**. Uma vez que a conta de serviço é criada, procederemos a gerar um **par de chaves relacionado** (**permissão `iam.serviceAccountKeys.create`**).
|
||||
2. **Criação de nova delegação**: É importante entender que **apenas o papel de Super Admin possui a capacidade de configurar delegação global de Domínio Amplo no Google Workspace** e a delegação de Domínio Amplo **não pode ser configurada programaticamente,** ela pode ser criada e ajustada **manualmente** através do **console** do Google Workspace.
|
||||
- A criação da regra pode ser encontrada na página **Controles de API → Gerenciar delegação de Domínio Amplo no console de administração do Google Workspace**.
|
||||
3. **Anexando privilégios de escopos OAuth**: Ao configurar uma nova delegação, o Google requer apenas 2 parâmetros, o ID do Cliente, que é o **ID OAuth do recurso de Conta de Serviço do GCP**, e **escopos OAuth** que definem quais chamadas de API a delegação requer.
|
||||
@@ -89,7 +93,7 @@ Um atacante com a capacidade de **criar contas de serviço em um projeto GCP** e
|
||||
|
||||
#### Delegação Interorganizacional
|
||||
|
||||
O ID SA OAuth é global e pode ser usado para **delegação interorganizacional**. Não houve restrição implementada para impedir a delegação global cruzada. Em termos simples, **contas de serviço de diferentes organizações GCP podem ser usadas para configurar delegação de domínio amplo em outras organizações Workspace**. Isso resultaria em **apenas precisar de acesso de Super Admin ao Workspace**, e não acesso à mesma conta GCP, já que o adversário pode criar Contas de Serviço e chaves privadas em sua conta GCP pessoalmente controlada.
|
||||
O ID SA OAuth é global e pode ser usado para **delegação interorganizacional**. Não houve restrição implementada para impedir a delegação global cruzada. Em termos simples, **contas de serviço de diferentes organizações GCP podem ser usadas para configurar delegação de domínio amplo em outras organizações do Workspace**. Isso resultaria em **apenas precisar de acesso de Super Admin ao Workspace**, e não acesso à mesma conta GCP, já que o adversário pode criar Contas de Serviço e chaves privadas em sua conta GCP pessoalmente controlada.
|
||||
|
||||
### Criando um Projeto para enumerar o Workspace
|
||||
|
||||
@@ -150,7 +154,7 @@ Se um atacante comprometer o computador de um usuário, ele também poderá modi
|
||||
|
||||
Se um atacante tiver acesso completo ao GWS, ele poderá acessar grupos com acesso privilegiado ao GCP ou até mesmo usuários, portanto, mover-se do GWS para o GCP é geralmente mais "simples" apenas porque **os usuários no GWS têm altos privilégios sobre o GCP**.
|
||||
|
||||
### Escalada de Privilégios do Google Groups
|
||||
### Escalonamento de Privilégios do Google Groups
|
||||
|
||||
Por padrão, os usuários podem **entrar livremente em grupos do Workspace da Organização** e esses grupos **podem ter permissões do GCP** atribuídas (verifique seus grupos em [https://groups.google.com/](https://groups.google.com/)).
|
||||
|
||||
|
||||
Reference in New Issue
Block a user