LeakyLooker: l'échec de passage du locataire au Studio Looker qui pourrait exfilter les données Google Cloud

Plus tôt cette année, les chercheurs en sécurité ont révélé un ensemble d'échecs qui ont affecté Looker Studio, l'outil de Google pour créer des rapports et des panneaux à partir de diverses sources de données. Tendable a baptisé ce paquet de défauts comme LeakyLooker et l'a décrite comme une série de faiblesses de « cross-tenant » capables, au pire des scénarios, de permettre à un attaquant de mener des consultations SQL arbitraires contre des bases de données étrangères et d'extraire des informations sensibles hébergées dans des projets Google Cloud.

Bien que rien n'indique que ces trous aient été exploités dans des environnements réels, la recherche a montré clairement que l'impact potentiel était grave. Suite à une notification responsable en juin 2025, Google a appliqué des corrections. Le rapport public de Tenable sur ces enquêtes est disponible avec des explications techniques détaillées, par exemple dans cette analyse générale publié par le.

Les vulnérabilités identifiées comprennent plusieurs vecteurs différents: injections SQL qui ne nécessitent pas d'interaction utilisateur (zéro-clic), abus d'identification stockés dans des connecteurs JDBC, défaillances de fonction natives qui ont permis d'injecter dans BigQuery, fuites de source de données par des liens ou la rendu d'images, techniques de filtrage du temps et comptage des images, et même un moyen de causer des effets de déni de ressources dans BigQuery. Tendable documenté chaque cas avec sa propre fiche technique, accessible au public, par exemple ici sur l'injection via des connecteurs et des identifiants stockés TRA-2025-28 et TRA-2025-29 ou des problèmes spécifiques liés à BigQuery et Spanner TRA-2025-27 et TRA-2025-37.

Ce qui rend ces échecs particulièrement inquiétants est non seulement la possibilité d'exécuter des phrases SQL malveillantes, mais la nature transversale du problème: de nombreuses organisations connectent Looker Studio avec des services tels que BigQuery, Spenner, Google Sheets, PostgreSQL, MySQL ou Cloud Storage pour construire des panneaux. Si un attaquant parvient à exploiter l'une de ces chaînes, il pourrait analyser des rapports publics ou utiliser un rapport partagé pour obtenir des références et, à partir de là, accéder à des ensembles de données complets dans différents projets de GCP.

Un scénario décrit par les chercheurs illustre comment un flux apparemment innocent - par exemple, rendre une visualisation publique ou la partager avec un collaborateur - peut devenir un vecteur d'attaque. Grâce à un échec dans la logique de la copie des rapports, un opposant a pu cloner un rapport et conserver les identifiants du propriétaire original, avec la possibilité ultérieure de modifier ou de supprimer des tableaux dans la base de données liée. Dans d'autres cas documentés, il suffisait à la victime d'ouvrir ou de visualiser un rapport conçu ad hoc pour son navigateur pour exécuter le code qui a contacté un projet contrôlé par l'agresseur, facilitant la reconstruction des données à partir des dossiers.

Selon le chercheur responsable, ces vulnérabilités ont brisé l'une des garanties fondamentales du système: qu'un rôle de lecture ou de «spectateur» ne devrait pas pouvoir manipuler ou contrôler les données qu'il visualise. En fait, la recherche a montré comment un utilisateur avec un minimum de permis pourrait indirectement causer l'exfiltration ou la modification d'informations dans des services tels que BigQuery et Google Sheets.

D'un point de vue défensif, la publication de la réponse de Tenable et de Google met en évidence plusieurs leçons pratiques que toute équipe de sécurité ou gestionnaire de cloud devrait envisager. Il est recommandé d'examiner les rapports de Looker Studio qui sont publiquement exposés, de vérifier les connecteurs qui stockent les justificatifs et d'appliquer le principe du privilège mineur dans les comptes de service et les justificatifs connexes. Google maintient la documentation sur Looker Studio qui aide à comprendre comment les rapports sont partagés et gérés, par exemple au centre d'aide Studio Looker, et ceux qui utilisent BigQuery peut revoir les meilleures pratiques sur la page de BigQuery et les guides de sécurité Google Cloud dans cloud.google.com / sécurité.

Il est important de souligner que les échecs étaient le résultat de combinaisons logiques complexes et non d'une seule erreur triviale : l'attaque complète nécessite de chaîner plusieurs conditions et d'exploiter des comportements inattendus sur la plate-forme. Cependant, l'existence de ces chaînes montre que les interfaces entre les services et la gestion des titres de compétence sont des domaines critiques qui nécessitent des essais rigides et des modèles de menace mis à jour.

La divulgation responsable était essentielle à la réduction des risques : En juin 2025, Google a informé Tenable et, à la suite de la collaboration entre les deux parties, des corrections ont été apportées avant que les informations techniques ne soient largement diffusées. Cette coordination a très probablement évité une utilisation malveillante massive et a donné aux gestionnaires le temps de prendre des mesures préventives.

Pour les organisations qui dépendent des tableaux de bord et des données en nuage, cet épisode devrait rappeler que le confort du partage et de la visualisation de l'information ne devrait pas sacrifier les contrôles de sécurité de base. Rotation des références après les changements, limitation de l'accès aux connecteurs sensibles, examen des politiques de partage et surveillance des tentatives de consultation inhabituelles dans des services comme BigQuery sont des étapes pratiques qui réduisent la surface de l'attaque.

Dans l'ensemble, LeakyLooker est un autre exemple de la façon dont la complexité des plateformes cloud et l'interaction entre les composants peuvent générer de nouveaux vecteurs d'attaque. La bonne nouvelle est que les problèmes ont été résolus après la notification, et la publication technique de Tenable offre du matériel pour les équipes de sécurité pour apprendre et renforcer leurs défenses. Pour ceux qui veulent approfondir les résultats, Tenable publie des notes techniques individuelles sur chaque vecteur, y compris celles relatives aux filtres par des images et des liens ( TRA-2025-30), des oracles temporaires ( TRA-2025-31) et des itinéraires spécifiques vers BigQuery et Spenner ( TRA-2025-38).

Le moral des responsables techniques et de gestion est clair : la sécurité dans les environnements de données partagées nécessite une surveillance constante, des examens périodiques des permis et une politique ferme sur ce qui est publié et partagé. Tenez-vous au courant des avis de sécurité des fournisseurs et profitez des ressources de recherche - comme celles offertes par Tenable - pour combler rapidement les lacunes avant de pouvoir les exploiter.