GCP <--> Workspace Pivoting
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:
GCP - Understanding Domain-Wide DelegationComprometer a delegação existente
Se um atacante comprometer algum acesso no 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.
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
:
Esta é uma ferramenta que pode realizar o ataque seguindo estes passos:
Enumerar Projetos GCP usando a API do Gerenciador de Recursos.
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.
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.
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.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.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 termos simples, 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. É fundamental 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.Enumerar e criar um novo token de acesso de portador 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 indicando um json com credenciais SA e o usuário a ser impersonificado. Aqui está como você o utilizaria:
Criar uma nova delegação (Persistência)
É possível verificar 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:
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ãoiam.serviceAccounts.create
. Uma vez que a conta de serviço é criada, procederemos para gerar um par de chaves relacionadas (permissãoiam.serviceAccountKeys.create
).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 de API → Gerenciar Delegação em Toda a Organização no console de Administração do Google Workspace.
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
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 de acordo com 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 Cruzada entre Organizações
O ID do SA OAuth é global e pode ser usado para delegação cruzada 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 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 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).
Verifique mais enumeração em:
GCP - IAM, Principals & Org Policies EnumAbusando do Gcloud
Você pode encontrar mais informações sobre o fluxo do gcloud
para fazer login em:
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:
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, a transição 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 em 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 em grupos do Google, você pode ser capaz de escalar para um grupo com algum tipo de acesso privilegiado ao GCP.
Referências
Last updated