GCP - Informations de base

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

• Consultez les subscription plans!
• Rejoignez le 💬 Discord group ou le telegram group ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des hacking tricks en soumettant des PRs aux HackTricks et HackTricks Cloud github repos.

Hiérarchie des ressources

Google Cloud utilise une hiérarchie des ressources qui est conceptuellement similaire à celle d’un système de fichiers traditionnel. Cela fournit un flux de travail logique parent/enfant avec des points d’attache spécifiques pour les politiques et les autorisations.

À un niveau élevé, cela ressemble à ceci :

Organization
--> Folders
--> Projects
--> Resources

Une machine virtuelle (appelée une instance de calcul) est une ressource. Une ressource réside dans un projet, probablement aux côtés d’autres instances de calcul, de buckets de stockage, etc.

Migration de Projets

Il est possible de migrer un projet sans organisation vers une organisation avec les permissions roles/resourcemanager.projectCreator et roles/resourcemanager.projectMover. Si le projet se trouve dans une autre organisation, il est nécessaire de contacter le support GCP pour les déplacer hors de l’organisation d’abord. Pour plus d’infos, consultez ceci.

Politiques d’Organisation

Permettent de centraliser le contrôle sur les ressources cloud de votre organisation :

• Centraliser le contrôle pour configurer des restrictions sur la façon dont les ressources de votre organisation peuvent être utilisées.
• Définir et établir des garde-fous pour que vos équipes de développement restent dans les limites de conformité.
• Aider les propriétaires de projets et leurs équipes à avancer rapidement sans craindre de violer la conformité.

Ces politiques peuvent être créées pour affecter l’ensemble de l’organisation, le(s) dossier(s) ou le(s) projet(s). Les descendants du nœud de hiérarchie de ressources ciblé héritent de la politique d’organisation.

Pour définir une politique d’organisation, vous choisissez un contrainte, qui est un type particulier de restriction contre un service Google Cloud ou un groupe de services Google Cloud. Vous configurez cette contrainte avec vos restrictions souhaitées.

Cas d’utilisation courants

• Limiter le partage de ressources en fonction du domaine.
• Limiter l’utilisation des comptes de service Identity and Access Management.
• Restreindre l’emplacement physique des ressources nouvellement créées.
• Désactiver la création de comptes de service.

Il existe de nombreuses autres contraintes qui vous donnent un contrôle granulaire sur les ressources de votre organisation. Pour plus d’informations, consultez la liste de toutes les contraintes du Service de Politique d’Organisation.

Politiques d’Organisation par Défaut

Rôles IAM

Ce sont comme des politiques IAM dans AWS car chaque rôle contient un ensemble de permissions.

Cependant, contrairement à AWS, il n’y a pas de dépôt centralisé de rôles. Au lieu de cela, les ressources donnent X rôles d’accès à Y principaux, et le seul moyen de savoir qui a accès à une ressource est d’utiliser la méthode get-iam-policy sur cette ressource.
Cela pourrait poser un problème car cela signifie que le seul moyen de savoir quelles permissions un principal a est de demander à chaque ressource à qui elle accorde des permissions, et un utilisateur pourrait ne pas avoir les permissions nécessaires pour obtenir les permissions de toutes les ressources.

Il existe trois types de rôles dans IAM :

• Rôles de base/primitive, qui incluent les rôles Propriétaire, Éditeur et Visionneur qui existaient avant l’introduction de l’IAM.
• Rôles prédéfinis, qui fournissent un accès granulaire pour un service spécifique et sont gérés par Google Cloud. Il existe de nombreux rôles prédéfinis, vous pouvez voir tous ceux-ci avec les privilèges qu’ils ont ici.
• Rôles personnalisés, qui fournissent un accès granulaire selon une liste de permissions spécifiée par l’utilisateur.

Il existe des milliers de permissions dans GCP. Pour vérifier si un rôle a une permission, vous pouvez chercher la permission ici et voir quels rôles l’ont.

Vous pouvez également chercher ici les rôles prédéfinis offerts par chaque produit. Notez que certains rôles ne peuvent pas être attachés à des utilisateurs et uniquement à des SAs en raison de certaines permissions qu’ils contiennent.
De plus, notez que les permissions ne prendront effet que si elles sont attachées au service pertinent.

Ou vérifiez si un rôle personnalisé peut utiliser une permission spécifique ici.

GCP - IAM, Principals & Org Policies Enum

Utilisateurs

Dans la console GCP, il n’y a pas de gestion des Utilisateurs ou Groupes, cela se fait dans Google Workspace. Bien que vous puissiez synchroniser un autre fournisseur d’identité dans Google Workspace.

Vous pouvez accéder aux utilisateurs et groupes de Workspaces à https://admin.google.com.

MFA peut être forcée pour les utilisateurs de Workspaces, cependant, un attaquant pourrait utiliser un jeton pour accéder à GCP via cli qui ne sera pas protégé par MFA (il sera protégé par MFA uniquement lorsque l’utilisateur se connecte pour le générer : gcloud auth login).

Groupes

Lorsqu’une organisation est créée, plusieurs groupes sont fortement suggérés à être créés. Si vous gérez l’un d’eux, vous pourriez avoir compromis tout ou une partie importante de l’organisation :

Politique de Mot de Passe par Défaut

• Appliquer des mots de passe forts
• Entre 8 et 100 caractères
• Pas de réutilisation
• Pas d’expiration
• Si des personnes accèdent à Workspace via un fournisseur tiers, ces exigences ne s’appliquent pas.

Comptes de service

Ce sont les principaux que les ressources peuvent avoir attachés et accéder pour interagir facilement avec GCP. Par exemple, il est possible d’accéder au jeton d’authentification d’un compte de service attaché à une VM dans les métadonnées.
Il est possible de rencontrer certains conflits lors de l’utilisation à la fois de IAM et des portées d’accès. Par exemple, votre compte de service peut avoir le rôle IAM de compute.instanceAdmin, mais l’instance que vous avez compromise a été limitée par la restriction de portée de https://www.googleapis.com/auth/compute.readonly. Cela vous empêcherait d’apporter des modifications en utilisant le jeton OAuth qui est automatiquement attribué à votre instance.

C’est similaire aux rôles IAM d’AWS. Mais contrairement à AWS, tout compte de service peut être attaché à n’importe quel service (il n’est pas nécessaire de l’autoriser via une politique).

Plusieurs des comptes de service que vous trouverez sont en fait générés automatiquement par GCP lorsque vous commencez à utiliser un service, comme :

PROJECT_NUMBER-compute@developer.gserviceaccount.com
PROJECT_ID@appspot.gserviceaccount.com

Cependant, il est également possible de créer et d’attacher des comptes de service personnalisés aux ressources, qui ressembleront à ceci :

SERVICE_ACCOUNT_NAME@PROJECT_NAME.iam.gserviceaccount.com

Clés & Jetons

Il existe 2 principales façons d’accéder à GCP en tant que compte de service :

• Via des jetons OAuth : Ce sont des jetons que vous obtiendrez à partir d’endroits comme les points de terminaison de métadonnées ou en volant des requêtes http et ils sont limités par les portées d’accès.
• Clés : Ce sont des paires de clés publiques et privées qui vous permettront de signer des requêtes en tant que compte de service et même de générer des jetons OAuth pour effectuer des actions en tant que compte de service. Ces clés sont dangereuses car elles sont plus compliquées à limiter et à contrôler, c’est pourquoi GCP recommande de ne pas les générer.
• Notez qu’à chaque fois qu’un SA est créé, GCP génère une clé pour le compte de service à laquelle l’utilisateur n’a pas accès (et qui ne sera pas listée dans l’application web). Selon ce fil, cette clé est utilisée en interne par GCP pour donner accès aux points de terminaison de métadonnées afin de générer les jetons OAuth accessibles.

Portées d’accès

Les portées d’accès sont attachées aux jetons OAuth générés pour accéder aux points de terminaison de l’API GCP. Elles restreignent les permissions du jeton OAuth.
Cela signifie que si un jeton appartient à un Propriétaire d’une ressource mais n’a pas la portée dans le jeton pour accéder à cette ressource, le jeton ne peut pas être utilisé pour (ab)user de ces privilèges.

Google recommande en fait de ne pas utiliser les portées d’accès et de s’appuyer totalement sur IAM. Le portail de gestion web impose en fait cela, mais les portées d’accès peuvent toujours être appliquées aux instances en utilisant des comptes de service personnalisés de manière programmatique.

Vous pouvez voir quelles portées sont assignées en interrogeant :

curl 'https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=<access_token>'

{
"issued_to": "223044615559.apps.googleusercontent.com",
"audience": "223044615559.apps.googleusercontent.com",
"user_id": "139746512919298469201",
"scope": "openid https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/cloud-platform https://www.googleapis.com/auth/appengine.admin https://www.googleapis.com/auth/sqlservice.login https://www.googleapis.com/auth/compute https://www.googleapis.com/auth/accounts.reauth",
"expires_in": 2253,
"email": "username@testing.com",
"verified_email": true,
"access_type": "offline"
}

Les scopes précédents sont ceux générés par défaut en utilisant gcloud pour accéder aux données. Cela est dû au fait que lorsque vous utilisez gcloud, vous créez d’abord un jeton OAuth, puis l’utilisez pour contacter les points de terminaison.

Le scope le plus important de ceux-ci est cloud-platform, ce qui signifie essentiellement qu’il est possible d’accéder à n’importe quel service dans GCP.

Vous pouvez trouver une liste de tous les scopes possibles ici.

Si vous avez des identifiants de navigateur gcloud, il est possible d’obtenir un jeton avec d’autres scopes, en faisant quelque chose comme :

# Maybe you can get a user token with other scopes changing the scopes array from ~/.config/gcloud/credentials.db

# Set new scopes for SDKs credentials
gcloud auth application-default login --scopes=https://www.googleapis.com/auth/userinfo.email,https://www.googleapis.com/auth/cloud-platform,https://www.googleapis.com/auth/sqlservice.login,https://www.googleapis.com/auth/appengine.admin,https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/accounts.reauth,https://www.googleapis.com/auth/admin.directory.user,https://www.googleapis.com/auth/admin.directory.group,https://www.googleapis.com/auth/admin.directory.domain,https://www.googleapis.com/auth/admin.directory.user

# Print new token
gcloud auth application-default print-access-token

# To use this token with some API you might need to use curl to indicate the project header with --header "X-Goog-User-Project: <project-name>"

Politiques IAM Terraform, Liens et Adhésions

Comme défini par terraform dans https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam, en utilisant terraform avec GCP, il existe différentes manières d’accorder à un principal l’accès à une ressource :

• Adhésions : Vous définissez des principaux comme membres de rôles sans restrictions sur le rôle ou les principaux. Vous pouvez mettre un utilisateur comme membre d’un rôle, puis mettre un groupe comme membre du même rôle et également définir ces principaux (utilisateur et groupe) comme membres d’autres rôles.
• Liens : Plusieurs principaux peuvent être liés à un rôle. Ces principaux peuvent toujours être liés ou être membres d’autres rôles. Cependant, si un principal qui n’est pas lié au rôle est défini comme membre d’un rôle lié, la prochaine fois que le lien est appliqué, l’adhésion disparaîtra.
• Politiques : Une politique est autoritaire, elle indique des rôles et des principaux et ensuite, ces principaux ne peuvent pas avoir plus de rôles et ces rôles ne peuvent pas avoir plus de principaux à moins que cette politique ne soit modifiée (pas même dans d’autres politiques, liens ou adhésions). Par conséquent, lorsqu’un rôle ou un principal est spécifié dans une politique, tous ses privilèges sont limités par cette politique. Évidemment, cela peut être contourné si le principal a la possibilité de modifier la politique ou des permissions d’escalade de privilèges (comme créer un nouveau principal et le lier à un nouveau rôle).

Références

• https://about.gitlab.com/blog/2020/02/12/plundering-gcp-escalating-privileges-in-google-cloud-platform/
• https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

• Consultez les subscription plans!
• Rejoignez le 💬 Discord group ou le telegram group ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des hacking tricks en soumettant des PRs aux HackTricks et HackTricks Cloud github repos.