mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-02-04 19:11:41 -08:00
Translated ['src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting
This commit is contained in:
Translator
@@ -9,7 +9,7 @@
|
||||
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**.
|
||||
|
||||
> [!NOTE]
|
||||
> 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).
|
||||
> 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).
|
||||
|
||||
Para mais informações sobre como isso funciona exatamente, consulte:
|
||||
|
||||
@@ -19,8 +19,8 @@ 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 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**.
|
||||
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**.
|
||||
|
||||
> [!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**.\
|
||||
@@ -40,13 +40,13 @@ python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-ke
|
||||
|
||||
Esta é uma ferramenta que pode realizar o ataque seguindo estes passos:
|
||||
|
||||
1. **Enumerar Projetos GCP** usando a API do Resource Manager.
|
||||
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 da 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 foi encontrado com 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_ **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 todas as identidades 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 de workspace válidos, escaneando usuários de domínio com funções em projetos GCP. É importante notar (novamente) que os JWTs são específicos do domínio e não são gerados para cada usuário; portanto, o processo automático visa uma única identidade única por domínio.
|
||||
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.
|
||||
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.
|
||||
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)
|
||||
@@ -77,9 +77,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 pode criar uma nova delegação permitindo que SAs se façam passar por 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 poderia criar uma nova delegação permitindo que SAs impersonem 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 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`**).
|
||||
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`**).
|
||||
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 +89,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ções implementadas 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 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
|
||||
|
||||
@@ -127,10 +127,10 @@ Verifique **mais enumeração em**:
|
||||
Você pode encontrar mais informações sobre o fluxo `gcloud` para login em:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-persistence/gcp-non-svc-persistance.md
|
||||
../gcp-persistence/gcp-non-svc-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
Conforme explicado lá, o gcloud pode solicitar o escopo **`https://www.googleapis.com/auth/drive`** que permitiria a um usuário acessar o drive do usuário.\
|
||||
Como explicado lá, o gcloud pode solicitar o escopo **`https://www.googleapis.com/auth/drive`** que permitiria a um usuário acessar o drive do usuário.\
|
||||
Como um atacante, se você comprometeu **fisicamente** o computador de um usuário e o **usuário ainda está logado** com sua conta, você poderia fazer login gerando um token com acesso ao drive usando:
|
||||
```bash
|
||||
gcloud auth login --enable-gdrive-access
|
||||
@@ -148,9 +148,9 @@ Se um atacante comprometer o computador de um usuário, ele também poderá modi
|
||||
|
||||
### Acesso a usuários privilegiados do GCP
|
||||
|
||||
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 de GWS para GCP é geralmente mais "simples" apenas porque **os usuários no GWS têm altos privilégios sobre o GCP**.
|
||||
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**.
|
||||
|
||||
### Escalonamento de Privilégios do Google Groups
|
||||
### Escalada 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/)).
|
||||
|
||||
|
||||
@@ -12,13 +12,13 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/phishing-met
|
||||
|
||||
Aparentemente, por padrão, em workspace os membros [**podem criar grupos**](https://groups.google.com/all-groups) **e convidar pessoas para eles**. Você pode então modificar o e-mail que será enviado ao usuário **adicionando alguns links.** O **e-mail virá de um endereço google**, então parecerá **legítimo** e as pessoas podem clicar no link.
|
||||
|
||||
Também é possível definir o endereço **FROM** como o **e-mail do grupo Google** para enviar **mais e-mails para os usuários dentro do grupo**, como na imagem a seguir onde o grupo **`google--support@googlegroups.com`** foi criado e um **e-mail foi enviado a todos os membros** do grupo (que foram adicionados sem qualquer consentimento)
|
||||
Também é possível definir o endereço **FROM** como o **e-mail do grupo Google** para enviar **mais e-mails para os usuários dentro do grupo**, como na imagem a seguir, onde o grupo **`google--support@googlegroups.com`** foi criado e um **e-mail foi enviado a todos os membros** do grupo (que foram adicionados sem qualquer consentimento)
|
||||
|
||||
<figure><img src="../../../images/image (5) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Google Chat Phishing
|
||||
|
||||
Você pode ser capaz de **iniciar um chat** com uma pessoa apenas tendo seu endereço de e-mail ou enviar um **convite para conversar**. Além disso, é possível **criar um Espaço** que pode ter qualquer nome (por exemplo, "Suporte Google") e **convidar** membros para isso. Se eles aceitarem, podem pensar que estão conversando com o Suporte Google:
|
||||
Você pode ser capaz de **iniciar um chat** com uma pessoa apenas tendo seu endereço de e-mail ou enviar um **convite para conversar**. Além disso, é possível **criar um Espaço** que pode ter qualquer nome (por exemplo, "Suporte Google") e **convidar** membros para ele. Se eles aceitarem, podem pensar que estão conversando com o Suporte Google:
|
||||
|
||||
<figure><img src="../../../images/image (6).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -69,9 +69,9 @@ Por exemplo, acessando [https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G3
|
||||
> [!TIP]
|
||||
> Note que um aviso aparecerá enquanto o conteúdo é carregado dentro de um iframe.
|
||||
|
||||
## Phishing de OAuth em App Scripts
|
||||
## Phishing de OAuth de App Scripts
|
||||
|
||||
É possível criar App Scripts anexados a documentos para tentar obter acesso ao token OAuth de uma vítima, para mais informações, consulte:
|
||||
É possível criar App Scripts anexados a documentos para tentar obter acesso ao token OAuth de uma vítima, para mais informações consulte:
|
||||
|
||||
{{#ref}}
|
||||
gws-app-scripts.md
|
||||
@@ -91,9 +91,9 @@ Quando um **usuário** deseja **usar** essa **aplicação**, ele será **solicit
|
||||
|
||||
Esta é uma maneira muito atraente de **phish** usuários não técnicos para usar **aplicações que acessam informações sensíveis** porque eles podem não entender as consequências. No entanto, em contas de organizações, existem maneiras de evitar que isso aconteça.
|
||||
|
||||
### Aviso de Aplicativo Não Verificado
|
||||
### Aviso de App Não Verificado
|
||||
|
||||
Como foi mencionado, o Google sempre apresentará um **aviso ao usuário para aceitar** as permissões que estão concedendo à aplicação em seu nome. No entanto, se a aplicação for considerada **perigosa**, o Google mostrará **primeiro** um **aviso** indicando que é **perigosa** e **dificultando** para o usuário conceder as permissões ao app.
|
||||
Como foi mencionado, o Google sempre apresentará um **aviso ao usuário para aceitar** as permissões que estão concedendo à aplicação em seu nome. No entanto, se a aplicação for considerada **perigosa**, o Google mostrará **primeiro** um **aviso** indicando que é **perigosa** e **dificultando mais** para o usuário conceder as permissões ao app.
|
||||
|
||||
Esse aviso aparece em apps que:
|
||||
|
||||
@@ -118,14 +118,14 @@ Esse aviso aparece em apps que:
|
||||
4. **Selecione** os **escopos OAuth**.
|
||||
- Esta página é dividida em permissões não sensíveis, permissões sensíveis e permissões restritas. Sempre que você adicionar uma nova permissão, ela é adicionada em sua categoria. Dependendo das permissões solicitadas, diferentes avisos aparecerão para o usuário indicando quão sensíveis essas permissões são.
|
||||
- Tanto **`admin.directory.user.readonly`** quanto **`cloud-platform`** são permissões sensíveis.
|
||||
5. **Adicione os usuários de teste.** Enquanto o status do app for de teste, apenas esses usuários poderão acessar o app, então certifique-se de **adicionar o e-mail que você vai phish**.
|
||||
5. **Adicione os usuários de teste.** Enquanto o status do app for teste, apenas esses usuários poderão acessar o app, então certifique-se de **adicionar o e-mail que você vai phish**.
|
||||
|
||||
Agora vamos obter **credenciais para uma aplicação web** usando o **ID de Cliente OAuth criado anteriormente**:
|
||||
|
||||
1. Volte para [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient), uma opção diferente aparecerá desta vez.
|
||||
2. Selecione **criar credenciais para uma aplicação web**
|
||||
2. Selecione **criar credenciais para uma aplicação Web**
|
||||
3. Defina os **origens Javascript** e **URIs de redirecionamento** necessários
|
||||
- Você pode definir em ambos algo como **`http://localhost:8000/callback`** para testes
|
||||
- Você pode definir em ambos algo como **`http://localhost:8000/callback`** para teste
|
||||
4. Obtenha suas **credenciais da aplicação**
|
||||
|
||||
Finalmente, vamos **executar uma aplicação web que usará as credenciais da aplicação OAuth**. Você pode encontrar um exemplo em [https://github.com/carlospolop/gcp_oauth_phishing_example](https://github.com/carlospolop/gcp_oauth_phishing_example).
|
||||
@@ -142,7 +142,7 @@ Vá para **`http://localhost:8000`**, clique no botão Login with Google, você
|
||||
O aplicativo mostrará o **token de acesso e o token de atualização** que podem ser facilmente usados. Para mais informações sobre **como usar esses tokens, verifique**:
|
||||
|
||||
{{#ref}}
|
||||
../../gcp-security/gcp-persistence/gcp-non-svc-persistance.md
|
||||
../../gcp-security/gcp-persistence/gcp-non-svc-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
#### Usando `glcoud`
|
||||
|
||||
Reference in New Issue
Block a user