tl;dr Wenn Sie einen Google API-Schlüssel löschen, wird angegeben, dass er sofort gelöscht wird. Unsere Tests zeigen ~23 Minuten. Während dieses Zeitfensters behält ein Angreifer mit einem geleakten Schlüssel Zugriff auf Ihre Daten und aktivierte APIs (einschließlich Gemini). Sie haben keine Möglichkeit, ihn schneller zu widerrufen oder zu bestätigen, wann er nicht mehr funktioniert. Google hat unseren ursprünglichen Bericht als „wird nicht behoben“ geschlossen.
Update vom Freitag, 22. Mai 2026: Google hat unseren Bericht wieder geöffnet und behandelt dies als P0-Bug.
Wenn Sie einen API-Schlüssel löschen, erwarten Sie, dass der Zugriff sofort endet.
Google API-Schlüssel funktionieren nicht so. Der Widerruf verbreitet sich allmählich über die Google-Infrastruktur. Einige Server lehnen den Schlüssel innerhalb von Sekunden ab, andere akzeptieren ihn noch 23 Minuten lang.
Ein Angreifer, der Ihren gelöschten Schlüssel besitzt, kann weiterhin Anfragen senden, bis eine einen Server erreicht, der noch nicht aktualisiert wurde. Wenn Gemini im Projekt aktiviert ist, können sie von Ihnen hochgeladene Dateien auslesen und zwischengespeicherte Konversationen exfiltrieren.
Die GCP-Konsole zeigt den Schlüssel nicht an und teilt Ihnen nicht mit, dass der Schlüssel noch funktioniert. Sie vertrauen darauf, dass die Google-Infrastruktur irgendwann aufholt.
Authentifizierung sollte nicht eventual consistent sein
Viele Dienste von Google Cloud sind von Haus aus eventual consistent. Bei diesem Modell verbreiten sich Updates schrittweise über die Server, anstatt alle auf einmal. Dieser Kompromiss ermöglicht es Google, global zu skalieren und schnell zu bleiben, und bei den meisten Diensten ist die Verzögerung unsichtbar. Doch bei der Authentifizierung ist dieser Kompromiss schwerer zu rechtfertigen.
Verzögerungen beim Widerruf von Anmeldeinformationen sind ausnutzbar. Vor einigen Monaten enthüllte Eduard Agavriloae eine Verzögerung von 4 Sekunden, die es gelöschten AWS-Zugriffsschlüsseln ermöglichte, neue Anmeldeinformationen zu erstellen. Vier Sekunden waren auf AWS ausreichend, um relevant zu sein.
Angesichts der jüngsten Aufmerksamkeit für Google API-Schlüssel die für den Zugriff auf Gemini verwendet werden, haben wir uns vorgenommen zu messen, wie lange das Widerrufsfenster für Google API-Schlüssel offen bleibt.
Was ist ein Widerrufsfenster?
Das Widerrufsfenster ist die Zeitspanne zwischen dem Löschen eines Schlüssels und der letzten erfolgreichen Authentifizierung.
Wenn das Fenster nur wenige Mikrosekunden beträgt, entspricht das Verhalten den Erwartungen der Nutzer. Ist es länger, gibt jede zusätzliche Sekunde Angreifern mehr Zeit, einen gestohlenen Schlüssel zu missbrauchen.
Messung des Widerrufsfensters
Um das Widerrufsfenster für Google API-Schlüssel zu messen, führten wir über zwei Tage hinweg 10 Versuche durch.
In jedem Versuch erstellten wir einen API-Schlüssel, löschten ihn und sendeten 3-5 authentifizierte Anfragen pro Sekunde, bis mehrere Minuten lang keine gültige Antwort zurückkam.
Wir wählten diese Rate, da wir nicht kontrollieren können, wie Google unsere Anfragen an verschiedene Authentifizierungsserver weltweit weiterleitet. Das Volumen sollte pro Versuch so viele davon wie möglich durchlaufen, während die Infrastruktur von Google respektiert wurde. Wir können nicht sagen, ob eine höhere Anfragerate das beobachtete Fenster verlängern würde. Ein Angreifer hat keinen Grund, die Anfragen so zu drosseln, wie wir es taten, daher ist es wichtig zu beachten, dass unsere Zahlen möglicherweise nicht den Worst Case darstellen.
Der Vollständigkeit halber haben wir unsere Arbeit einige Wochen später stichprobenartig überprüft, um sicherzustellen, dass das beobachtete Verhalten nicht auf vorübergehende Netzwerkprobleme zurückzuführen war.
23 Minuten
Über zehn Versuche hinweg betrug das längste Fenster fast 23 Minuten! Das ist eine unglaublich lange Zeit für einen gelöschten Schlüssel, um sich immer noch erfolgreich zu authentifizieren.
Das kürzeste Fenster betrug fast 8 Minuten, und der Median lag bei etwa 16 Minuten. Über die Versuche hinweg war die Erfolgsrate sehr unvorhersehbar: Eine Minute nach der Löschung waren in einem Versuch 79 % der Anfragen erfolgreich, während es in einem anderen nur 5 % waren.
Ein Angreifer, der einen gestohlenen Schlüssel besitzt, erlebt keinen sauberen Abbruch oder einen vorhersehbaren Verfall. Der Zugriff funktioniert ungleichmäßig weiter, bis er schließlich einfach aufhört.
Verfolgung eines einzelnen Versuchs in der GCP-Konsole
Um die Inkonsistenz in Googles Infrastruktur zu veranschaulichen, haben wir einen unserer Versuche mithilfe des Diagramms „Traffic by Credential“ in GCP überwacht. Die untere (blaue) Linie zeigt erfolgreiche Authentifizierungen und spiegelt die Länge des Widerrufsfensters wider.
Wir hatten nicht erwartet, andere Daten zu sehen, aber eine zweite Linie erschien. Die obere (grüne) Linie zeigt abgelehnte Anfragen und ist beschriftet mit apikey:UNKNOWN. Wir hatten (fälschlicherweise) angenommen, dass ungültige Anfragen einfach ohne Projektzuordnung verworfen würden. Stattdessen nimmt GCP sie in dieses Diagramm auf.
Um das mysteriöse apikey:UNKNOWN Wert besser zu verstehen, haben wir versucht, uns mit einem Tage alten, gelöschten API-Schlüssel zu authentifizieren. Überraschenderweise tauchten diese Anfragen im selben Diagramm auf, gebündelt in derselben apikey:UNKNOWN Gruppe.
Unsere beste Vermutung ist, dass Google die Projektzuordnung auch nach dem Löschen eines Schlüssels beibehält, falls Nutzer sich entscheiden, das Credential wiederherzustellen.
Für IR-Teams, die eine kompromittierte Anmeldeinformation untersuchen, kann der apikey:UNKNOWN Wert verwirrend sein. Jede Anfrage, die mit einem gelöschten Google API-Schlüssel gestellt wird, wird in dieselbe UNKNOWN-Kategorie gebündelt, was es schwierig macht, zu erkennen, welche Anfragen sich auf eine bestimmte Anmeldeinformation beziehen. Eine Anfrage in diesem Bucket könnte bedeuten, dass ein Bedrohungsakteur immer noch versucht, sich mit dem gelöschten Schlüssel zu authentifizieren, oder es könnte ein legitimer Dienst sein, der mit einem nicht verwandten, veralteten Schlüssel läuft.
Befinden Sie sich innerhalb des 23-minütigen Widerrufsfensters, suchen Sie nach gültigen Authentifizierungen, die den kompromittierten Schlüssel verwenden. Liegen Sie außerhalb dieses Fensters, scheint das Risiko extrem gering zu sein.
Regionale Unterschiede in der Konsistenz
Wir führten das erste Experiment von einer privaten IP-Adresse an der Ostküste der USA aus durch. Wir vermuteten, dass ein ähnliches Experiment über VMs in verschiedenen GCP-Regionen zusätzliche Inkonsistenzen aufdecken könnte.
Wir haben eine VM in drei Regionen gestartet: us-east1, europe-west1, und asia-southeast1. Anschließend führten wir 5 Testläufe durch. Für jeden Testlauf löschten wir einen einzelnen API-Schlüssel und sendeten parallel Anfragen von jeder der drei VMs.
Zwei Dinge fielen auf. Erstens, unmittelbar nach dem Löschen eines Schlüssels zeigten VMs in verschiedenen Regionen sehr unterschiedliche Erfolgsraten bei der Authentifizierung. Die untenstehende Tabelle zeigt den Prozentsatz gültiger Anfragen in der ersten Minute nach Region.
Betrachten wir Testlauf 1: us-east1 82%, europe-west1 60%, asia-southeast1 32 %. VMs, die weiter von den USA entfernt waren, erkannten die Löschung schneller, was dem Gegenteil der Erwartungen entspricht. Von außen können wir nicht genau sagen, warum das so ist. Googles Anfragen-Routing ist komplexer als „VM-Region gleich Server-Region“, und eine VM in Singapur kommuniziert nicht unbedingt mit Servern in Singapur. Das Muster war jedoch über alle Testläufe hinweg konsistent, was auf regionale Infrastruktur, Caching oder Routing-Affinität als Ursache für den Unterschied hindeutet.
Zweitens war der regionale Unterschied nicht nur eine Sache der ersten Minute. Über das gesamte Fenster hinweg, asia-southeast1 hatte eine mittlere Erfolgsrate bei der Authentifizierung von Anfragen von 22 %, während us-east1 und europe-west1 beide bei etwa 49 % lagen. Asien blieb Minute für Minute niedriger, nicht nur am Anfang.
Was auch immer diese Unterschiede verursacht, der Standort des Servers prägt eindeutig, wie sich ein gelöschter Schlüssel nach der Löschung verhält.
Andere Google-Anmeldeinformationen
Unsere Testläufe verwendeten alle Schlüssel mit Zugriff auf Gemini, aber wir beobachteten dasselbe Verhalten bei Schlüsseln, die auf andere GCP-APIs wie BigQuery und Maps zugeschnitten waren. Die Verzögerung ist eine Eigenschaft des Anmeldeinformationstyps, nicht der im Projekt aktivierten APIs.
Der Vollständigkeit halber haben wir zwei weitere Google-Anmeldeinformationstypen getestet:
- Neue Gemini API-Schlüssel (AQ.-Präfix). Die Löschung wurde in ca. 1 Minute propagiert.
- Google Service Account-Schlüssel. Die Löschung wurde in ca. 5 Sekunden propagiert.
Beide laufen im Google-Maßstab und widerrufen beide wesentlich schneller als die 23 Minuten, die wir für Google API-Schlüssel gemessen haben.
Meldung an Google
Wir haben dies an Google gemeldet. Google hat den Bericht mit der Begründung „wird nicht behoben“ geschlossen. Die Position des Teams ist, soweit wir sie verstehen, dass die Propagationsverzögerung eine bekannte Eigenschaft des Systems und kein Sicherheitsproblem ist.
Obwohl Google öffentlich dokumentiert, dass ihre IAM API eventual consistent ist, dokumentieren sie dieses Verhalten nicht explizit für Google API-Schlüssel.
[Bildunterschrift: Screenshot von der Dokumentationsseite der Google IAM API.]
Gebrochene Benutzererwartungen
Verteilte Systeme in Googles Größenordnung sind komplex, und dies ist keine Kritik am GCP IAM-Team. Aber ein 23-minütiges Widerrufsfenster steht fundamental im Widerspruch zu dem, was Benutzer von einem Löschbutton erwarten. Die Diskrepanz zwischen dieser Erwartung und Googles Verhalten verdeutlicht vier Probleme:
1. Die Benutzeroberfläche ist extrem irreführend.
Wenn Sie den Schlüssel löschen, entfernt Google ihn aus Ihrer Ansicht und teilt Ihnen mit: „Nach dem Löschen kann er nicht mehr für API-Anfragen verwendet werden.“ Diese Aussage ist nachweislich falsch. Der Benutzer hat keine Möglichkeit zu wissen, ob der Schlüssel noch aktiv ist, keine Möglichkeit, den Widerruf zu beschleunigen, und keine Möglichkeit zu bestätigen, wann er vollständig aufgehört hat zu funktionieren.
2. Google hat für andere Anmeldeinformationstypen einen schnelleren Widerruf implementiert.
Der Widerruf von Service-Account-Anmeldeinformationen wird in etwa 5 Sekunden propagiert. Geminis neueres API-Schlüsselformat wird in etwa einer Minute propagiert. Beide laufen im Google-Maßstab. Beide deuten darauf hin, dass dies auch für Google API-Schlüssel technisch lösbar ist.
3. Lange Konsistenzfenster sind nicht mit der Authentifizierung kompatibel.
Die Erwartung beim Löschen einer Anmeldeinformation ist, dass diese Anmeldeinformation ungültig ist. Selbst wenige Sekunden Verzögerung sind relevant, wie Eduards AWS-Forschung im letzten Jahr zeigte.
4. Lange Widerrufsfenster beeinträchtigen die Just-in-Time-Erstellung von Anmeldeinformationen.
Ein Dienstanbieter, der Google API-Schlüssel dynamisch erstellen möchte, muss nach dem Widerruf einen 23-minütigen Puffer einplanen, bevor der Schlüssel garantiert ungültig ist. Das ist inkompatibel mit der Funktionsweise von JIT.
Umgang mit dem Zeitfenster
Bis Google einen schnelleren Widerruf bereitstellt, liegt die Verantwortung für die Schließung dieser Lücke bei den Benutzern. Zwei Dinge helfen dabei.
1. Betrachten Sie das Löschen von Schlüsseln als einen 30-minütigen Vorgang, nicht als einen sofortigen.
Wenn Sie auf einen geleakten Google API-Schlüssel reagieren, gehen Sie davon aus, dass der Schlüssel 30 Minuten nach dem Klicken auf „Löschen“ noch aktiv ist. Das bietet einen gewissen Puffer über die von uns beobachteten maximal 23 Minuten hinaus. Planen Sie den Rest Ihrer Incident Response um dieses Zeitfenster herum.
2. Überwachen Sie die Nutzung während des Zeitfensters.
Überprüfen Sie unter „Enabled APIs and services“ in der GCP-Konsole die API-Anfragen nach Anmeldeinformationen. Wenn Sie nach dem Löschen unerwartete Nutzung dieser Anmeldeinformationen feststellen, könnte jemand diese aktiv ausnutzen.
Große eventual consistency-Fenster sind die falsche Designentscheidung für den Widerruf von Anmeldeinformationen. Bis Google dies ändert, behandeln Sie jede Schlüssel-Löschung als einen 30-minütigen Vorgang und überwachen Sie das Zeitfenster auf Missbrauch.
