GCP - IAM Privesc
IAM
Trouvez plus d'informations sur IAM dans :
GCP - IAM, Principals & Org Policies Enumiam.roles.update
(iam.roles.get
)
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 :
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
)
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.
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
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.
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
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.
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Frhinosecuritylabs.com%2Fwp-content%2Fuploads%2F2020%2F04%2Fimage2-500x493.png&width=768&dpr=4&quality=100&sign=eb0da8c5&sv=1)
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 :
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
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
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
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 :
Vous pouvez trouver un script pour automatiser la création, exploitation et nettoyage d'un environnement vulnérable ici.
iam.serviceAccounts.actAs
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
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 :
Ensuite, vous pouvez simplement l'utiliser pour accéder au service avec :
Certain services qui supportent l'authentification via ce type de tokens sont :
Google Cloud Endpoints (si vous utilisez Google OIDC)
Vous pouvez trouver un exemple sur comment créer un token OpenID au nom d'un compte de service ici.
Références
Last updated