Dans cet épisode du podcast Police Secure, Clément Cruchet présente une analyse approfondie de la surface d’attaque de Google Cloud Platform (GCP), un sujet souvent négligé dans la communauté de la cybersécurité. Contrairement à Azure et AWS qui bénéficient d’une documentation abondante sur leurs vulnérabilités et vecteurs d’attaque, GCP reste le “petit frère oublié” du cloud computing. Cette présentation, donnée lors de la conférence Bide, vise à combler cette lacune en explorant les chemins qu’un attaquant pourrait emprunter dans un environnement GCP.

Clément observe qu’il y a trois ou quatre ans, la documentation sur les vulnérabilités GCP était quasi inexistante. Cette absence de contenu a même conduit certains utilisateurs sur des forums comme Reddit à affirmer de manière erronée que GCP était plus sûr ou exempt de mauvaises configurations. En réalité, ces failles existent bel et bien, mais elles n’avaient simplement pas été explorées en profondeur. Bien que la situation se soit améliorée depuis trois ans avec l’apparition de formations et de certifications, GCP demeure significativement moins couvert que ses concurrents.

Le cœur de la sécurité dans tous les environnements cloud réside dans la gestion des identités et des accès. Que ce soit Azure, AWS, GCP ou d’autres fournisseurs comme Oracle Cloud ou Alibaba Cloud, chacun possède son propre modèle IAM distinct. Ces modèles constituent la base de toute gestion des permissions, rôles et autorisations dans les environnements cloud. Le paradoxe est clair : sans permissions IAM, on ne peut rien faire, mais avec trop de permissions, on ouvre la porte à des abus et des défauts de configuration. La majorité des vulnérabilités dans les environnements cloud proviennent justement de ces mauvaises configurations au sein de l’IAM.

GCP se distingue par sa structure hiérarchique particulière. Contrairement à AWS qui fonctionne avec des comptes, ou à Azure qui utilise des tenants, des subscriptions et des groupes de ressources, GCP adopte une approche top-down très structurée. Au sommet se trouve l’organisation, généralement liée au nom de domaine de l’entreprise (par exemple company.com). Sous l’organisation, on trouve des folders, comparables aux unités organisationnelles (OU) d’Active Directory. Ces folders contiennent ensuite des projets, qui constituent l’unité administrative la plus importante.

Les projets dans GCP peuvent être comparés aux comptes AWS et c’est principalement à ce niveau que se fait la facturation. Pour beaucoup d’utilisateurs, seule la vue du projet est accessible, sans nécessairement avoir besoin d’une organisation complète. Cette flexibilité permet de commencer à travailler directement avec un projet sans passer par la création d’une infrastructure organisationnelle complète.

Un point crucial soulevé par Clément concerne les rôles primitifs dans GCP : éditeur, viewer, owner et browser. Ces rôles sont extrêmement dangereux car ils accordent des permissions bien trop larges. Par exemple, un rôle d’éditeur peut avoir accès à 800 permissions différentes, ce qui viole complètement le principe du moindre privilège. Le message clé est de ne jamais utiliser ces rôles primitifs dans une infrastructure GCP.

Même les rôles prédéfinis, pourtant plus granulaires, peuvent présenter des risques. Un rôle comme “compute admin”, qui devrait théoriquement se limiter à l’administration des ressources compute, peut en réalité inclure 800 permissions, dont certaines touchent à des services non liés comme BigQuery. La recommandation fondamentale est de créer des rôles personnalisés aussi granulaires que possible et d’appliquer systématiquement le principe du moindre privilège.

L’une des contributions majeures de cette présentation concerne le domain wide delegation, une technique d’exfiltration peu documentée. Cette fonctionnalité permet à un compte de service dans GCP d’interagir avec Google Workspace : accéder à Drive, Gmail, envoyer des emails au nom d’utilisateurs, récupérer des pièces jointes, etc.

Clément a développé un outil Python appelé “Delegate” pour démontrer et tester cette technique. Lorsqu’il a écrit son article de blog sur le sujet début 2023, il n’existait pratiquement aucune documentation sur cette vulnérabilité. Ironiquement, Palo Alto Networks a publié un article similaire plusieurs mois après, ce qui témoigne du caractère précurseur de ses recherches.

Le scénario d’attaque typique implique un attaquant qui compromet une machine virtuelle possédant un compte de service capable d’effectuer du domain wide delegation. Cette technique peut également servir de mécanisme de persistance, permettant à un attaquant de configurer sa propre délégation pour exfiltrer des données de manière discrète. L’outil Delegate permet de lire des emails, télécharger et uploader des fichiers sur Drive, offrant ainsi une capacité d’exfiltration complète.

Pour synthétiser ses recherches, Clément propose une kill chain communautaire spécifique à GCP, disponible sur GitHub (github.com/otendfreed/GCP-attack-matrix). Cette matrice d’attaque représente l’ensemble des tactiques, techniques et procédures (TTP) depuis la reconnaissance jusqu’à l’exfiltration et l’impact. L’objectif est de fournir un outil pour les équipes de sécurité souhaitant effectuer du purple teaming dans des environnements GCP, leur permettant d’évaluer leurs contrôles de sécurité et leur capacité de détection.

Ce podcast souligne l’importance de ne pas négliger GCP dans les stratégies de sécurité cloud. Bien que moins documenté, ce fournisseur présente des vecteurs d’attaque tout aussi critiques que ses concurrents. La recherche communautaire et le partage de connaissances sont essentiels pour identifier et corriger les vulnérabilités avant que des attaquants malveillants ne les exploitent. Comme le souligne Clément, pour attaquer un système, il faut d’abord le comprendre, et c’est précisément cette compréhension qu’il cherche à transmettre à la communauté de la cybersécurité.