Last updated
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Este post é a introdução de https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover que pode ser acessado para mais detalhes.
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. Este recurso, que é crucial para aplicativos que interagem com APIs ou serviços do Google que precisam de impersonação de usuário, aumenta a eficiência e minimiza erros humanos ao automatizar tarefas. Usando OAuth 2.0, desenvolvedores de aplicativos e administradores podem conceder a essas contas de serviço acesso aos dados do usuário sem o consentimento individual do usuário. O Google Workspace permite a criação de dois tipos principais de identidades de objeto delegadas globais:
Aplicativos GWS: Aplicativos do Marketplace do Workspace podem ser configurados como uma identidade delegada. Antes de serem disponibilizados no marketplace, cada aplicativo do Workspace passa por uma revisão pelo Google para minimizar o uso indevido potencial. Embora isso não elimine completamente o risco de abuso, aumenta significativamente a dificuldade para que tais incidentes ocorram.
Conta de Serviço GCP: Saiba mais sobre Contas de Serviço GCP aqui.
É assim que uma Conta de Serviço GCP pode acessar APIs do Google em nome de outras identidades no Google Workspace:
A identidade cria um JWT: A identidade usa a chave privada da conta de serviço (parte do arquivo de par de chaves JSON) para assinar um JWT. Este JWT contém declarações sobre a conta de serviço, o usuário-alvo a ser impersonado e os escopos OAuth de acesso à API REST que está sendo solicitada.
A identidade usa o JWT para solicitar um token de acesso: O aplicativo/usuário usa o JWT para solicitar um token de acesso do serviço OAuth 2.0 do Google. A solicitação também inclui o usuário-alvo a ser impersonado (o e-mail do Workspace do usuário) e os escopos para os quais o acesso é solicitado.
O serviço OAuth 2.0 do Google retorna um token de acesso: O token de acesso representa a autoridade da conta de serviço para agir em nome do usuário para os escopos especificados. Este token é tipicamente de curta duração e deve ser renovado periodicamente (de acordo com a necessidade do aplicativo). É essencial entender que os escopos OAuth especificados no token JWT têm validade e impacto no token de acesso resultante. Por exemplo, tokens de acesso que possuem múltiplos escopos terão validade para vários aplicativos de API REST.
A identidade usa o token de acesso para chamar APIs do Google: Agora, com um token de acesso relevante, o serviço pode acessar a API REST necessária. O aplicativo usa este token de acesso no cabeçalho "Authorization" de suas solicitações HTTP destinadas às APIs do Google. Essas APIs utilizam o token para verificar a identidade impersonada e confirmar que ela possui a autorização necessária.
As APIs do Google retornam os dados solicitados: Se o token de acesso for válido e a conta de serviço tiver a autorização apropriada, as APIs do Google retornam os dados solicitados. Por exemplo, na imagem a seguir, utilizamos o método users.messages.list para listar todos os IDs de mensagens do Gmail associados a um usuário-alvo do Workspace.
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
