Português - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

GCP - IAM Privesc

Support HackTricks

IAM

Encontre mais informações sobre IAM em:

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

Um atacante com as permissões mencionadas poderá atualizar um papel atribuído a você e lhe conceder permissões extras para outros recursos como:

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

Você 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 que pertence a uma Conta de Serviço, portanto, é possível solicitar um token de acesso de uma Conta de Serviço com mais privilégios do que os nossos.

gcloud --impersonate-service-account="${victim}@${PROJECT_ID}.iam.gserviceaccount.com" \
auth print-access-token

Você 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

Você 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.

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

iam.serviceAccounts.implicitDelegation

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

Observe que, de acordo com a documentação, a delegação do gcloud só funciona para gerar um token usando o método generateAccessToken(). Então aqui está como obter um token usando a API diretamente:

curl -X POST \
'https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/'"${TARGET_SERVICE_ACCOUNT}"':generateAccessToken' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer '"$(gcloud auth print-access-token)" \
-d '{
"delegates": ["projects/-/serviceAccounts/'"${DELEGATED_SERVICE_ACCOUNT}"'"],
"scope": ["https://www.googleapis.com/auth/cloud-platform"]
}'

Você 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.signBlob

Um atacante com as permissões mencionadas poderá assinar cargas úteis arbitrárias no GCP. Assim, será possível criar um JWT não assinado da SA e, em seguida, enviá-lo como um blob para obter o JWT assinado pela SA que estamos visando. Para mais informações leia isso.

Você 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 web JSON (JWTs) bem formados. A diferença em relação ao 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 facilita o uso, mas você só pode assinar JWT em vez de qualquer byte.

Você 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 o papel 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"

# If you still have prblem grant yourself also this permission
gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \ \
--member="user:username@domain.com" \
--role="roles/iam.serviceAccountUser"

Você 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 é como a permissão iam:PassRole da AWS. É essencial para executar tarefas, como iniciar uma instância do Compute Engine, pois concede a capacidade de "agir como" uma Conta de Serviço, garantindo uma gestão de permissões segura. Sem isso, os usuários podem obter acesso indevido. Além disso, explorar a iam.serviceAccounts.actAs envolve vários métodos, cada um exigindo um conjunto de permissões, em contraste com 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 novas e melhores permissões. 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)

  • Implantando trabalhos em serviços do GCP (mais aplicável à compromissão de uma conta de usuário)

iam.serviceAccounts.getOpenIdToken

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

De acordo com este post interessante, é necessário indicar o público (serviço onde você deseja usar o token para autenticar) e você receberá um JWT assinado pelo google indicando a conta de serviço e o público 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 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 via esse 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

Support HackTricks
PreviousGCP - Deploymentmaneger PrivescNextGCP - KMS Privesc

Last updated