tl;dr: Wenn man einen Google-API-Schlüssel löscht, wird angezeigt, dass er sofort gelöscht wird. Unsere Tests ergaben jedoch eine Verzögerung von ca. 23 Minuten. Während dieses Zeitfensters behält ein Angreifer, der über einen durchgesickerten Schlüssel verfügt, Zugriff auf Ihre Daten und die aktivierten APIs (einschließlich Gemini). Sie haben keine Möglichkeit, den Schlüssel schneller zu widerrufen oder zu überprüfen, wann er nicht mehr funktioniert. Google hat unseren Bericht mit dem Vermerk „Wird nicht behoben“ abgeschlossen.
Wenn Sie einen API-Schlüssel löschen, gehen Sie davon aus, dass der Zugriff sofort beendet wird.
Google-API-Schlüssel funktionieren nicht auf diese Weise. Die Sperrung wird schrittweise in der gesamten Google-Infrastruktur übernommen. Einige Server lehnen den Schlüssel innerhalb von Sekunden ab, andere akzeptieren ihn noch 23 Minuten lang.
Ein Angreifer, der im Besitz Ihres gelöschten Schlüssels ist, kann so lange Anfragen senden, bis eine davon einen Server erreicht, der noch nicht auf den aktuellen Stand gebracht wurde. Wenn Gemini für das Projekt aktiviert ist, kann er von Ihnen hochgeladene Dateien auslesen und zwischengespeicherte Unterhaltungen abgreifen.
Die GCP-Konsole zeigt den Schlüssel nicht an und gibt auch keinen Hinweis darauf, dass der Schlüssel noch gültig ist. Sie verlassen sich darauf, dass die Infrastruktur von Google die Daten irgendwann nachholt.
Die Authentifizierung sollte nicht nur „eventually consistent“ sein
Viele Dienste Cloud Google Cloud sind von Grund auf auf „eventually consistent“ ausgelegt. Bei diesem Modell werden Aktualisierungen nicht auf einmal, sondern schrittweise auf alle Server übertragen. Dieser Kompromiss ermöglicht es Google, global zu skalieren und gleichzeitig schnell zu bleiben, und bei den meisten Diensten ist die Verzögerung nicht wahrnehmbar. Bei der Authentifizierung lässt sich dieser Kompromiss jedoch schwerer rechtfertigen.
Verzögerungen beim Entzug von Zugangsdaten können ausgenutzt werden. Vor einigen Monaten deckte Eduard Agavriloae eine Verzögerung von vier Sekunden auf, die es ermöglichte, mit gelöschten AWS-Zugriffsschlüsseln neue Zugangsdaten zu erstellen. Vier Sekunden reichten aus, um auf AWS erhebliche Auswirkungen zu haben.
Angesichts der jüngsten Aufmerksamkeit, die den für den Zugriff auf Gemini verwendeten Google-API-Schlüsseln zuteil wurde, haben wir uns daran gemacht, zu ermitteln, wie lange das Zeitfenster für die Sperrung von Google-API-Schlüsseln offen bleibt.
Was ist eine Widerrufsfrist?
Das Sperrfenster ist der Zeitraum zwischen dem Löschen eines Schlüssels und der letzten erfolgreichen Authentifizierung.
Wenn dieses Zeitfenster nur wenige Mikrosekunden beträgt, entspricht das Verhalten den Erwartungen der Nutzer. Ist es länger, verschafft jede zusätzliche Sekunde Angreifern mehr Zeit, einen gestohlenen Schlüssel zu missbrauchen.
Ermittlung des Widerrufszeitraums
Um das Zeitfenster für die Sperrung von Google-API-Schlüsseln zu ermitteln, haben wir über zwei Tage hinweg 10 Tests durchgeführt.
Bei jedem Test haben wir einen API-Schlüssel erstellt, diesen gelöscht und 3–5 authentifizierte Anfragen pro Sekunde gesendet, bis mehrere Minuten lang keine gültige Antwort mehr zurückkam.
Wir haben diese Rate gewählt, da wir keinen Einfluss darauf haben, wie Google unsere Anfragen an verschiedene Authentifizierungsserver weltweit weiterleitet. Das Volumen war so ausgelegt, dass pro Testdurchlauf möglichst viele dieser Server abgedeckt werden, ohne dabei die Infrastruktur von Google zu überlasten. Wir können nicht sagen, ob eine höhere Anfragerate das beobachtete Zeitfenster verlängern würde. Ein Angreifer hat keinen Grund, die Rate so zu drosseln wie wir, daher ist zu beachten, dass unsere Zahlen möglicherweise nicht den schlimmsten Fall widerspiegeln.
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
In zehn Tests betrug das längste Zeitfenster fast 23 Minuten! Das ist eine unglaublich lange Zeitspanne, in der ein gelöschter Schlüssel noch erfolgreich authentifiziert werden kann.
Das kürzeste Zeitfenster betrug fast 8 Minuten, der Median lag bei etwa 16 Minuten. Über alle Versuche hinweg war die Erfolgsquote äußerst unvorhersehbar: Eine Minute nach der Löschung waren in einem Versuch 79 % der Anfragen erfolgreich, während es in einem anderen Versuch nur 5 % waren.
Ein Angreifer, der im Besitz eines gestohlenen Schlüssels ist, sieht weder einen sauberen Abbruch noch einen vorhersehbaren Leistungsabfall. Der Zugriff funktioniert weiterhin, wenn auch unregelmäßig, bis er schließlich ganz ausfällt.
Verfolgung eines einzelnen Versuchs in der GCP-Konsole
Um die Inkonsistenz in der Infrastruktur von Google zu veranschaulichen, haben wir einen unserer Tests mithilfe des Diagramms „Traffic by Credential“ in GCP überwacht. Die untere (blaue) Linie zeigt erfolgreiche Authentifizierungen an und spiegelt die Dauer des Sperrfensters wider.
Wir hatten nicht mit weiteren Daten gerechnet, doch dann erschien eine zweite Linie. Die obere (grüne) Linie stellt abgelehnte Anfragen dar und ist mit apikey:UNKNOWN. Wir waren (fälschlicherweise) davon ausgegangen, dass ungültige Anfragen einfach verworfen würden, ohne dass sie einem Projekt zugeordnet würden. Stattdessen berücksichtigt GCP sie in dieser Grafik.
Um das Geheimnisvolle besser zu verstehen apikey:UNKNOWN Wert haben wir versucht, uns mit einem vor einigen Tagen gelöschten API-Schlüssel zu authentifizieren. Überraschenderweise tauchten diese Anfragen im selben Diagramm auf, gebündelt in derselben apikey:UNKNOWN Gruppe.
Wir gehen davon aus, dass Google die Projektzuordnung auch nach einer Löschung des Schlüssels beibehält, für den Fall, dass Nutzer die Anmeldedaten wiederherstellen möchten.
Für IR-Teams, die einen Fall von durchgesickerten Zugangsdaten untersuchen, ist die apikey:UNKNOWN Dieser Wert kann verwirrend sein. Alle Anfragen, die mit einem gelöschten Google-API-Schlüssel gestellt werden, werden in derselben Kategorie „UNKNOWN“ zusammengefasst, sodass schwer zu erkennen ist, welche Anfragen sich auf bestimmte Anmeldedaten beziehen. Eine Anfrage in diesem Bereich könnte bedeuten, dass ein Angreifer weiterhin versucht, sich mit dem gelöschten Schlüssel zu authentifizieren, oder es könnte sich um einen legitimen Dienst handeln, der auf einem nicht damit in Zusammenhang stehenden, veralteten Schlüssel läuft.
Wenn Sie sich innerhalb des 23-minütigen Widerrufszeitraums befinden, suchen Sie nach gültigen Authentifizierungen, die den offengelegten Schlüssel verwenden. Liegt dieser Zeitraum bereits hinter Ihnen, erscheint das Risiko äußerst gering.
Regionale Unterschiede in der Konsistenz
Wir haben das erste Experiment von einer privaten IP-Adresse an der Ostküste der USA aus durchgeführt. Wir gingen davon aus, dass ein ähnliches Experiment, das über virtuelle Maschinen in verschiedenen GCP-Regionen durchgeführt wird, möglicherweise weitere Unstimmigkeiten aufdecken könnte.
Wir haben in drei Regionen eine virtuelle Maschine eingerichtet: us-east1, Europa-West1, und Südostasien1. Anschließend führten wir fünf Tests durch. Bei jedem Test löschten wir einen einzelnen API-Schlüssel und sendeten parallel Anfragen von jeder der drei VMs.
Zwei Dinge fielen besonders auf. Erstens: Unmittelbar nach dem Löschen eines Schlüssels wiesen VMs in verschiedenen Regionen sehr unterschiedliche Erfolgsraten bei der Authentifizierung auf. Die folgende Tabelle zeigt den prozentualen Anteil gültiger Anfragen in der ersten Minute nach Region.
Schau dir Versuch 1 an: us-east1 82%, Europa-West1 60%, Südostasien1 32 %. VMs, die weiter von den USA entfernt waren, haben die Löschung schneller umgesetzt, was genau das Gegenteil dessen ist, was man erwarten würde. Von außen lässt sich nicht genau sagen, warum das so ist. Das Routing von Anfragen bei Google ist komplexer als die einfache Gleichung „VM-Region entspricht Server-Region“, und eine VM in Singapur kommuniziert nicht unbedingt mit Servern in Singapur. Das Muster war jedoch in allen Versuchen konsistent, was darauf hindeutet, dass regionale Infrastruktur, Caching oder Routing-Affinitäten für diesen Unterschied verantwortlich sind.
Zweitens war der regionale Unterschied nicht nur in der ersten Minute zu beobachten. Über das gesamte Zeitfenster hinweg Südostasien1 wies eine mittlere Erfolgsquote bei der Authentifizierung von Anfragen von 22 % auf, während us-east1 und Europa-West1 Beide lagen bei etwa 49 %. Asien blieb von Minute zu Minute schwächer, nicht nur zu Beginn.
Was auch immer diese Unterschiede verursacht, der Standort des Servers bestimmt eindeutig, wie sich ein gelöschter Schlüssel nach der Löschung verhält.
Andere Google-Anmeldedaten
Bei allen unseren Tests wurden Schlüssel verwendet, die Zugriff auf Gemini gewähren, doch wir haben dasselbe Verhalten auch bei Schlüsseln beobachtet, die auf andere GCP-APIs wie BigQuery und Maps beschränkt sind. Die Verzögerung hängt vom Typ der Anmeldedaten ab und nicht davon, welche APIs im Projekt aktiviert sind.
Der Vollständigkeit halber haben wir zwei weitere Arten von Google-Anmeldedaten getestet:
- Neue Gemini-API-Schlüssel (mit dem Präfix „AQ.“). Die Löschung wird innerhalb von ca. 1 Minute übernommen.
- Schlüssel für Google-Dienstkonten. Die Löschung wird innerhalb von ca. 5 Sekunden übernommen.
Beide laufen im Google-Maßstab, und beide werden deutlich schneller gesperrt als die 23 Minuten, die wir bei Google-API-Schlüsseln gemessen haben.
Weitergabe an Google
Wir haben dies an Google gemeldet. Google hat den Bericht mit dem Vermerk „Wird nicht behoben“ abgeschlossen. Nach unserem Verständnis vertritt das Team die Auffassung, dass die Übertragungsverzögerung eine bekannte Eigenschaft des Systems und kein Sicherheitsproblem ist.
Zwar dokumentiert Google öffentlich, dass seine IAM-API „eventually consistent“ ist, doch wird dieses Verhalten für Google-API-Schlüssel nicht ausdrücklich beschrieben.
[Bildunterschrift: Screenshot von der Dokumentationsseite zur IAM-API von Google.]
Enttäuschte Erwartungen der Nutzer
Verteilte Systeme in der Größenordnung von Google sind eine Herausforderung, und dies ist keine Kritik am GCP-IAM-Team. Doch ein Widerrufszeitfenster von 23 Minuten steht im grundlegenden Widerspruch zu dem, was Nutzer von einem Löschbutton erwarten. Die Diskrepanz zwischen dieser Erwartung und Googles Vorgehensweise verdeutlicht vier Probleme:
1. Die Benutzeroberfläche ist äußerst 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 Nutzer hat keine Möglichkeit zu erfahren, ob der Schlüssel noch aktiv ist, keine Möglichkeit, die Sperrung zu beschleunigen, und keine Möglichkeit, zu überprüfen, wann er endgültig nicht mehr funktioniert.
2. Google hat eine schnellere Sperrfunktion für andere Arten von Zugangsdaten entwickelt.
Die Sperrung von Anmeldedaten für Dienstkonten wird innerhalb von etwa 5 Sekunden wirksam. Das neuere API-Schlüsselformat von Gemini wird innerhalb von etwa einer Minute wirksam. Beide laufen im Google-Maßstab. Beides deutet darauf hin, dass dies auch für Google-API-Schlüssel technisch machbar ist.
3. Lange Konsistenzfenster sind nicht mit der Authentifizierung vereinbar.
Wenn man eine Anmeldeinformation löscht, geht man davon aus, dass diese damit ungültig ist. Selbst eine Verzögerung von nur wenigen Sekunden kann entscheidend sein, wie Eduards AWS-Untersuchung im letzten Jahr gezeigt hat.
4. Lange Sperrfristen beeinträchtigen die Just-in-Time-Generierung von Zugangsdaten.
Ein Dienstanbieter, der Google-API-Schlüssel dynamisch generieren möchte, muss nach einer Sperrung eine Wartezeit von 23 Minuten einkalkulieren, bevor der Schlüssel garantiert ungültig ist. Dies ist mit der JIT Funktionsweise JIT unvereinbar.
Arbeiten rund um das Fenster
Bis Google eine schnellere Sperrung einführt, liegt es in der Verantwortung der Nutzer, diese Lücke zu schließen. Zwei Dinge helfen dabei.
1. Gehen Sie davon aus, dass das Löschen eines Schlüssels etwa 30 Minuten dauert und nicht sofort erfolgt.
Wenn Sie auf einen durchgesickerten Google-API-Schlüssel reagieren, gehen Sie davon aus, dass der Schlüssel nach dem Klicken auf „Löschen“ noch 30 Minuten lang aktiv ist. Das verschafft Ihnen einen kleinen Puffer über die von uns beobachteten maximalen 23 Minuten hinaus. Planen Sie den weiteren Verlauf Ihrer Reaktion auf den Vorfall entsprechend diesem Zeitfenster.
2. Beobachten Sie die Nutzung während des Zeitfensters.
Überprüfen Sie unter „Aktivierte APIs und Dienste“ in der GCP-Konsole die API-Anfragen nach Anmeldeinformationen. Wenn Sie nach dem Löschen unerwartete Zugriffe über diese Anmeldeinformationen feststellen, könnte jemand diese aktiv missbrauchen.
Große Zeitfenster für die eventuelle Konsistenz sind bei der Sperrung von Zugangsdaten die falsche Designentscheidung. Solange Google daran nichts ändert, sollten Sie jede Schlüssel-Löschung als einen Vorgang von 30 Minuten betrachten und das Zeitfenster auf Missbrauch überwachen.
