GCP - IAM Privesc

Aprenda hacking AWS do zero ao avançado com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks:

IAM

Encontre mais informações sobre IAM em:

pageGCP - IAM, Principals & Org Policies Enum

iam.roles.update (iam.roles.get)

Um atacante com as permissões mencionadas poderá atualizar uma função atribuída a você e conceder permissões extras para outros recursos como:

gcloud iam roles update <rol name> --project <project> --add-permissions <permission>

Pode encontrar um script para automatizar a criação, exploração e limpeza de um ambiente vulnerável aqui e um script em Python para abusar desse privilégio aqui. Para mais informações, consulte a pesquisa original.

iam.serviceAccounts.getAccessToken (iam.serviceAccounts.get)

Um atacante com as permissões mencionadas poderá solicitar um token de acesso pertencente a uma Conta de Serviço, sendo possível solicitar um token de acesso de uma Conta de Serviço com mais privilégios do que os nossos.

Pode encontrar um script para automatizar a criação, exploração e limpeza de um ambiente vulnerável aqui e um script em Python para abusar desse privilégio aqui. Para mais informações, consulte a pesquisa original.

iam.serviceAccountKeys.create

Um atacante com as permissões mencionadas poderá criar uma chave gerenciada pelo usuário para uma Conta de Serviço, o que nos permitirá acessar o GCP como essa Conta de Serviço.

gcloud iam service-accounts keys create --iam-account <name> /tmp/key.json

gcloud auth activate-service-account --key-file=sa_cred.json

Pode encontrar um script para automatizar a criação, exploração e limpeza de um ambiente vulnerável aqui e um script em python para abusar desse privilégio aqui. Para mais informações, consulte a pesquisa original.

Note que iam.serviceAccountKeys.update não funcionará para modificar a chave de um SA porque para fazer isso as permissões iam.serviceAccountKeys.create também são necessárias.

iam.serviceAccounts.implicitDelegation

Se tiver a permissão iam.serviceAccounts.implicitDelegation em uma Conta de Serviço que tenha a permissão iam.serviceAccounts.getAccessToken em uma terceira Conta de Serviço, então pode usar a delegação implícita para criar um token para essa terceira Conta de Serviço. Aqui está um diagrama para ajudar a explicar.

Pode encontrar um script para automatizar a criação, exploração e limpeza de um ambiente vulnerável aqui e um script em python para abusar desse privilégio aqui. Para mais informações, consulte a pesquisa original.

Note que, de acordo com a documentação, a delegação só funciona para gerar um token usando o método generateAccessToken().

iam.serviceAccounts.signBlob

Um atacante com as permissões mencionadas poderá assinar payloads arbitrários no GCP. Assim, será possível criar um JWT não assinado do SA e depois enviá-lo como um blob para obter o JWT assinado pelo SA que estamos visando. Para mais informações leia isso.

Pode encontrar um script para automatizar a criação, exploração e limpeza de um ambiente vulnerável aqui e um script em python para abusar desse privilégio aqui e aqui. Para mais informações, consulte a pesquisa original.

iam.serviceAccounts.signJwt

Um atacante com as permissões mencionadas poderá assinar tokens JSON web (JWTs) bem formados. A diferença com o método anterior é que em vez de fazer o Google assinar um blob contendo um JWT, usamos o método signJWT que já espera um JWT. Isso torna mais fácil de usar, mas você só pode assinar JWT em vez de qualquer byte.

Pode encontrar um script para automatizar a criação, exploração e limpeza de um ambiente vulnerável aqui e um script em python para abusar desse privilégio aqui. Para mais informações, consulte a pesquisa original.

iam.serviceAccounts.setIamPolicy

Um atacante com as permissões mencionadas poderá adicionar políticas IAM a contas de serviço. Você pode abusar disso para conceder a si mesmo as permissões necessárias para se passar pela conta de serviço. No exemplo a seguir, estamos nos concedendo a função roles/iam.serviceAccountTokenCreator sobre a SA interessante:

gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \
--member="user:username@domain.com" \
--role="roles/iam.serviceAccountTokenCreator"

Pode encontrar um script para automatizar a criação, exploração e limpeza de um ambiente vulnerável aqui.

iam.serviceAccounts.actAs

A permissão iam.serviceAccounts.actAs é semelhante à permissão iam:PassRole da AWS. É essencial para executar tarefas, como iniciar uma instância do Compute Engine, pois concede a capacidade de "atuar como" uma Conta de Serviço, garantindo uma gestão segura de permissões. Sem isso, os usuários podem obter acesso indevido. Além disso, explorar o iam.serviceAccounts.actAs envolve vários métodos, cada um exigindo um conjunto de permissões, ao contrário de outros métodos que precisam apenas de uma.

Impersonação de conta de serviço

Impersonar uma conta de serviço pode ser muito útil para obter novos e melhores privilégios. Existem três maneiras de impersonar outra conta de serviço:

  • Autenticação usando chaves privadas RSA (coberto acima)

  • Autorização usando políticas do Cloud IAM (coberto aqui)

  • Implantar trabalhos em serviços do GCP (mais aplicável à comprometimento de uma conta de usuário)

iam.serviceAccounts.getOpenIdToken

Um atacante com as permissões mencionadas poderá gerar um JWT OpenID. Estes são usados para afirmar identidade e não necessariamente carregam qualquer autorização implícita contra um recurso.

De acordo com este post interessante, é necessário indicar a audiência (serviço onde deseja usar o token para autenticar) e você receberá um JWT assinado pelo Google indicando a conta de serviço e a audiência do JWT.

Você pode gerar um OpenIDToken (se tiver acesso) com:

# First activate the SA with iam.serviceAccounts.getOpenIdToken over the other SA
gcloud auth activate-service-account --key-file=/path/to/svc_account.json
# Then, generate token
gcloud auth print-identity-token "${ATTACK_SA}@${PROJECT_ID}.iam.gserviceaccount.com" --audiences=https://example.com

Então você pode simplesmente usá-lo para acessar o serviço com:

curl -v -H "Authorization: Bearer id_token" https://some-cloud-run-uc.a.run.app

Alguns serviços que suportam autenticação por meio desse tipo de tokens são:

Você pode encontrar um exemplo de como criar um token OpenID em nome de uma conta de serviço aqui.

Referências

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

Outras formas de apoiar o HackTricks:

Última actualización