En bref : lorsque vous supprimez une clé API Google, le système indique qu’elle est supprimée immédiatement. Nos tests montrent qu’il faut compter environ 23 minutes. Pendant ce laps de temps, un pirate disposant d’une clé divulguée conserve l’accès à vos données et aux API activées (y compris Gemini). Vous n’avez aucun moyen de la révoquer plus rapidement ni de vérifier quand elle cesse de fonctionner. Google a classé notre rapport comme « ne sera pas corrigé ».
Lorsque vous supprimez une clé API, vous vous attendez à ce que l'accès soit immédiatement interrompu.
Les clés API Google ne fonctionnent pas ainsi. La révocation se propage progressivement à travers l'infrastructure de Google. Certains serveurs rejettent la clé en quelques secondes, tandis que d'autres continuent de l'accepter pendant 23 minutes.
Un pirate en possession de votre clé supprimée peut continuer à envoyer des requêtes jusqu'à ce que l'une d'elles atteigne un serveur qui n'a pas encore été mis à jour. Si Gemini est activé sur le projet, il peut extraire les fichiers que vous avez téléchargés et récupérer les conversations mises en cache.
La console GCP n'affiche pas la clé et ne vous indique pas si celle-ci est toujours valide. Vous comptez sur l'infrastructure de Google pour qu'elle finisse par se mettre à jour.
L'authentification ne doit pas être « à cohérence finale »
De nombreux services Cloud Google Cloud sont, par conception, à cohérence différée. Dans ce modèle, les mises à jour se propagent progressivement sur l'ensemble des serveurs plutôt que d'un seul coup. Ce compromis permet à Google de s'étendre à l'échelle mondiale tout en conservant sa rapidité, et pour la plupart des services, le décalage est imperceptible. Mais en matière d'authentification, ce compromis est plus difficile à justifier.
Les délais liés à la révocation des identifiants peuvent être exploités. Il y a quelques mois, Eduard Agavriloae a révélé l'existence d'un délai de 4 secondes qui permettait à des clés d'accès AWS supprimées de créer de nouveaux identifiants. Quatre secondes suffisaient pour que cela ait des conséquences sur AWS.
Compte tenu de l'attention récente portée aux clés API Google utilisées pour accéder à Gemini, nous avons cherché à déterminer combien de temps la période de révocation des clés API Google reste ouverte.
Qu'est-ce qu'un délai de rétractation ?
La période de révocation correspond au délai entre la suppression d'une clé et la dernière authentification réussie.
Si ce délai ne dure que quelques microsecondes, le comportement correspond à ce à quoi s'attendent les utilisateurs. S'il est plus long, chaque seconde supplémentaire donne aux pirates davantage de temps pour exploiter une clé volée.
Détermination de la période de révocation
Pour évaluer le délai de révocation des clés API de Google, nous avons effectué 10 tests sur deux jours.
À chaque test, nous avons créé une clé API, puis l'avons supprimée, avant d'envoyer 3 à 5 requêtes authentifiées par seconde jusqu'à ce qu'aucune réponse valide ne soit renvoyée pendant plusieurs minutes.
Nous avons choisi ce débit car nous n'avons aucun contrôle sur la manière dont Google achemine nos requêtes vers les différents serveurs d'authentification répartis à travers le monde. Ce volume visait à faire passer les requêtes par le plus grand nombre possible de ces serveurs à chaque essai, tout en respectant l'infrastructure de Google. Nous ne pouvons pas affirmer qu'un débit de requêtes plus élevé permettrait d'allonger la fenêtre d'observation. Un attaquant n'a aucune raison de limiter le débit comme nous l'avons fait ; il convient donc de noter que nos chiffres ne reflètent peut-être pas le pire des cas.
Par souci d'exhaustivité, nous avons également procédé à des vérifications ponctuelles de notre travail quelques semaines plus tard afin de nous assurer que le comportement observé n'était pas dû à des problèmes réseau passagers.
23 minutes
Sur les dix tests effectués, la durée maximale a atteint près de 23 minutes ! C'est une durée incroyablement longue pendant laquelle une clé supprimée peut encore permettre une authentification réussie.
La durée la plus courte était de près de 8 minutes, et la durée médiane avoisinait les 16 minutes. D'un essai à l'autre, le taux de réussite était très variable : une minute après la suppression, 79 % des requêtes ont abouti dans un essai, contre seulement 5 % dans un autre.
Un pirate en possession d'une clé volée ne constate ni coupure nette ni dégradation prévisible. L'accès continue de fonctionner, de manière irrégulière, jusqu'à ce qu'il finisse par s'interrompre.
Suivi d'un essai clinique unique dans la console GCP
Pour illustrer les incohérences de l'infrastructure de Google, nous avons suivi l'un de nos tests à l'aide du graphique « Trafic par identifiant » dans GCP. La ligne inférieure (bleue) indique les authentifications réussies et reflète la durée de la fenêtre de révocation.
Nous ne nous attendions pas à voir d'autres données, mais une deuxième ligne est apparue. La ligne supérieure (verte) représente les requêtes rejetées et porte l'intitulé apikey : INCONNU. Nous avions (à tort) supposé que les requêtes non valides seraient simplement ignorées sans être attribuées à aucun projet. Or, GCP les inclut dans ce graphique.
Pour mieux comprendre ce mystère apikey : INCONNU valeur, nous avons tenté de nous authentifier à l'aide d'une clé API supprimée depuis plusieurs jours. Étonnamment, ces requêtes sont apparues sur le même graphique, regroupées dans le même apikey : INCONNU groupe.
Selon nous, Google conserve les informations d'attribution du projet même après la suppression de la clé, au cas où les utilisateurs décideraient de restaurer les identifiants.
Pour les équipes chargées de la réponse aux incidents (IR) qui enquêtent sur une fuite d'identifiants, le apikey : INCONNU Cette valeur peut prêter à confusion. Toute requête effectuée à l'aide d'une clé API Google supprimée est regroupée dans la même catégorie « UNKNOWN », ce qui rend difficile de déterminer quelles requêtes sont liées à un identifiant particulier. Une requête dans ce groupe peut signifier qu'un acteur malveillant tente toujours de s'authentifier avec la clé supprimée, ou qu'il s'agit d'un service légitime fonctionnant sur une clé obsolète et sans rapport avec la situation.
Si vous vous trouvez dans la fenêtre de révocation de 23 minutes, recherchez les authentifications valides effectuées à l'aide de la clé divulguée. Si vous vous trouvez en dehors de cette fenêtre, le risque semble extrêmement faible.
Différences régionales en matière d'uniformité
Nous avons mené la première expérience à partir d'une adresse IP résidentielle située sur la côte Est des États-Unis. Nous avons émis l'hypothèse que la réalisation d'une expérience similaire sur des machines virtuelles situées dans différentes régions GCP pourrait mettre en évidence d'autres incohérences.
Nous avons lancé une machine virtuelle dans trois régions : us-east1, Europe-Ouest 1, et Asie du Sud-Est 1. Nous avons ensuite effectué cinq essais. Pour chaque essai, nous avons supprimé une seule clé API et envoyé des requêtes depuis chacune des trois machines virtuelles en parallèle.
Deux éléments ont retenu notre attention. Tout d'abord, immédiatement après la suppression d'une clé, les machines virtuelles situées dans différentes régions ont affiché des taux de réussite d'authentification très variables. Le tableau ci-dessous présente le pourcentage de requêtes valides au cours de la première minute, par région.
Regardez le procès n° 1 : us-east1 82%, Europe-Ouest 1 60%, Asie du Sud-Est 1 32 %. Les machines virtuelles situées plus loin des États-Unis ont réagi plus rapidement à la suppression, ce qui va à l'encontre de ce à quoi on pourrait s'attendre. Nous ne pouvons pas en expliquer exactement la raison de l'extérieur. Le routage des requêtes chez Google est plus complexe que la simple équation « région de la machine virtuelle = région du serveur », et une machine virtuelle à Singapour ne communique pas nécessairement avec des serveurs situés à Singapour. Cependant, cette tendance s'est confirmée lors de tous les essais, ce qui suggère que cette différence s'explique par des facteurs liés à l'infrastructure régionale, à la mise en cache ou à l'affinité de routage.
Deuxièmement, cet écart régional ne s'est pas limité aux premières minutes. Sur l'ensemble de la période, Asie du Sud-Est 1 affichait un taux médian de réussite des demandes d'authentification de 22 %, tandis que us-east1 et Europe-Ouest 1 Les deux se sont situés aux alentours de 49 %. L'Asie est restée en baisse minute après minute, et pas seulement au début.
Quelle que soit la cause de ces différences, l'emplacement du serveur détermine clairement le comportement d'une clé supprimée après sa suppression.
Autres identifiants Google
Lors de nos tests, nous avons tous utilisé des clés donnant accès à Gemini, mais nous avons observé le même comportement avec des clés limitées à d'autres API GCP, telles que BigQuery et Maps. Ce délai est inhérent au type d'identifiant, et non aux API activées dans le projet.
Par souci d'exhaustivité, nous avons testé deux autres types d'identifiants Google :
- Nouvelles clés API Gemini (préfixe AQ.). La suppression est effective en environ 1 minute.
- Clés du compte de service Google. La suppression a été répercutée en environ 5 secondes.
Les deux fonctionnent à l'échelle de Google, et les deux sont révoquées bien plus rapidement que les 23 minutes que nous avons mesurées pour les clés API de Google.
Communication à Google
Nous avons signalé ce problème à Google. Google a classé ce signalement comme « ne sera pas corrigé ». D'après ce que nous avons compris, l'équipe estime que le délai de propagation est une caractéristique connue du système et ne constitue pas un problème de sécurité.
Bien que Google indique officiellement que son API IAM est cohérente à terme, l'entreprise ne précise pas ce comportement pour les clés API Google.
[Légende : Capture d'écran de la page de documentation de l'API IAM de Google.]
Attentes déçues des utilisateurs
Les systèmes distribués à l'échelle de Google sont complexes, et cela ne constitue en aucun cas une critique à l'égard de l'équipe IAM de GCP. Cependant, un délai de rétractation de 23 minutes est fondamentalement en contradiction avec ce que les utilisateurs attendent d'un bouton de suppression. Le décalage entre cette attente et le comportement de Google met en évidence quatre problèmes :
1. L'interface utilisateur est extrêmement trompeuse.
Lorsque vous supprimez la clé, Google la retire de votre interface et vous indique : « Une fois supprimée, elle ne peut plus être utilisée pour effectuer des requêtes API. » Cette affirmation est manifestement fausse. L'utilisateur n'a aucun moyen de savoir si la clé est toujours active, aucun moyen d'accélérer sa révocation, et aucun moyen de confirmer quand elle a complètement cessé de fonctionner.
2. Google a mis en place un processus de révocation plus rapide pour d'autres types d'identifiants.
Les révocations d'identifiants de compte de service sont répercutées en environ 5 secondes. Le nouveau format de clé API de Gemini est répercuté en environ une minute. Les deux fonctionnent à l'échelle de Google. Cela suggère que ce problème est techniquement résoluble pour les clés API de Google également.
3. Les fenêtres de cohérence longues ne sont pas compatibles avec l'authentification.
Lorsqu'on supprime un identifiant, on s'attend à ce qu'il soit définitivement désactivé. Même un délai de quelques secondes peut avoir des conséquences, comme l'a montré l'étude menée par Eduard sur AWS l'année dernière.
4. Les longues périodes de révocation entravent la génération de certificats « juste à temps ».
Un fournisseur de services qui souhaite générer dynamiquement des clés API Google doit prévoir un délai de 23 minutes après la révocation avant que la clé ne soit définitivement désactivée. Cela est incompatible avec le fonctionnement JIT .
Travailler autour de la fenêtre
En attendant que Google mette en place un système de révocation plus rapide, c'est aux utilisateurs qu'il revient de combler cette lacune. Deux mesures peuvent y contribuer.
1. Considérez la suppression d'une clé comme une opération qui prend 30 minutes, et non comme une opération instantanée.
Si vous intervenez suite à la fuite d'une clé API Google, partez du principe que celle-ci reste active pendant 30 minutes après avoir cliqué sur « Supprimer ». Cela vous laisse une marge de manœuvre supplémentaire par rapport aux 23 minutes maximum que nous avons observées. Organisez le reste de votre intervention en fonction de ce délai.
2. Surveillez l'utilisation pendant cette période.
Dans la section « API et services activés » de la console GCP, examinez les requêtes API par identifiant. Si vous constatez une utilisation inattendue de cet identifiant après sa suppression, cela signifie que quelqu'un pourrait en abuser.
Les longues fenêtres de cohérence éventuelle constituent un mauvais choix de conception pour la révocation des identifiants. Tant que Google n'aura pas remédié à cela, considérez chaque suppression de clé comme une opération pouvant prendre jusqu'à 30 minutes et surveillez attentivement cette fenêtre pour détecter toute utilisation abusive.
