Français - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

GCP - IAM Privesc

Soutenez HackTricks

IAM

Trouvez plus d'informations sur IAM dans :

GCP - IAM, Principals & Org Policies Enum

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

Un attaquant avec les permissions mentionnées pourra mettre à jour un rôle qui vous est attribué et vous donner des permissions supplémentaires à d'autres ressources comme :

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 ici. Pour plus d'informations, consultez la recherche originale.

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

Un attaquant avec les permissions mentionnées pourra demander un jeton d'accès appartenant à un Service Account, il est donc possible de demander un jeton d'accès d'un Service Account avec plus de privilèges que le nôtre.

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

Vous pouvez trouver un script pour automatiser la création, exploitation et nettoyage d'un environnement vulnérable ici et un script python pour abuser de ce privilège ici. Pour plus d'informations, consultez la recherche originale.

iam.serviceAccountKeys.create

Un attaquant avec les 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 création, exploitation et nettoyage d'un environnement vulnérable ici et un script python pour abuser de ce privilège ici. Pour plus d'informations, consultez la recherche originale.

Notez que iam.serviceAccountKeys.update ne fonctionnera pas pour modifier la clé d'un SA car pour cela, les permissions iam.serviceAccountKeys.create sont également nécessaires.

iam.serviceAccounts.implicitDelegation

Si vous avez la permission iam.serviceAccounts.implicitDelegation sur un Service Account qui a la permission iam.serviceAccounts.getAccessToken sur un troisième Service Account, alors vous pouvez utiliser implicitDelegation pour créer un jeton 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 jeton en utilisant la méthode generateAccessToken(). Voici donc comment obtenir un jeton en utilisant directement l'API :

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 création, exploitation et nettoyage d'un environnement vulnérable ici et un script python pour abuser de ce privilège ici. Pour plus d'informations, consultez la recherche originale.

iam.serviceAccounts.signBlob

Un attaquant avec les permissions mentionnées pourra signer des charges utiles arbitraires dans GCP. Il sera donc possible de créer un JWT non signé du SA puis l'envoyer en tant que blob pour obtenir le JWT signé par le SA que nous ciblons. Pour plus d'informations lisez ceci.

Vous pouvez trouver un script pour automatiser la création, exploitation et nettoyage d'un environnement vulnérable ici et un script python pour abuser de ce privilège ici et ici. Pour plus d'informations, consultez la recherche originale.

iam.serviceAccounts.signJwt

Un attaquant avec les 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 un blob contenant un JWT par Google, nous utilisons la méthode signJWT qui attend déjà un JWT. Cela le rend plus facile à utiliser mais vous ne pouvez signer que des JWT au lieu de n'importe quels octets.

Vous pouvez trouver un script pour automatiser la création, exploitation et nettoyage d'un environnement vulnérable ici et un script python pour abuser de ce privilège ici. Pour plus d'informations, consultez la recherche originale.

iam.serviceAccounts.setIamPolicy

Un attaquant avec les permissions mentionnées pourra ajouter des politiques IAM aux comptes de service. Vous pouvez en abuser pour vous accorder les permissions nécessaires pour usurper 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 permission iam.serviceAccounts.actAs est similaire à la permission iam:PassRole d'AWS. Elle est essentielle pour exécuter des tâches, comme l'initiation d'une instance Compute Engine, car elle accorde la capacité de "actAs" un compte de service, assurant une gestion sécurisée des permissions. Sans cela, les utilisateurs pourraient obtenir un accès indu. De plus, exploiter la permission 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.

Usurpation de compte de service

Usurper un compte de service peut être très utile pour obtenir de nouveaux et meilleurs privilèges. Il existe trois façons de usurper un autre compte de service :

  • Authentification en utilisant des clés privées RSA (couvert ci-dessus)

  • Autorisation en utilisant des politiques Cloud IAM (couvert ici)

  • Déploiement de tâches sur les services GCP (plus applicable au compromis d'un compte utilisateur)

iam.serviceAccounts.getOpenIdToken

Un attaquant avec les permissions mentionnées pourra générer un JWT OpenID. Ceux-ci sont utilisés pour affirmer l'identité et ne portent pas nécessairement d'autorisation implicite contre une ressource.

Selon ce post intéressant, il est nécessaire d'indiquer l'audience (service où vous souhaitez utiliser le token pour vous authentifier) et vous recevrez un JWT signé par google indiquant le compte de service 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

Certain services qui supportent l'authentification via ce type de tokens sont :

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

Références

Soutenez HackTricks
PreviousGCP - Deploymentmaneger PrivescNextGCP - KMS Privesc

Last updated