GCP - IAM Privesc
Tip
Aprenda e pratique AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Aprenda e pratique Az Hacking:HackTricks Training Azure Red Team Expert (AzRTE)
Apoie o HackTricks
- Check the subscription plans!
- Participe do 💬 Discord group ou do telegram group ou siga-nos no Twitter 🐦 @hacktricks_live.
- Compartilhe hacking tricks enviando PRs para os HackTricks e HackTricks Cloud github repos.
IAM
Encontre mais informações sobre o IAM em:
GCP - IAM, Principals & Org Policies Enum
iam.roles.update (iam.roles.get)
Um atacante com as permissões mencionadas poderá atualizar uma role atribuída a você e conceder permissões adicionais 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, exploit e limpeza de um vuln environment aqui e um script python para abusar desse privilégio aqui. Para mais informações, consulte a pesquisa original.
gcloud iam roles update <Rol_NAME> --project <PROJECT_ID> --add-permissions <Permission>
iam.roles.create & iam.serviceAccounts.setIamPolicy
A permissão iam.roles.create permite a criação de funções personalizadas em um projeto/organização. Nas mãos de um atacante, isso é perigoso porque permite a definição de novos conjuntos de permissões que podem, posteriormente, ser atribuídos a entidades (por exemplo, usando a permissão iam.serviceAccounts.setIamPolicy) com o objetivo de escalar privilégios.
gcloud iam roles create <ROLE_ID> \
--project=<PROJECT_ID> \
--title="<Title>" \
--description="<Description>" \
--permissions="permission1,permission2,permission3"
iam.serviceAccounts.getAccessToken (iam.serviceAccounts.get)
Um atacante com as permissões mencionadas poderá solicitar um access token que pertence a uma Service Account, portanto é possível solicitar um access token de uma Service Account com mais privilégios do que os nossos.
Para uma variante resource-driven em que código controlado pelo atacante rouba um managed Vertex AI Agent Engine runtime token do metadata service e o reutiliza como o Vertex AI service agent, consulte:
GCP - Vertex AI Post Exploitation
gcloud --impersonate-service-account="${victim}@${PROJECT_ID}.iam.gserviceaccount.com" \
auth print-access-token
Você pode encontrar um script para automatizar a creation, exploit and cleaning of a vuln environment here e um script em python para abusar desse privilégio here. Para mais informações confira a original research.
iam.serviceAccountKeys.create
Um atacante com as permissões mencionadas poderá criar uma chave gerenciada pelo usuário para um Service Account, o que nos permitirá acessar o GCP como esse Service Account.
gcloud iam service-accounts keys create --iam-account <name> /tmp/key.json
gcloud auth activate-service-account --key-file=sa_cred.json
You can find a script to automate the creation, exploit and cleaning of a vuln environment here and a python script to abuse this privilege here. For more information check the original research.
Observe que iam.serviceAccountKeys.update não funcionará para modificar a chave de uma SA porque, para isso, também é necessária a permissão iam.serviceAccountKeys.create.
iam.serviceAccounts.implicitDelegation
Se você tiver a permissão iam.serviceAccounts.implicitDelegation em um Service Account que tenha a permissão iam.serviceAccounts.getAccessToken em um terceiro Service Account, então você pode usar implicitDelegation para criar um token para esse terceiro Service Account. Aqui está um diagrama para ajudar a explicar.

Observe que, de acordo com a documentation, a delegação do gcloud funciona apenas 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 o creation, exploit and cleaning of a vuln environment here e um script em python para abusar deste privilégio here. Para mais informações confira a original research.
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 da SA e então enviá-lo como um blob para que o JWT seja assinado pela SA que estamos visando. Para mais informações read this.
Você pode encontrar um script para automatizar o creation, exploit and cleaning of a vuln environment here e um script em python para abusar deste privilégio here e here. Para mais informações confira a original research.
iam.serviceAccounts.signJwt
Um atacante com as permissões mencionadas poderá assinar JSON web tokens (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 quaisquer bytes.
Você pode encontrar um script para automatizar o creation, exploit and cleaning of a vuln environment here e um script em python para abusar deste privilégio here. Para mais informações confira a original research.
iam.serviceAccounts.setIamPolicy
Um atacante com as permissões mencionadas poderá adicionar políticas IAM a service accounts. Você pode abusar disso para conceder a si mesmo as permissões necessárias para impersonar a service account. No exemplo a seguir estamos nos concedendo o papel roles/iam.serviceAccountTokenCreator sobre a SA de interesse:
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 creation, exploit and cleaning of a vuln environment here.
iam.serviceAccounts.actAs
A iam.serviceAccounts.actAs permission é como a iam:PassRole permission from AWS. É essencial para executar tarefas, como iniciar uma instância do Compute Engine, pois concede a capacidade de “actAs” uma conta de serviço, garantindo o gerenciamento seguro de permissões. Sem isso, 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 exigem apenas uma.
Impersonação de conta de serviço
Impersonar uma conta de serviço pode ser muito útil para obter privilégios novos e melhores. Existem três formas pelas quais você pode impersonate another service account:
- Autenticação usando chaves privadas RSA (abordado acima)
- Autorização usando Cloud IAM policies (abordado aqui)
- Deploying jobs on GCP services (mais aplicável ao comprometimento de uma conta de usuário)
iam.serviceAccounts.getOpenIdToken
Um atacante com as permissões mencionadas poderá gerar um OpenID JWT. Eles são usados para afirmar identidade e não carregam necessariamente qualquer autorização implícita contra um recurso.
De acordo com este interesting post, é necessário indicar a audience (o serviço onde você quer usar o token para autenticação) e você receberá um JWT assinado pelo google indicando a conta de serviço e a audience 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 via esse tipo de token são:
- Google Cloud Run
- Google Cloud Functions
- Google Identity Aware Proxy
- Google Cloud Endpoints (if using Google OIDC)
You can find an example on how to create and OpenID token behalf a service account here.
Referências
Tip
Aprenda e pratique AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Aprenda e pratique Az Hacking:HackTricks Training Azure Red Team Expert (AzRTE)
Apoie o HackTricks
- Check the subscription plans!
- Participe do 💬 Discord group ou do telegram group ou siga-nos no Twitter 🐦 @hacktricks_live.
- Compartilhe hacking tricks enviando PRs para os HackTricks e HackTricks Cloud github repos.
HackTricks Cloud

