Português - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

GCP <--> Workspace Pivoting

Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras maneiras de apoiar o HackTricks:

De GCP para GWS

Noções básicas de Delegação em Toda a Organização

A delegação em toda a organização 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 toda a organização em nome dos usuários.

Isso basicamente significa que contas de serviço dentro de projetos GCP de uma organização podem ser capazes de se passar por usuários do Workspace da mesma organização (ou até mesmo de uma diferente).

Para obter mais informações sobre como isso funciona exatamente, consulte:

pageGCP - Understanding Domain-Wide Delegation

Comprometer a delegação existente

Se um atacante comprometer algum acesso sobre o GCP e conhecer um e-mail de usuário válido do Workspace (preferencialmente super administrador) da empresa, ele poderia enumerar todos os projetos aos quais tem acesso, enumerar todas as Contas de Serviço dos projetos, verificar a quais contas de serviço ele tem acesso, e repetir todos esses passos com cada CS que ele pode se passar. 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 se passar por usuário com cada conta de serviço.

Observe que ao configurar a delegação em toda a organização, nenhum usuário do Workspace é necessário, portanto, apenas saber um válido é suficiente e necessário para a falsificação. No entanto, os privilégios do usuário falsificado serão usados, então se for Super Administrador você poderá acessar tudo. Se ele não tiver nenhum acesso, isso será inútil.

GCP Generate Delegation Token

Este simples script irá gerar um token OAuth como o usuário delegado que você pode então 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 Gerenciador de Recursos.

  2. Iterar em 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 em 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 é encontrado com permissão relevante na política IAM.

  5. Iterar em cada nova conta de serviço e criar um objeto JWT para ela que é composto pelas credenciais da chave privada SA e um escopo OAuth. O processo de criação de um novo objeto JWT irá iterar em 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 encontramos 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, de acordo com nossa verificação de enumeração de combinações. Em resumo, um único usuário válido do Workspace é suficiente para avançar. Este usuário pode ser definido no arquivo config.yaml do DeleFriend. Se um usuário de workspace alvo ainda 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 observar (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 identidade única por domínio.

  7. Enumerar e criar um novo token de acesso de portador 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 indicando um json com credenciais SA e o usuário a ser impersonificado. Aqui está como você o usaria:

# 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 as Delegações em Toda a Organização 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égio de super administrador para GWS poderia criar uma nova delegação permitindo que as contas de serviço 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 de API diretas e ferramentas CLI. Isso requer a função iam.serviceAccountAdmin ou qualquer função personalizada equipada com a permissão iam.serviceAccounts.create. Uma vez que a conta de serviço é criada, procederemos para gerar um par de chaves relacionado (permissão iam.serviceAccountKeys.create).

  2. Criação de nova delegação: É importante entender que apenas a função de Super Administrador possui a capacidade de configurar a delegação global em toda a organização no Google Workspace e a delegação em toda a organização não pode ser configurada programaticamente, ela só 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 da API → Gerenciar Delegação em Toda a Organização no console de Administração do Google Workspace.

  1. Anexando o privilégio de escopos OAuth: Ao configurar uma nova delegação, o Google requer apenas 2 parâmetros, o ID do Cliente, que é o ID OAuth da conta de serviço do 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. Atuando em nome da identidade alvo: Neste ponto, temos um objeto delegado funcional no GWS. Agora, usando a chave privada da conta de serviço do GCP, podemos realizar chamadas de API (no escopo definido no parâmetro de escopo OAuth) para ativá-lo e atuar 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 a permissão que ele tem para aplicativos de API REST.

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

Delegação entre Organizações

O ID do SA OAuth é global e pode ser usado para delegação entre organizações. Não foi implementada nenhuma restrição para evitar a delegação global cruzada. Em termos simples, contas de serviço de diferentes organizações GCP podem ser usadas para configurar a delegação em toda a organização em outras organizações do Workspace. Isso resultaria em apenas precisar de acesso de Super Administrador ao Workspace, e não ao mesmo 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 permissão para criar novos projetos, e quando um novo projeto é criado o criador recebe a função de Proprietário sobre ele.

Portanto, um usuário pode criar um projeto, ativar 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 ter 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:

pageGCP - IAM, Principals & Org Policies Enum

Abusando do Gcloud

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

pageGCP - Non-svc Persistance

Como explicado lá, o gcloud pode solicitar o escopo https://www.googleapis.com/auth/drive que permitiria a um usuário acessar a unidade do usuário. Como 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 à unidade 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 no 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 irá chamar o gcloud auth login, ele provavelmente não suspeitará de nada.

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

Do GWS para o 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, mover 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 de Grupos do Google

Por padrão, os usuários podem se juntar livremente aos 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 escalamento de privilégios de grupos do Google, você pode ser capaz de escalar para um grupo com algum tipo de acesso privilegiado ao GCP.

Referências

Aprenda hacking na AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras maneiras de apoiar o HackTricks:

AnteriorGCP - Storage EnumSiguienteGCP - Understanding Domain-Wide Delegation

Última actualización