TL:DR;
- Ein Rechte-Management-Fehler bei Google erlaubte es öffentlich einsehbaren Google Cloud API-Keys, wie z.B. jenen für reCAPTCHA, unbefugt auf die Generative Language API zuzugreifen.
- Dies ermöglichte es Dritten, Deine öffentlichen Tokens zu missbrauchen und die Gemini API auf Deine Kosten abzufragen, bis hin zu Deinen Billing-Limits.
- Obwohl neu erstellte API-Keys nun strengere Rechte haben, solltest Du in der Google Cloud Platform prüfen, ob die „Generative Language API“ in Projekten mit öffentlichen Keys aktiviert ist.
- Darüber hinaus musst Du sicherstellen, dass API-Keys generell nur die absolut notwendigen Berechtigungen haben und dass weitreichendere Tokens niemals exponiert sind, da selbst interne KI-Agenten diese missbrauchen können.
- Überprüfe konsequent alle Zugriffsrechte Deiner Cloud- und AI-Tools, trenne Berechtigungen strikt und setze sowie kontrolliere Billing-Limits, um Risiken umfassend zu minimieren.
Hast Du auf Deiner Domain Google reCAPTCHA, Google-Maps-Integrationen oder ein anderes Tool im Einsatz, das über die Google Cloud Platform läuft?
Wenn ja, dann solltest Du dringend weiterlesen.
Hast Du oder vielleicht jemand aus Deinem Unternehmen in den letzten Monaten über dieselben Google-Cloud-Accounts Googles AI-Tools getestet oder setzt diese sogar regelmäßig ein?
Dann logg Dich jetzt in die Google Cloud Platform ein. Prüfe dort unter "APIs & Services" → "Enabled APIs & Services", ob die "Generative Language API" aktiviert ist. Und zwar für alle Projekte, über die reCAPTCHA und Ähnliches laufen (oder, wenn Du Dir nicht sicher bist, für alle Projekte).
Warum der Stress?
Für Deine reCAPTCHA-Integration, die Du vor Jahren einmal eingerichtet hast, steht der API-Key potenziell im Klartext im reCAPTCHA-Script, sodass jeder User mit ein paar Klicks in den Entwicklertools darauf zugreifen kann.
So stand es zumindest in der Dokumentation. Für klassische Google-Cloud-Services ist es kein Sicherheitsproblem, dass der API-Key öffentlich einsehbar ist, da die Nutzung an die Domain geknüpft ist und somit niemand außerhalb der Domain etwas damit anfangen kann. Die API-Keys sind ursprünglich kein Sicherheits-, sondern ein Abrechnungstool.
Jetzt gab es jedoch ein Rechte-Management-Update-Upsi bei Google: Wenn in einem Projekt die "Generative Language API" aktiviert wird, dürfen per Default alle API-Tokens des Projekts darauf zugreifen… also beispielsweise auch die öffentlich einsehbaren API-Keys eines reCAPTCHA.
Wenn Deinen Nutzerinnen und Nutzern die eigenen Tokens ausgehen, müssen sie sich also keine Geschichte aus den Fingern saugen, warum Dein KI-Chatbot ihre Programmierprobleme lösen soll. Sie können sich einfach Deinen Token schnappen und die Gemini API direkt abfragen … auf Deine Kosten, bis zu den Billing-Limits, die Du hoffentlich gesetzt hast.
Eine bessere, ausführlichere Erklärung findest Du bei trufflesecurity, die Google diesen Bug gemeldet haben.
Rechtemanagement muss kontrolliert und deterministisch sein
Neu angelegte API-Keys haben übrigens inzwischen per Default strengere Rechte. Wenn Du Deine GCP-API-Keys geprüft hast, besteht aktuell keine akute Sicherheitslücke mehr.
Trotzdem solltest Du mit den API-Keys vorsichtig umgehen und sicherstellen, dass die öffentlich einsehbaren API-Keys wirklich nur das dürfen, was sie auch brauchen, und dass API-Keys mit weitreichenderen Rechten nirgends auffindbar sind. Gleiches gilt auch für andere Tokens, Auth-Credentials, Passkeys und so weiter und nicht nur für die Google Cloud, sondern auch für AWS, Microsoft, OpenAI, Anthropic und weitere.
Und bei "nirgends auffindbar" meine ich nicht nur, dass sie irgendwo öffentlich im Internet landen könnten. In Zeiten von KI-Agenten kann ein API-Key mit den falschen Rechten an der falschen Stelle fatale Folgen haben, auch ohne jemals öffentlich gewesen zu sein.
Sicherheitsmechanismen von Coding-Agenten wie Claude, Cursor und Co. funktionieren nicht vollständig deterministisch, sondern auf Basis von Prompts. Daher können diese Agenten sie auch einfach ignorieren.
Ein Worst-Case-Beispiel liefert das Startup PocketOS: Ein Coding-Bot hat dort die komplette Produktionsdatenbank inklusive Backups gelöscht. Und zwar mit einem Token, den er für die aktuelle Aufgabe gar nicht hätte haben dürfen.
Im Vergleich dazu wäre für die meisten Firmen eine unerwartete Token-Rechnung in Höhe der maximalen Billing-Limits (und der damit verbundene Ausfall der Services, die eigentlich über eine GCP-API laufen) vermutlich das kleinere Übel.
Aber Du willst vermutlich weder das kleinere noch das größere Übel. In beiden Fällen ist die Schadenshöhe unangenehm und die Eintrittswahrscheinlichkeit höher, als Dir lieb ist. Wenn man das grob überschlägt, ergibt sich bei der klassischen Risiko-Rechnung:
Risiko = Schadenshöhe × Eintrittswahrscheinlichkeit
dass Du dieses Risiko minimieren solltest. Nimm Dir das also zum Anlass, die Zugriffsrechte für Deine Cloud- und AI-Tools und andere kritische Systeme zu überprüfen, die Berechtigungen sauber zu trennen und einzudampfen und die dazugehörigen Billing-Limits zu prüfen.