L'escalade de privilèges dans GCP est un problème de permissions : une seule permission dangereuse transforme un membre limité en propriétaire du projet ou de l'organisation. Le catalogue ci-dessous s'appuie sur la liste de méthodes de Rhino Security Labs et sur le projet GCP-IAM-Privilege-Escalation, regroupé selon la primitive que chaque chemin exploite.
Les chemins#
- setIamPolicy : vous accorder n'importe quel rôle sur une ressource, un projet, un dossier ou une organisation que vous pouvez administrer.
- Mise à jour de rôle personnalisé : ajouter des permissions à un rôle personnalisé que vous détenez déjà avec
iam.roles.update. - Org policy : assouplir les contraintes de l'organization policy avec
orgpolicy.policy.setpour débloquer d'autres escalades. - Script de démarrage via métadonnées : exécuter du code sur une instance existante en écrivant
compute.instances.setMetadataou une clé SSH. - Déploiement actAs :
iam.serviceAccounts.actAsplus un verbe de création de ressource pour déployer du code qui s'exécute sous l'identité d'un compte de service privilégié.
Choisir un chemin#
Le chemin le plus direct est setIamPolicy si vous le détenez : il accorde Owner en un seul appel. Lorsque vous ne détenez que actAs plus une permission de déploiement, choisissez la ressource la moins coûteuse à créer (une fonction ou un Cloud Build est plus rapide et plus discret qu'une VM). Les primitives d'usurpation de compte de service (getAccessToken, création de clé) se trouvent sous usurpation de compte de service et s'enchaînent souvent après l'un de ces chemins.