GCP <--> Workspace Pivoting
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
La délégation à l'échelle du domaine de Google Workspace permet à un objet d'identité, soit une application externe du Google Workspace Marketplace, soit un compte de service GCP interne, d'accéder aux données de l'ensemble de Workspace au nom des utilisateurs.
Cela signifie essentiellement que les comptes de service à l'intérieur des projets GCP d'une organisation pourraient être capables d'usurper l'identité des utilisateurs de Workspace de la même organisation (ou même d'une organisation différente).
Pour plus d'informations sur le fonctionnement exact de cela, consultez :
GCP - Understanding Domain-Wide DelegationSi un attaquant a compromis un accès sur GCP et connaît un email d'utilisateur Workspace valide (de préférence super admin) de l'entreprise, il pourrait énumérer tous les projets auxquels il a accès, énumérer tous les comptes de service des projets, vérifier à quels comptes de service il a accès, et répéter toutes ces étapes avec chaque compte de service qu'il peut usurper. Avec une liste de tous les comptes de service auxquels il a accès et la liste des emails Workspace, l'attaquant pourrait essayer d'usurper l'identité de l'utilisateur avec chaque compte de service.
Notez que lors de la configuration de la délégation à l'échelle du domaine, aucun utilisateur Workspace n'est nécessaire, donc il suffit de connaître un valide pour l'usurpation. Cependant, les privilèges de l'utilisateur usurpé seront utilisés, donc s'il s'agit d'un Super Admin, vous pourrez accéder à tout. S'il n'a aucun accès, cela sera inutile.
Ce script simple va générer un jeton OAuth en tant qu'utilisateur délégué que vous pouvez ensuite utiliser pour accéder à d'autres API Google avec ou sans gcloud:
Ceci est un outil qui peut effectuer l'attaque en suivant ces étapes :
Énumérer les projets GCP en utilisant l'API Resource Manager.
Itérer sur chaque ressource de projet, et énumérer les ressources de compte de service GCP auxquelles l'utilisateur IAM initial a accès en utilisant GetIAMPolicy.
Itérer sur chaque rôle de compte de service, et trouver les rôles intégrés, de base et personnalisés avec la permission serviceAccountKeys.create sur la ressource de compte de service cible. Il convient de noter que le rôle d'éditeur possède intrinsèquement cette permission.
Créer une nouvelle clé privée KEY_ALG_RSA_2048 pour chaque ressource de compte de service qui est trouvée avec la permission pertinente dans la politique IAM.
Itérer sur chaque nouveau compte de service et créer un objet JWT pour celui-ci qui est composé des informations d'identification de la clé privée SA et d'un champ OAuth. Le processus de création d'un nouvel objet JWT itérera sur toutes les combinaisons existantes de champs OAuth de la liste oauth_scopes.txt, afin de trouver toutes les possibilités de délégation. La liste oauth_scopes.txt est mise à jour avec tous les champs OAuth que nous avons trouvés pertinents pour abuser des identités Workspace.
La méthode _make_authorization_grant_assertion révèle la nécessité de déclarer un utilisateur de workspace cible, appelé subject, pour générer des JWT sous DWD. Bien que cela puisse sembler nécessiter un utilisateur spécifique, il est important de réaliser que DWD influence chaque identité au sein d'un domaine. Par conséquent, créer un JWT pour n'importe quel utilisateur de domaine affecte toutes les identités dans ce domaine, conformément à notre vérification d'énumération de combinaison. En d'autres termes, un utilisateur Workspace valide est suffisant pour avancer.
Cet utilisateur peut être défini dans le fichier config.yaml de DeleFriend. Si un utilisateur de workspace cible n'est pas déjà connu, l'outil facilite l'identification automatique des utilisateurs de workspace valides en scannant les utilisateurs de domaine avec des rôles sur les projets GCP. Il est essentiel de noter (encore une fois) que les JWT sont spécifiques au domaine et ne sont pas générés pour chaque utilisateur ; par conséquent, le processus automatique cible une seule identité unique par domaine.
Énumérer et créer un nouveau jeton d'accès porteur pour chaque JWT et valider le jeton contre l'API tokeninfo.
Gitlab a créé ce script Python qui peut faire deux choses - lister le répertoire des utilisateurs et créer un nouveau compte administratif tout en indiquant un json avec les informations d'identification SA et l'utilisateur à usurper. Voici comment vous l'utiliseriez :
Il est possible de vérifier les délégations à l'échelle du domaine dans https://admin.google.com/u/1/ac/owl/domainwidedelegation.
Un attaquant ayant la capacité de créer des comptes de service dans un projet GCP et des privilèges de super administrateur sur GWS pourrait créer une nouvelle délégation permettant aux SAs d'usurper l'identité de certains utilisateurs de GWS :
Génération d'un nouveau compte de service et d'une paire de clés correspondante : Sur GCP, de nouvelles ressources de compte de service peuvent être produites soit de manière interactive via la console, soit de manière programmatique en utilisant des appels API directs et des outils CLI. Cela nécessite le rôle iam.serviceAccountAdmin ou tout rôle personnalisé équipé de la permission iam.serviceAccounts.create. Une fois le compte de service créé, nous procéderons à la génération d'une paire de clés associée (permission iam.serviceAccountKeys.create).
Création d'une nouvelle délégation : Il est important de comprendre que seul le rôle de Super Administrateur possède la capacité de configurer une délégation à l'échelle du domaine dans Google Workspace et que la délégation à l'échelle du domaine ne peut pas être configurée de manière programmatique. Elle ne peut être créée et ajustée manuellement via la console de Google Workspace.
La création de la règle peut être trouvée sous la page Contrôles API → Gérer la délégation à l'échelle du domaine dans la console d'administration Google Workspace.
Attacher les privilèges des portées OAuth : Lors de la configuration d'une nouvelle délégation, Google exige seulement 2 paramètres, l'ID client, qui est l'ID OAuth du compte de service GCP, et les portées OAuth qui définissent quels appels API la délégation nécessite.
La liste complète des portées OAuth peut être trouvée ici, mais voici une recommandation : https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/admin.directory.group, https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.domain, https://mail.google.com/, https://www.googleapis.com/auth/drive, openid
Agir au nom de l'identité cible : À ce stade, nous avons un objet délégué fonctionnel dans GWS. Maintenant, en utilisant la clé privée du compte de service GCP, nous pouvons effectuer des appels API (dans la portée définie dans le paramètre de portée OAuth) pour le déclencher et agir au nom de toute identité existant dans Google Workspace. Comme nous l'avons appris, le compte de service générera des jetons d'accès selon ses besoins et en fonction des permissions qu'il a pour les applications REST API.
Consultez la section précédente pour quelques outils afin d'utiliser cette délégation.
L'ID SA OAuth est global et peut être utilisé pour la délégation inter-organisationnelle. Aucune restriction n'a été mise en place pour empêcher la délégation inter-groupe. En termes simples, les comptes de service de différentes organisations GCP peuvent être utilisés pour configurer une délégation à l'échelle du domaine sur d'autres organisations Workspace. Cela signifierait qu'il suffit d'un accès de Super Administrateur à Workspace, et non d'un accès au même compte GCP, car l'adversaire peut créer des comptes de service et des clés privées sur son compte GCP personnel.
Par défaut, les utilisateurs de Workspace ont la permission de créer de nouveaux projets, et lorsqu'un nouveau projet est créé, le créateur obtient le rôle de Propriétaire sur celui-ci.
Par conséquent, un utilisateur peut créer un projet, activer les API pour énumérer Workspace dans son nouveau projet et essayer de l'énumérer.
Pour qu'un utilisateur puisse énumérer Workspace, il a également besoin de suffisamment de permissions Workspace (tous les utilisateurs ne pourront pas énumérer le répertoire).
Vérifiez plus d'énumération dans :
GCP - IAM, Principals & Org Policies EnumVous pouvez trouver plus d'informations sur le flux gcloud pour se connecter dans :
Comme expliqué là-bas, gcloud peut demander la portée https://www.googleapis.com/auth/drive qui permettrait à un utilisateur d'accéder au drive de l'utilisateur.
En tant qu'attaquant, si vous avez compromis physiquement l'ordinateur d'un utilisateur et que l'utilisateur est toujours connecté avec son compte, vous pourriez vous connecter en générant un jeton avec accès au drive en utilisant :
Si un attaquant compromet l'ordinateur d'un utilisateur, il pourrait également modifier le fichier google-cloud-sdk/lib/googlecloudsdk/core/config.py et ajouter dans le CLOUDSDK_SCOPES la portée 'https://www.googleapis.com/auth/drive' :
Par conséquent, la prochaine fois que l'utilisateur se connecte, il créera un jeton avec accès à drive que l'attaquant pourrait abuser pour accéder au drive. Évidemment, le navigateur indiquera que le jeton généré aura accès à drive, mais comme l'utilisateur se connectera lui-même avec gcloud auth login, il ne soupçonnera probablement rien.
Pour lister les fichiers drive : curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"
Si un attaquant a un accès complet à GWS, il pourra accéder à des groupes avec un accès privilégié à GCP ou même à des utilisateurs, donc passer de GWS à GCP est généralement plus "simple" simplement parce que les utilisateurs dans GWS ont des privilèges élevés sur GCP.
Par défaut, les utilisateurs peuvent rejoindre librement les groupes Workspace de l'Organisation et ces groupes peuvent avoir des autorisations GCP assignées (vérifiez vos groupes sur https://groups.google.com/).
En abusant de la privesc des groupes google, vous pourriez être en mesure d'escalader vers un groupe avec un certain type d'accès privilégié à GCP.
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)
