Français - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

GCP - IAM Privesc

Apprenez le piratage AWS de zéro à héros avec htARTE (Expert en équipe rouge AWS de HackTricks)!

Autres façons de soutenir HackTricks :

IAM

Trouvez plus d'informations sur IAM dans :

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

Un attaquant disposant des autorisations mentionnées pourra mettre à jour un rôle qui vous est attribué et vous accorder des autorisations supplémentaires pour d'autres ressources comme suit :

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 autorisations mentionnées pourra demander un jeton d'accès appartenant à un compte de service, il est donc possible de demander un jeton d'accès d'un compte de service avec plus de privilèges que les nôtres.

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.serviceAccountKeys.create

Un attaquant avec les autorisations 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 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.

Notez que iam.serviceAccountKeys.update ne fonctionnera pas pour modifier la clé d'un compte de service car pour cela les autorisations iam.serviceAccountKeys.create sont également nécessaires.

iam.serviceAccounts.implicitDelegation

Si vous avez la permission iam.serviceAccounts.implicitDelegation sur un compte de service qui a la permission iam.serviceAccounts.getAccessToken sur un troisième compte de service, alors vous pouvez utiliser l'implicitDelegation pour créer un jeton pour ce troisième compte de service. Voici un schéma pour aider à expliquer.

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.

Notez qu'selon la documentation, la délégation ne fonctionne que pour générer un jeton en utilisant la méthode generateAccessToken().

iam.serviceAccounts.signBlob

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

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

iam.serviceAccounts.signJwt

Un attaquant avec les autorisations mentionnées pourra signer des jetons web JSON (JWT) bien formés. La différence avec la méthode précédente est que au lieu de faire signer à Google un blob contenant un JWT, 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, 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.setIamPolicy

Un attaquant avec les autorisations mentionnées pourra ajouter des politiques IAM aux comptes de service. Vous pouvez l'exploiter pour vous accorder les autorisations dont vous avez besoin pour usurper le compte de service. Dans l'exemple suivant, nous nous accordons le rôle roles/iam.serviceAccountTokenCreator sur le compte de service 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"

Vous pouvez trouver un script pour automatiser la création, l'exploitation et le 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'initialisation d'une instance Compute Engine, car elle accorde la capacité d'agir en tant que compte de service, assurant une gestion sécurisée des autorisations. Sans cela, les utilisateurs pourraient obtenir un accès indu. De plus, l'exploitation de iam.serviceAccounts.actAs implique diverses méthodes, chacune nécessitant un ensemble d'autorisations, contrairement à d'autres méthodes qui n'en nécessitent qu'une seule.

Impersonation de compte de service

L'impersonation d'un compte de service peut être très utile pour obtenir de nouveaux et meilleurs privilèges. Il existe trois façons d'impersonner un autre compte de service:

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

  • Autorisation en utilisant des politiques Cloud IAM (mentionné ici)

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

iam.serviceAccounts.getOpenIdToken

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

Selon ce post intéressant, il est nécessaire d'indiquer l'audience (service où vous souhaitez utiliser le jeton 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

Certains services qui prennent en charge l'authentification via ce type de jetons sont :

Vous pouvez trouver un exemple sur la façon de créer un jeton OpenID au nom d'un compte de service ici.

Références

Apprenez le piratage AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres façons de soutenir HackTricks :

PrécédentGCP - Deploymentmaneger PrivescSuivantGCP - KMS Privesc

Dernière mise à jour