GCP <--> Workspace Pivoting
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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.
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:
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 domínio, 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 privilegios 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.
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:
Esta é uma ferramenta que pode realizar o ataque seguindo estes passos:
Enumerar Projetos GCP usando a API Resource Manager.
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.
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.
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.
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.
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 ainda 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. É importante 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.
Enumerar e criar um novo token de acesso bearer para cada JWT e validar o token contra a API tokeninfo.
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 SA e o usuário a ser personificado. Aqui está como você o utilizaria:
É 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:
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).
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.
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 da 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
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.
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.
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).
Verifique mais enumeração em:
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:
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"
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.
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 da escalada de privilégios em grupos do google, você pode ser capaz de escalar para um grupo com algum tipo de acesso privilegiado ao GCP.
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
