Português - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

GCP <--> Workspace Pivoting

Support HackTricks

De GCP para GWS

Noções básicas de Delegação em Larga Escala

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.

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:

Comprometendo a delegação existente

Se um atacante comprometeu algum acesso sobre 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 ser. 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.

Observe que ao configurar a delegação em larga escala, nenhum usuário do Workspace é necessário, portanto, apenas saber que 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 Gerar Token de Delegação

Este script simples irá gerar um token OAuth como o usuário delegado que você pode usar para acessar outras APIs do Google com ou sem gcloud:

# Impersonate indicated user
python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-key-file>

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

DeleFriend

Esta é uma ferramenta que pode realizar o ataque seguindo estes passos:

  1. Enumerar Projetos GCP usando a API do Resource Manager.

  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 essa permissão por padrão.

  4. Criar uma nova chave privada KEY_ALG_RSA_2048 para cada recurso da conta de serviço que foi 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 todas as identidades 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. É 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.

  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

O Gitlab criou este script Python 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:

# Install requirements
pip install --upgrade --user oauth2client

# Validate access only
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com

# List the directory
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com \
--list

# Create a new admin account
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com \
--account pwned

Criar uma nova delegação (Persistência)

É possível verificar Delegações de Domínio Amplo em 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:

  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.

  1. 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 GCP, e escopos OAuth que definem quais chamadas de API a delegação requer.

  • A lista completa de escopos OAuth pode ser encontrada aqui, mas aqui está uma recomendação: 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

  1. Agindo em nome da identidade alvo: Neste ponto, temos um objeto delegado funcional no GWS. Agora, usando a chave privada da Conta de Serviço GCP, podemos realizar chamadas de API (no escopo definido no parâmetro de escopo OAuth) para acioná-lo e agir em nome de qualquer identidade que exista no Google Workspace. Como aprendemos, a conta de serviço gerará tokens de acesso conforme suas necessidades e de acordo com as permissões que possui para aplicações REST API.

  • Verifique a seção anterior para algumas ferramentas para usar esta delegação.

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 controlada pessoalmente.

Criando um Projeto para enumerar o Workspace

Por padrão, os usuários do Workspace têm a permissão para criar novos projetos, e quando um novo projeto é criado, o criador recebe o papel de Proprietário sobre ele.

Portanto, um usuário pode criar um projeto, habilitar as APIs para enumerar o Workspace em seu novo projeto e tentar enumerá-lo.

Para que um usuário possa enumerar o Workspace, ele também precisa de permissões suficientes no Workspace (nem todo usuário poderá enumerar o diretório).

# Create project
gcloud projects create <uniq-projec-name> --name=proj-name
# Set project
gcloud config set project <uniq-projec-name>
# Enable svcs
gcloud services enable admin.googleapis.com
gcloud services enable cloudidentity.googleapis.com
# Get org ID
gcloud organizations list
# Get currents email user groups (at least you can check the groups and members of the groups you belong to)
gcloud identity groups memberships search-transitive-groups --member-email <email> --labels=cloudidentity.googleapis.com/groups.discussion_forum
gcloud identity groups memberships list --group-email=g<group-email>

# FROM HERE THE USER NEEDS TO HAVE ENOUGH WORKSPACE ACCESS
gcloud beta identity groups preview --customer <org-cust-id>

Verifique mais enumeração em:

Abusando credenciais do Gcloud

Você pode encontrar mais informações sobre o fluxo gcloud para login em:

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:

gcloud auth login --enable-gdrive-access

Se um atacante comprometer o computador de um usuário, ele também poderá modificar o arquivo google-cloud-sdk/lib/googlecloudsdk/core/config.py e adicionar em CLOUDSDK_SCOPES o escopo 'https://www.googleapis.com/auth/drive':

Portanto, na próxima vez que o usuário fizer login, ele criará um token com acesso ao drive que o atacante poderá abusar para acessar o drive. Obviamente, o navegador indicará que o token gerado terá acesso ao drive, mas como o usuário chamará a si mesmo o gcloud auth login, ele provavelmente não suspeitará de nada.

Para listar arquivos do drive: curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"

De GWS para GCP

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, a transição de GWS para GCP geralmente é mais "simples" apenas porque os usuários no GWS têm altos privilégios sobre o GCP.

Escalonamento de Privilégios em Grupos do Google

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/).

Abusando do google groups privesc, você pode ser capaz de escalar para um grupo com algum tipo de acesso privilegiado ao GCP.

Referências

Support HackTricks
PreviousGCP - Workflows EnumNextGCP - Understanding Domain-Wide Delegation

Last updated