Les clés API Google n'étaient pas secrètes, mais Gemini a changé les règles car il utilise les mêmes clés pour accéder à vos données

Un pirate peut accéder à vos données et vous facturer l'utilisation du LLM

Truffle Security a analysé des millions de sites web et trouvé près de 3 000 clés API Google, initialement déployées pour des services publics tels que Google Maps, qui authentifient désormais également Gemini, même si elles n'étaient pas destinées à cet usage. Avec une clé valide, un pirate peut accéder aux fichiers téléchargés, aux données mises en cache et facturer l'utilisation du LLM à votre compte.

Gemini, anciennement Bard, est un assistant conversationnel développé par l'entreprise Google. Pour générer du texte, il se base sur une famille de grands modèles de langage également appelée Gemini, introduite au public le 7 décembre 2023. Gemini est l'acronyme de Generalized Multimodal Intelligence Network. Gemini peut comprendre et interagir avec l'audio et la vidéo, et générer du texte (poésie, scripts, pièces musicales, courriels, lettres, etc.), du code, des traductions (entre plus de 100 langues). Il peut produire plusieurs types de contenu créatif (images, dessins, sons, musique, vidéos…), aider des chercheurs en analysant des données ou en générant des hypothèses.

Pendant plus de dix ans, Google a répété aux développeurs que les clés API Google (comme celles utilisées dans Maps, Firebase, etc.) n'étaient pas secrètes. Mais ce n'est plus vrai : Gemini accepte les mêmes clés pour accéder à vos données privées. Truffle Security a analysé des millions de sites web et trouvé près de 3 000 clés API Google, initialement déployées pour des services publics tels que Google Maps, qui authentifient désormais également Gemini, même si elles n'étaient pas destinées à cet usage. Avec une clé valide, un pirate peut accéder aux fichiers téléchargés, aux données mises en cache et facturer l'utilisation du LLM à votre compte. Même Google disposait d'anciennes clés API publiques, qu'il considérait comme non sensibles, mais qui pouvait être utiliser pour accéder au Gemini interne de Google.


Le problème fondamental

Google Cloud utilise un seul format de clé API (AIza...) à deux fins fondamentalement différentes : l'identification publique et l'authentification sensible.

Pendant des années, Google a explicitement indiqué aux développeurs que les clés API pouvaient être intégrées en toute sécurité dans le code côté client. La liste de contrôle de sécurité de Firebase stipule que les clés API ne sont pas des secrets.

Remarque : celles-ci sont très différentes des clés JSON de compte de service utilisées pour alimenter GCP.


La documentation JavaScript de Google Maps invite les développeurs à coller leur clé directement dans le code HTML.


Cela semble logique. Ces clés ont été conçues comme des identifiants de projet à des fins de facturation et peuvent être soumises à des restrictions supplémentaires (contournables) telles que la liste blanche des référents HTTP. Elles n'ont pas été conçues comme des identifiants d'authentification.

Puis Gemini est arrivé.


Lorsque vous activez l'API Gemini (Generative Language API) sur un projet Google Cloud, les clés API existantes dans ce projet (y compris celles qui se trouvent dans le JavaScript public de votre site web) peuvent accéder silencieusement aux points de terminaison sensibles de Gemini. Sans avertissement. Sans boîte de dialogue de confirmation. Sans notification par e-mail.

Cela crée deux problèmes distincts :

Extension rétroactive des privilèges. Vous avez créé une clé Maps il y a trois ans et l'avez intégrée dans le code source de votre site web, exactement comme Google vous l'avait demandé. Le mois dernier, un développeur de votre équipe a activé l'API Gemini pour un prototype interne. Votre clé Maps publique est désormais un identifiant Gemini. Toute personne qui la récupère peut accéder à vos fichiers téléchargés, à votre contenu mis en cache et faire grimper votre facture d'IA. Personne ne vous en a informé.

Paramètres par défaut non sécurisés. Lorsque vous créez une nouvelle clé API dans Google Cloud, elle est par défaut « sans restriction », ce qui signifie qu'elle est immédiatement valable pour toutes les API activées dans le projet, y compris Gemini. L'interface utilisateur affiche un avertissement concernant « l'utilisation non autorisée », mais l'architecture par défaut est largement ouverte.


Résultat : des milliers de clés API qui ont été déployées comme des jetons de facturation inoffensifs sont désormais des identifiants Gemini actifs sur l'internet public.

Ce qui fait de cela une élévation de privilèges plutôt qu'une mauvaise configuration, c'est la séquence des événements.

1. Un développeur crée une clé API et l'intègre dans un site web pour Maps. (À ce stade, la clé est inoffensive.)

2. L'API Gemini est activée sur le même projet. (Désormais, cette même clé peut accéder à des points de terminaison Gemini sensibles.)

3. Le développeur n'est jamais averti que les privilèges de la clé ont changé en arrière-plan. (La clé est passée d'un identifiant public à un identifiant secret).

Bien que les utilisateurs puissent restreindre les clés API Google (par service API et application), la vulnérabilité réside dans la posture par défaut non sécurisée (CWE-1188) et l'attribution incorrecte des privilèges (CWE-269) :

- Mise à niveau implicite de la confiance : Google a appliqué rétroactivement des privilèges sensibles à des clés existantes qui étaient déjà légitimement déployées dans des environnements publics (par exemple, des bundles JavaScript).

- Absence de séparation des clés : une conception sécurisée de l'API nécessite des clés distinctes pour chaque environnement (clés publiables vs clés secrètes). En s'appuyant sur un format de clé unique pour les deux, le système s'expose à des compromissions et à la confusion.

Échec des paramètres par défaut sécurisés : l'état par défaut d'une clé générée via le panneau API GCP permet d'accéder à l'API Gemini sensible (en supposant qu'elle soit activée). Un utilisateur qui crée une clé pour un widget de carte génère sans le savoir un identifiant capable d'effectuer des actions administratives.

Ce qu'un pirate peut faire

L'attaque est très simple. Un pirate visite votre site web, consulte le code source de la page et copie votre clé AIza... à partir de l'intégration Maps. Il exécute ensuite :



Au lieu d'un message d'erreur 403 Forbidden, il obtient un message 200 OK. À partir de là, le pirate peut :

- Accéder à des données privées. Les points de terminaison /files/ et /cachedContents/ peuvent contenir des ensembles de données téléchargés, des documents et du contenu mis en cache. Tout ce que le propriétaire du projet a stocké via l'API Gemini est accessible.

- Faire grimper votre facture. L'utilisation de l'API Gemini n'est pas gratuite. En fonction du modèle et de la fenêtre contextuelle, un acteur malveillant qui...