GCP <--> Workspace Pivoting
Apprenez et pratiquez le piratage AWS :Formation HackTricks AWS Red Team Expert (ARTE)
Apprenez et pratiquez le piratage GCP :
Formation HackTricks GCP Red Team Expert (GRTE)
De GCP à GWS
Principes de la délégation à l'échelle du domaine
La délégation à l'échelle du domaine de Google Workspace permet à un objet d'identité, qu'il s'agisse d'une application externe du Google Workspace Marketplace ou d'un compte de service GCP interne, d'accéder aux données à travers le Workspace au nom des utilisateurs.
Cela signifie essentiellement que les comptes de service à l'intérieur des projets GCP d'une organisation pourraient être en mesure d'usurper les utilisateurs de Workspace de la même organisation (ou même d'une autre).
Pour plus d'informations sur le fonctionnement exact, consultez :
GCP - Understanding Domain-Wide DelegationCompromettre une délégation existante
Si un attaquant a compromis un certain accès sur GCP et connaît un e-mail d'utilisateur Workspace valide (de préférence super administrateur) 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 e-mails de Workspace, l'attaquant pourrait essayer d'usurper 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, il suffit donc de connaître un seul valide, ce qui est suffisant et nécessaire pour l'usurpation. Cependant, les privilèges de l'utilisateur usurpé seront utilisés, donc s'il s'agit d'un super administrateur, vous pourrez tout accéder. Si celui-ci n'a aucun accès, cela sera inutile.
Ce script simple permettra de générer un jeton OAuth en tant qu'utilisateur délégué que vous pourrez ensuite utiliser pour accéder à d'autres API Google avec ou sans gcloud
:
C'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 l'autorisation serviceAccountKeys.create sur la ressource de compte de service cible. Il convient de noter que le rôle d'Éditeur possède naturellement cette autorisation.
Créer une nouvelle clé privée
KEY_ALG_RSA_2048
pour chaque ressource de compte de service qui est trouvée avec l'autorisation pertinente dans la stratégie 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'une portée OAuth. Le processus de création d'un nouvel objet JWT va itérer sur toutes les combinaisons existantes de portées 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 toutes les portées OAuth que nous avons trouvées pertinentes pour abuser des identités Workspace.La méthode
_make_authorization_grant_assertion
révèle la nécessité de déclarer un utilisateur Workspace cible, appelé sujet, 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, la création d'un JWT pour n'importe quel utilisateur de domaine affecte toutes les identités de ce domaine, conforme à notre vérification d'énumération des combinaisons. En d'autres termes, un seul utilisateur Workspace valide est suffisant pour avancer. Cet utilisateur peut être défini dans le fichier config.yaml de DeleFriend. Si un utilisateur Workspace cible n'est pas déjà connu, l'outil facilite l'identification automatique des utilisateurs Workspace valides en scannant les utilisateurs de domaine avec des rôles sur les projets GCP. Il est important 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 identité unique par domaine.Énumérer et créer un nouveau jeton d'accès de 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 utilisateur 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 :
Créer une nouvelle délégation (Persistance)
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 le privilège de super administrateur pour GWS pourrait créer une nouvelle délégation permettant aux comptes de service d'usurper certains utilisateurs de GWS:
Génération d'un nouveau compte de service et de la paire de clés correspondante: Sur GCP, de nouveaux comptes de service peuvent être créés de manière interactive via la console ou 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 l'autorisationiam.serviceAccounts.create
. Une fois le compte de service créé, nous procéderons à la génération d'une paire de clés associée (autorisationiam.serviceAccountKeys.create
).Création d'une nouvelle délégation: Il est important de comprendre que seul le rôle de Super Admin possède la capacité de configurer une délégation globale à l'échelle du domaine dans Google Workspace et 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 que 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 de Google Workspace.
Attribution du privilège des étendues OAuth: Lors de la configuration d'une nouvelle délégation, Google ne requiert que 2 paramètres, l'ID Client, qui est l'ID OAuth du compte de service GCP, et les étendues OAuth qui définissent les appels API nécessaires à la délégation.
La liste complète des étendues 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 d'étendue OAuth) pour le déclencher et agir au nom de toute identité existante dans Google Workspace. Comme nous l'avons appris, le compte de service générera des jetons d'accès selon ses besoins et selon les autorisations qu'il a pour les applications API REST.
Vérifiez la section précédente pour certains outils à utiliser avec cette délégation.
Délégation interorganisationnelle
L'ID OAuth du compte de service est global et peut être utilisé pour la délégation interorganisationnelle. Aucune restriction n'a été mise en place pour empêcher la délégation interglobale. 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 nécessiterait seulement un accès Super Admin à Workspace, et non 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 personnellement contrôlé.
Création d'un projet pour énumérer Workspace
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 dessus.
Par conséquent, un utilisateur peut créer un projet, activer les APIs 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 l'annuaire).
Vérifiez plus d'énumération dans:
GCP - IAM, Principals & Org Policies EnumAbus de Gcloud
Vous pouvez trouver plus d'informations sur le flux gcloud
pour vous connecter à:
Comme expliqué, gcloud peut demander la portée https://www.googleapis.com/auth/drive
qui permettrait à un utilisateur d'accéder au lecteur 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 lecteur 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 les CLOUDSDK_SCOPES
la portée 'https://www.googleapis.com/auth/drive'
:
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F2597608130-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F0fTBDNDP65sXMI73beHl%252Fuploads%252Fgit-blob-e9a307fc7f84e84b728826ef99237ceb33b83850%252Fimage%2520%28342%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=3423d326&sv=1)
Ainsi, la prochaine fois que l'utilisateur se connectera, il créera un jeton avec accès au drive que l'attaquant pourrait exploiter pour accéder au drive. Bien sûr, le navigateur indiquera que le jeton généré aura accès au drive, mais comme l'utilisateur appellera lui-même gcloud auth login
, il ne soupçonnera probablement rien.
Pour lister les fichiers du drive : curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"
De GWS à GCP
Accéder aux utilisateurs privilégiés de GCP
Si un attaquant a un accès complet sur GWS, il pourra accéder à des groupes avec des accès privilégiés sur GCP ou même à des utilisateurs, donc passer de GWS à GCP est généralement plus "simple" simplement parce que les utilisateurs de GWS ont des privilèges élevés sur GCP.
Escalade de privilèges des Google Groups
Par défaut, les utilisateurs peuvent rejoindre librement les groupes Workspace de l'Organisation et ces groupes peuvent avoir des autorisations GCP attribuées (vérifiez vos groupes sur https://groups.google.com/).
En abusant de la privilège d'escalade des groupes Google, vous pourriez être en mesure d'escalader vers un groupe avec un certain type d'accès privilégié à GCP.
Références
Apprenez et pratiquez le piratage AWS :HackTricks Formation Expert en Équipe Rouge AWS (ARTE)
Apprenez et pratiquez le piratage GCP :
HackTricks Formation Expert en Équipe Rouge GCP (GRTE)
Last updated