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 autorisations serviceusage.services.enable
et serviceusage.services.use
, il est possible d'activer des services dans un projet et de les utiliser.
Notez qu'en général, les utilisateurs de Workspace se voient accorder le rôle de Créateur de projet par défaut, ce qui leur donne accès à la création de nouveaux projets. Lorsqu'un utilisateur crée un projet, il se voit attribuer le rôle de propriétaire
. Ainsi, il pourrait activer ces services sur le projet pour pouvoir énumérer Workspace.
Cependant, il est également nécessaire d'avoir suffisamment d'autorisations 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 & utilisateurs avec les lignes suivantes.
Même si cela indique groupes d'identité
, cela renvoie é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 (il n'est pas nécessaire si vous utilisez directement l'API comme le fait PurplePanda ici.
Même avec le service admin activé, il est possible que vous rencontriez une erreur lors de l'énumération car votre utilisateur de l'espace de travail compromis n'a pas suffisamment d'autorisations :
IAM
Consultez ceci pour des informations de base sur IAM.
Autorisations 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 les rôles de Créateur de compte de facturation et de Créateur de projet par défaut. 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 la ressource de votre organisation.
Ces rôles accordent les autorisations :
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 la documentation. Par conséquent, par défaut, un utilisateur pourra créer un projet et exécuter n'importe quel service dessus (miners ? Énumération de l'espace de travail ? ...)
Le plus haut privilège dans une organisation GCP est le rôle Administrateur de l'organisation.
set-iam-policy vs add-iam-policy-binding
Dans la plupart des services, vous pourrez modifier les autorisations 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 stratégie IAM existante tandis que set-iam-policy
va supprimer les autorisations précédemment accordées et définir uniquement celles indiquées dans la commande.
Énumération
Enumération IAM cloudasset
Il existe différentes façons 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.
La permission
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 répertorier 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 être utile pour récupérer également les politiques affectant une ressource comme un projet
Je suppose que l'autorisation
cloudasset.assets.queryIamPolicy
pourrait également donner accès à la recherche des autorisations des principaux
Énumération des autorisations testIam
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 Red, vous pourriez utiliser l'outil https://github.com/carlospolop/bf_my_gcp_perms pour forcer vos autorisations actuelles.
Cependant, notez que le service cloudresourcemanager.googleapis.com
doit être activé.
Élévation de privilèges
Sur la page suivante, vous pouvez vérifier comment abuser des autorisations IAM pour escalader les privilèges:
GCP - IAM PrivescÉnumération non authentifiée
GCP - IAM, Principals & Org Unauthenticated EnumPost-exploitation
GCP - IAM Post ExploitationPersistance
Si vous avez des privilèges élevés, vous pourriez :
Créer de nouveaux SA (ou utilisateurs si dans Workspace)
Donner plus de permissions aux principaux contrôlés par vous-même
Accorder plus de privilèges aux SA vulnérables (SSRF dans vm, vuln Cloud Function…)
...
Politiques d'organisation
Pour une introduction sur ce que sont les politiques d'organisation, consultez :
GCP - Basic InformationLes politiques IAM indiquent les autorisations que les principaux ont sur les ressources via des rôles, qui sont des autorisations granulaires attribuées. 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.
Élévation de privilèges
Sur la page suivante, vous pouvez vérifier comment abuser des autorisations des politiques d'organisation pour escalader les privilèges:
GCP - Orgpolicy PrivescLast updated