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)
Para uma introdução sobre o que é uma conta de serviço, confira:
GCP - Basic InformationUma conta de serviço sempre pertence a um projeto:
Para uma introdução sobre como Usuários e Grupos funcionam no GCP, consulte:
GCP - Basic InformationCom as permissões serviceusage.services.enable e serviceusage.services.use, é possível habilitar serviços em um projeto e usá-los.
Observe que, por padrão, os usuários do Workspace recebem o papel de Criador de Projetos, dando-lhes acesso para criar novos projetos. Quando um usuário cria um projeto, ele recebe o papel de owner sobre ele. Assim, ele poderia habilitar esses serviços sobre o projeto para poder enumerar o Workspace.
No entanto, note que também é necessário ter permissões suficientes no Workspace para poder chamar essas APIs.
Se você puder habilitar o serviço admin e se seu usuário tiver privilegios suficientes no workspace, você poderia enumerar todos os grupos e usuários com as seguintes linhas.
Mesmo que diga identity groups, também retorna usuários sem nenhum grupo:
Nos exemplos anteriores, o parâmetro --labels é obrigatório, então um valor genérico é usado (não é necessário se você usar a API diretamente como PurplePanda faz aqui.
Mesmo com o serviço de administrador habilitado, é possível que você receba um erro ao enumerá-los porque seu usuário de workspace comprometido não tem permissões suficientes:
Verifique isso para informações básicas sobre IAM.
Das documentações: Quando um recurso de organização é criado, todos os usuários em seu domínio recebem os papéis de Criador de Conta de Cobrança e Criador de Projeto por padrão. Esses papéis padrão permitem que seus usuários comecem a usar o Google Cloud imediatamente, mas não são destinados ao uso na operação regular do recurso de sua organização.
Esses papéis concedem as permissões:
billing.accounts.create e resourcemanager.organizations.get
resourcemanager.organizations.get e resourcemanager.projects.create
Além disso, quando um usuário cria um projeto, ele é concedido como proprietário desse projeto automaticamente de acordo com as documentações. Portanto, por padrão, um usuário poderá criar um projeto e executar qualquer serviço nele (mineradores? enumeração de Workspace? ...)
O maior privilégio em uma Organização GCP é o papel de Administrador da Organização.
Na maioria dos serviços, você poderá alterar as permissões sobre um recurso usando o método add-iam-policy-binding ou set-iam-policy. A principal diferença é que add-iam-policy-binding adiciona uma nova vinculação de papel à política IAM existente, enquanto set-iam-policy irá deletar as permissões anteriormente concedidas e definir apenas as que estão indicadas no comando.
Existem diferentes maneiras de verificar todas as permissões de um usuário em diferentes recursos (como organizações, pastas, projetos...) usando este serviço.
A permissão cloudasset.assets.searchAllIamPolicies pode solicitar todas as políticas iam dentro de um recurso.
A permissão cloudasset.assets.analyzeIamPolicy pode solicitar todas as políticas iam de um principal dentro de um recurso.
A permissão cloudasset.assets.searchAllResources permite listar todos os recursos de uma organização, pasta ou projeto. Recursos relacionados ao IAM (como funções) incluídos.
A permissão cloudasset.assets.analyzeMove pode ser útil para também recuperar políticas que afetam um recurso como um projeto.
Eu suponho que a permissão cloudasset.assets.queryIamPolicy também poderia dar acesso para encontrar permissões de principais
Se você não consegue acessar informações do IAM usando os métodos anteriores e está em uma Red Team. Você pode usar a ferramenta https://github.com/carlospolop/bf_my_gcp_perms para forçar suas permissões atuais.
No entanto, observe que o serviço cloudresourcemanager.googleapis.com precisa estar habilitado.
Na página a seguir, você pode verificar como abusar das permissões do IAM para escalar privilégios:
GCP - IAM PrivescSe você tiver altos privilégios, você pode:
Criar novas SAs (ou usuários se estiver no Workspace)
Dar a principais controlados por você mais permissões
Dar mais privilégios a SAs vulneráveis (SSRF em vm, Cloud Function vulnerável…)
…
Para uma introdução sobre o que são Org Policies, confira:
GCP - Basic InformationAs políticas do IAM indicam as permissões que os principais têm sobre os recursos por meio de funções, que são atribuídas com permissões granulares. As políticas de organização restrigem como esses serviços podem ser usados ou quais recursos estão desativados. Isso ajuda a melhorar o menor privilégio de cada recurso no ambiente GCP.
Na página a seguir, você pode verificar como abusar das permissões de políticas organizacionais para escalar privilégios:
GCP - Orgpolicy PrivescAprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
