Last updated
Apprenez et pratiquez le Hacking AWS :HackTricks Formation Expert Red Team AWS (ARTE) Apprenez et pratiquez le Hacking GCP : HackTricks Formation Expert Red Team GCP (GRTE)
Pour une introduction sur ce qu'est un compte de service, consultez :
Un compte de service appartient toujours à un projet :
Pour une introduction sur le fonctionnement des Utilisateurs & Groupes dans GCP, consultez :
Avec les permissions serviceusage.services.enable et serviceusage.services.use, il est possible de activer des services dans un projet et de les utiliser.
Notez qu'en règle générale, les utilisateurs de Workspace se voient attribuer le rôle Créateur de projet, leur donnant accès à créer de nouveaux projets. Lorsqu'un utilisateur crée un projet, il se voit attribuer le rôle owner sur celui-ci. Ainsi, il pourrait activer ces services sur le projet pour pouvoir énumérer Workspace.
Cependant, il est également nécessaire d'avoir suffisamment de permissions dans Workspace pour pouvoir appeler ces API.
Si vous pouvez activer le service admin et si votre utilisateur a suffisamment de privilèges dans Workspace, vous pourriez énumérer tous les groupes et utilisateurs avec les lignes suivantes.
Même s'il est indiqué identity groups, cela retourne également des utilisateurs sans aucun groupe :
Dans les exemples précédents, le paramètre --labels est requis, donc une valeur générique est utilisée (ce n'est pas requis si vous utilisez l'API directement comme PurplePanda le fait ici.
Même avec le service administrateur activé, il est possible que vous rencontriez une erreur lors de leur énumération parce que votre utilisateur de workspace compromis n'a pas suffisamment de permissions :
Consultez ceci pour des informations de base sur IAM.
D'après les docs : Lorsqu'une ressource d'organisation est créée, tous les utilisateurs de votre domaine se voient accorder par défaut les rôles Créateur de compte de facturation et Créateur de projet. Ces rôles par défaut permettent à vos utilisateurs de commencer à utiliser Google Cloud immédiatement, mais ne sont pas destinés à être utilisés dans le fonctionnement régulier de votre ressource d'organisation.
Ces rôles accordent les permissions :
billing.accounts.create et resourcemanager.organizations.get
resourcemanager.organizations.get et resourcemanager.projects.create
De plus, lorsqu'un utilisateur crée un projet, il est automatiquement accordé propriétaire de ce projet selon les docs. Par conséquent, par défaut, un utilisateur pourra créer un projet et exécuter n'importe quel service dessus (mineurs ? énumération de Workspace ? ...)
Le plus haut privilège dans une organisation GCP est le rôle Administrateur d'organisation.
Dans la plupart des services, vous pourrez modifier les permissions sur une ressource en utilisant la méthode add-iam-policy-binding ou set-iam-policy. La principale différence est que add-iam-policy-binding ajoute un nouveau lien de rôle à la politique IAM existante tandis que set-iam-policy va supprimer les permissions précédemment accordées et définir uniquement celles indiquées dans la commande.
Il existe différentes manières de vérifier toutes les autorisations d'un utilisateur dans différentes ressources (telles que des organisations, des dossiers, des projets...) en utilisant ce service.
L'autorisation cloudasset.assets.searchAllIamPolicies peut demander toutes les politiques IAM à l'intérieur d'une ressource.
La permission cloudasset.assets.analyzeIamPolicy peut demander toutes les politiques iam d'un principal à l'intérieur d'une ressource.
La permission cloudasset.assets.searchAllResources permet de lister toutes les ressources d'une organisation, d'un dossier ou d'un projet. Les ressources liées à IAM (comme les rôles) sont incluses.
La permission cloudasset.assets.analyzeMove peut également être utile pour récupérer les politiques affectant une ressource comme un projet.
Je suppose que la permission cloudasset.assets.queryIamPolicy pourrait également donner accès pour trouver les permissions des principaux.
Si vous ne pouvez pas accéder aux informations IAM en utilisant les méthodes précédentes et que vous êtes dans une Red Team. Vous pourriez utiliser l'outil https://github.com/carlospolop/bf_my_gcp_perms pour forcer vos permissions actuelles.
Cependant, notez que le service cloudresourcemanager.googleapis.com doit être activé.
Dans la page suivante, vous pouvez vérifier comment abuser des permissions IAM pour escalader les privilèges :
Si vous avez des privilèges élevés, vous pourriez :
Créer de nouveaux SAs (ou utilisateurs si dans Workspace)
Donner à des principaux contrôlés par vous plus de permissions
Donner plus de privilèges à des SAs vulnérables (SSRF dans vm, vuln Cloud Function…)
…
Pour une introduction sur ce que sont les Org Policies, consultez :
Les politiques IAM indiquent les permissions que les principaux ont sur les ressources via des rôles, qui se voient attribuer des permissions granulaires. Les politiques d'organisation restreignent la manière dont ces services peuvent être utilisés ou quelles fonctionnalités sont désactivées. Cela aide à améliorer le principe du moindre privilège de chaque ressource dans l'environnement GCP.
Dans la page suivante, vous pouvez vérifier comment abuser des autorisations des politiques d'organisation pour escalader les privilèges :
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)
