GCP - IAM, Principals & Org Policies Enum
Comptes de Service
Pour une introduction sur ce qu'est un compte de service, consultez :
GCP - Basic InformationÉnumération
Un compte de service appartient toujours à un projet :
Utilisateurs & Groupes
Pour une introduction sur le fonctionnement des Utilisateurs & Groupes dans GCP, consultez :
GCP - Basic InformationÉnumération
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 :
IAM
Consultez ceci pour des informations de base sur IAM.
Permissions par défaut
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
etresourcemanager.organizations.get
resourcemanager.organizations.get
etresourcemanager.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.
set-iam-policy vs add-iam-policy-binding
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.
Énumération
cloudasset IAM Enumeration
Il existe différentes manières de vérifier toutes les autorisations d'un utilisateur dans différentes ressources (telles que les organisations, les dossiers, les 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
testIamPermissions enumeration
Si vous ne pouvez pas accéder aux informations IAM en utilisant les méthodes précédentes et que vous êtes dans une équipe rouge. 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é.
Privesc
Dans la page suivante, vous pouvez vérifier comment abuser des permissions IAM pour escalader les privilèges :
GCP - IAM PrivescUnauthenticated Enum
GCP - IAM, Principals & Org Unauthenticated EnumPost Exploitation
GCP - IAM Post ExploitationPersistence
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…)
…
Org Policies
Pour une introduction sur ce que sont les Org Policies, consultez :
GCP - Basic InformationLes 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.
Privesc
Dans la page suivante, vous pouvez vérifier comment abuser des permissions des politiques d'organisation pour escalader les privilèges :
GCP - Orgpolicy PrivescLast updated