Français - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

GCP <--> Workspace Pivoting

Apprenez le piratage AWS de zéro à héros avec htARTE (Expert en équipe rouge AWS de HackTricks)!

Autres façons de soutenir HackTricks :

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 :

pageGCP - Understanding Domain-Wide Delegation

Compromettre 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. S'il n'a aucun accès, cela sera inutile.

GCP Générer un jeton de délégation

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:

# Impersonate indicated user
python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-key-file>

# Impersonate indicated user and add additional scopes
python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-key-file> --scopes "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"

DeleFriend

C'est un outil qui peut effectuer l'attaque en suivant ces étapes :

  1. Énumérer les projets GCP en utilisant l'API Resource Manager.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. Énumérer et créer un nouveau jeton d'accès de porteur pour chaque JWT et valider le jeton contre l'API tokeninfo.

Script Python de Gitlab

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 l'utiliser :

# Install requirements
pip install --upgrade --user oauth2client

# Validate access only
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com

# List the directory
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com \
--list

# Create a new admin account
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com \
--account pwned

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:

  1. 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 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 l'autorisation 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 (autorisation iam.serviceAccountKeys.create).

  2. 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 sur la page Contrôles API → Gérer la délégation à l'échelle du domaine dans la console d'administration de Google Workspace.

  1. Attribution du privilège des étendues OAuth: Lors de la configuration d'une nouvelle délégation, Google requiert seulement 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

  1. 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 pas 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 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 l'annuaire).

# Create project
gcloud projects create <uniq-projec-name> --name=proj-name
# Set project
gcloud config set project <uniq-projec-name>
# Enable svcs
gcloud services enable admin.googleapis.com
gcloud services enable cloudidentity.googleapis.com
# Get org ID
gcloud organizations list
# Get currents email user groups (at least you can check the groups and members of the groups you belong to)
gcloud identity groups memberships search-transitive-groups --member-email <email> --labels=cloudidentity.googleapis.com/groups.discussion_forum
gcloud identity groups memberships list --group-email=g<group-email>

# FROM HERE THE USER NEEDS TO HAVE ENOUGH WORKSPACE ACCESS
gcloud beta identity groups preview --customer <org-cust-id>

Vérifiez plus d'énumération dans:

pageGCP - IAM, Principals & Org Policies Enum

Abus de Gcloud

Vous pouvez trouver plus d'informations sur le flux gcloud pour vous connecter dans:

pageGCP - Non-svc Persistance

Comme expliqué là-bas, 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:

gcloud auth login --enable-gdrive-access

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':

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 exécutera lui-même la commande 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 à GWS, il pourra accéder à des groupes avec des accès privilégiés sur GCP ou même à des utilisateurs, passant ainsi 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 le piratage AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres façons de soutenir HackTricks :

PrécédentGCP - Storage EnumSuivantGCP - Understanding Domain-Wide Delegation

Dernière mise à jour