Google mit KI hacken und 700 Millionen Won verdienen

• Fall eines Sicherheitsforschers, der Google-APIs mithilfe von KI dazu brachte, sie automatisch ununterbrochen anzustochern, und so innerhalb von 3 Monaten 500.000 US-Dollar an Bug-Bounty-Einnahmen erzielte
• Durch die Kombination von API-Schlüsseln, die aus mehr als 60.000 Android-Apps gesammelt wurden, mit Googles API-Spezifikationen (discovery document) wurden mehr als 1.500 APIs als Testziele erfasst, darunter auch solche, die extern kaum bekannt sind
• Einem auf Claude basierenden KI-System wurden API-Testwerkzeuge angebunden, sodass es wie ein Mensch Anfragen senden und Zugriffskontrollschwachstellen mit fehlender Berechtigungsprüfung automatisch finden konnte
• Zahlreiche schwerwiegende Schwachstellen entdeckt, darunter Übernahme von Google-Voice-Konten, Lecks privater YouTube-Videos, Offenlegung von Widevine-DRM-Schlüsseln und Nachverfolgung der Identität von Besitzern von Nest-Geräten
• Die meisten Funde beruhten nicht auf ausgefeilten Angriffen, sondern auf sich wiederholenden Grundfehlern wie fehlenden Berechtigungsprüfungen, nicht authentifizierten APIs und Testumgebungen, die echte Daten unverändert offenlegten

---

Ausgangspunkt der Forschung

• Im Oktober 2025 wurde die Forschung zu Google durch eine Einladung zu bugSWAT Mexico erneut intensiviert; besonders interessant war, dass sich dabei teilweise Googles Quellcode einsehen ließ
• Während im vergangenen Jahr kleinere Projekte mit Claude entstanden, wuchs die Einschätzung, dass sich Google-APIs mit KI in großem Maßstab automatisiert testen lassen
• Der zentrale Einstiegspunkt war das discovery document — im Grunde Googles Version einer Swagger-Dokumentation, die alle Endpunkte, Parameter und Methoden maschinenlesbar beschreibt
  • Manche sind öffentlich, etwa die YouTube Data API, andere existieren auch für interne APIs wie die Internal People API
  • Einige waren direkt zugänglich, die meisten erforderten jedoch einen gültigen API-Schlüssel

API-Schlüssel sammeln

• Ein in einem Dienst gefundener Schlüssel war oft auch für mehrere andere APIs desselben GCP-Projekts aktiviert, sodass mit mehr gesammelten Schlüsseln auch die Reichweite zugänglicher APIs wuchs
• Die Schlüsselsammlung erfolgte gemeinsam mit dem Freund Michael
  • 61.200 Android-APKs heruntergeladen, darunter alle Versionen aller Google-Apps, entpackt und nach API-Schlüsseln durchsucht
  • Mit einer Erweiterung auf Basis der Chrome Debugger API den Datenverkehr abgefangen und beim Besuch von mehr als 2.800 bekannten Google-Webdomains Schlüssel aus Live-Anfragen gesammelt
  • Parallel dazu wurden Google-iOS-Apps (IPA) entschlüsselt und verfügbare Google-Binärdateien analysiert

• Nur Google-Schlüssel herausfiltern

  • Um den VRP-Umfang einzuhalten, wurden mit der Cloud Marketplace API Projektinformationen zu den Schlüsseln abgefragt und Nicht-Google-Schlüssel entfernt
  • Nutzt man einen Schlüssel gegen eine API ohne Berechtigung, verrät die Fehlermeldung die Projektnummer (z. B. "...in project 244648151629...")
  • Mit dieser Nummer zeigt das Feld company die Eigentümer-Domain des Projekts an; alles außerhalb von google.com sowie übernommener Firmen wie nest.com, fitbit.com oder wing.com wurde verworfen

Lebende Google-API-Domains finden

• Kandidatendomains wurden aus von der Erweiterung protokollierten Domains, per Schlüsselwort generierten Brute-Force-Kandidaten und Certificate-Transparency-Logs zusammengesetzt
• An jede Domain wurden Anfragen geschickt; war der Server-Header einer von ESF, GSE oder scaffolding on HTTPServer2, wurde sie als lebende gültige Google-API eingestuft

Selbst versteckte Spezifikationen abgreifen

• Im Juli 2025 entfernte Google bei den meisten APIs den Pfad /$discovery/rest, einige ließen sich aber weiter umgehen

• Über Visibility Labels versteckte Endpunkte

  • Bei bestimmten Projekten waren Visibility Labels aktiv, sodass sich versteckte Endpunkte nur mit dem Parameter labels aufrufen ließen
  • Ohne Label war die Spezifikation der Service Management API 253 KB groß, mit ?labels=GOOGLE_INTERNAL wuchs sie auf 329 KB und legte große Mengen versteckter Dokumentation offen
  • Da jeweils nur ein Label auf einmal abgefragt werden konnte, war ein enormes Anfragevolumen nötig, um alle Kombinationen aus Labels, Schlüsseln und APIs zu testen
• Auf diese Weise wurden Spezifikationen von mehr als 1.500 APIs gesammelt und zusammen mit älteren Forschungsunterlagen für automatisierte KI-Tests vorbereitet

Authentifizierungsprobleme lösen

• API-Schlüssel lösten das Problem der „Berechtigung“, doch viele Endpunkte verlangten zusätzlich eine Authentifizierung, also die Prüfung, wer der Aufrufer ist
• Bearer-Token sind an ein GCP-Projekt gebunden; kombiniert man sie mit einem API-Schlüssel, entsteht ein Fehler wegen „verschiedener Projekte“, ein bekannter Umgehungsweg existierte nicht

• First Party Authentication (FPA)

  • Viele APIs unterstützten Googles proprietäres Authentifizierungssystem FPA, das zusammen mit API-Schlüsseln funktioniert
  • Webanfragen enthalten ein Session-Cookie sowie einen daraus berechneten Authorization-Wert und werden an Hosts unter *.clients6.google.com gesendet
  • Einige APIs wie drivefrontend-pa verlangen vollständigere FPA-v2-Header, in deren Hash auch Nutzerkennungen wie die E-Mail einfließen
  • Michael fand eine Sourcemap, die Google zeitweise versehentlich offengelegt hatte, und gewann daraus den Code zur Erzeugung von FPA-v2-Headern aus der internen Bibliothek gapix

• Tokenstruktur und Gaia-ID

  • Das Tokenformat lautet <timestamp>_<hash>_<identifier key>; der SHA1-Input ist „email:gaiaId timestamp sessionCookie origin“
  • Es gibt nur drei Identifier-Keys: e (E-Mail), u (verschleierte Gaia-ID) und a (Workspace-Domain); andere Buchstaben ignoriert das Backend
  • Gaia steht für „Google Accounts and ID Administration“; jedes Konto besitzt eine fortlaufende nicht verschleierte Gaia-ID (z. B. 131337133377) und zusätzlich eine lange verschleierte ID

• Origin-Allowlist und Schlüsselbeschränkungen

  • Viele APIs haben eine Liste zulässiger Origin-Werte; bei nicht erlaubter Origin kommt der irreführende Fehler SESSION_COOKIE_INVALID, der leicht wie ein Cookie-Problem wirkt
  • Schlüssel haben vier Einschränkungstypen: Server, Browser, Android und iOS; Browser verlangt Referer, iOS X-Ios-Bundle-Identifier, Android X-Android-Package plus passendem Zertifikats-Fingerprint
  • Diese Werte wurden beim Schlüsselsammeln mitgespeichert und in dieselbe Brute-Force-Pipeline integriert
  • Für *.corp.google.com gab es keine Origin-Beschränkung; solche APIs waren daher wahrscheinlich interne APIs ohne beabsichtigte öffentliche Nutzung und entsprechend fehleranfällig — ein Fall brachte 9.000 US-Dollar für eine Zugriffskontrollschwachstelle

Ablaufkarte der Anfrage und eigenes Testwerkzeug

• Es wurde ein Programm gebaut, das klassifiziert, auf welcher Stufe eine Anfrage abgewiesen wird — Methodenauflösung, Schlüsseligkeit, Schlüsselbeschränkung, Authentifizierung, Origin-Prüfung, Labels usw. — und so eine Zuordnung, welcher Schlüssel bei welcher API funktioniert, erstellt
• Googles API Explorer unterstützt nur öffentliche APIs und war für diese Zwecke nicht nutzbar; deshalb wurde in etwa einer Woche ein eigener API Explorer gebaut, der bis FPA v2 unterstützt
  • Die Spezifikationen werden clientseitig geparst, gültige Request-/Response-JSONs automatisch erzeugt und eine UI für schnelles Testen beliebiger Payloads bereitgestellt
  • Der im Demo gezeigte Endpunkt leckte assignedTams (Technical Account Managers) über einen Zugriffskontrollfehler und brachte 6.000 US-Dollar ein

Aufbau der automatisierten KI-Tests

• Ziel war, dass die KI grundlegende Zugriffskontrollprobleme automatisch findet und Menschen diese anschließend zu schwerwiegenderen Schwachstellen ausbauen
• Der JSON-Parsing-Code des Frontends wurde der KI über MCP-Tools angebunden, damit sie APIs wie ein Mensch testen konnte

• Gründlicher und leiser

  • Anfangs probierte die KI nur ein paar Mal und beendete dann frühzeitig; durch eine Ralph-Wiggum-Schleife musste nun jeder Endpunkt mindestens einmal getestet werden, bevor der Lauf enden durfte
  • Endpunkte wurden zunächst in logische Gruppen eingeteilt, gruppenweise getestet und Funde früherer Gruppen an spätere weitergegeben
  • Die Eingabe von probe_api wurde auf endpoint, path und body vereinfacht; die komplexe FPA-Authentifizierung erledigte das Backend, sodass die KI sich auf Payloads konzentrieren konnte
  • Da Antworten je nach Schlüssel verschieden ausfallen konnten, wurde dieselbe Anfrage automatisch mit allen Schlüsseln gesendet und identische Antworten per Hash gruppiert
  • Verwirrende Fehlermeldungen wie „Method not found“ wurden in MISSING_REQUIRED_VISIBILITY_LABEL u. Ä. übersetzt, um die KI nicht fehlzuleiten

• Rauschen und Verifikationsprobleme beheben

  • Zu Beginn gingen echte Bugs in 90 % Rauschen unter; die beiden Kernprobleme waren schwierige Verifikation und zu viele Fehlalarme
  • In Berichte wurde die tatsächliche Anfrage als operation ID aufgenommen, damit sie sich im Frontend per „Play“ reproduzieren ließ und manipulationssichere Belege vorlagen
  • Über mehr als einen Monat wurde der System-Prompt verfeinert und das Meldekriterium präzisiert — gemeldet wurden nur Zugriff auf Daten anderer Nutzer oder 2xx-Antworten dort, wo 4xx zu erwarten wären; bloße Existenzaufzählung galt nicht als Schwachstelle
  • Danach fand die KI Bugs in großer Zahl mit mehr als 50 % Genauigkeit; die einzige echte Begrenzung war die Zahl verfügbarer API-Schlüssel

Wichtige gefundene Schwachstellen

• In weniger als drei Monaten wurden Bugs im Wert von 500.000 US-Dollar gefunden; unten einige repräsentative, bereits behobene Fälle

• Übernahme von Google-Voice-Konten

  • In gfibervoice-pa fehlte jede Zugriffskontrolle; mit einer einzigen curl-Zeile ohne jede Authentifizierung ließ sich die gesamte PII eines Opfers auslesen, wenn man nur dessen nicht verschleierte Gaia-ID kannte, einschließlich Telefonnummern und Benachrichtigungsadressen
  • In der Antwort war sogar die Wiederherstellungs-Telefonnummer des Google-Kontos des Opfers sichtbar (nur unter bestimmten Bedingungen, genaue Bedingungen von Google nicht veröffentlicht)
  • Es existierte außerdem ein Endpunkt, der Voice-Nummern zwangsweise beliebigen Konten zuweisen konnte; trotz 500-Fehler wurde die Nummer tatsächlich hinzugefügt, und es wurde auch ein Endpunkt mit möglichem SIM-Swap-Potenzial entdeckt
  • Nach Einstufung als P0/S0 innerhalb weniger Stunden gepatcht, 20.000 US-Dollar Prämie
  • Direkt nach dem Patch wurde außerdem die Offenlegung von nur fürs Intranet gedachten zhandlern wie /btz entdeckt; über /flagz ließ sich aus dem laufenden Dienst ein API-Schlüssel extrahieren

• Übernahme von AdExchange-Konten

  • Ein Endpunkt wurde gefunden, der per Einzelanfrage die gesamte Liste aller AdExchange-Konten ausgeben konnte
  • In Produktion blockierte Kontenendpunkte funktionierten in der Staging-Umgebung ohne Zugriffskontrolle, und diese Staging-Umgebung zeigte auf echte Produktionsdaten
  • Es war zudem möglich, sich selbst als ADMIN zu beliebigen Konten hinzuzufügen; für beide Meldungen zusammen gab es 30.000 US-Dollar

• eldar.corp.google.com

  • Die API von Eldar, einer nur für Googler bestimmten internen Site zur Verwaltung von Datenschutzbewertungen, war extern erreichbar; so konnten Nicht-Googler sensible Informationen wie interne Log-Zugriffsanfragen einsehen
  • Auch nach einer ersten Sperre war der Zugriff über andere Sandbox-Adressen weiter möglich; insgesamt 26.674 US-Dollar

• Leck privater YouTube-Videos

  • Da beim Video-Upload Asset-Namen im Format Auto generated asset - <video_id> erzeugt werden, konnten IDs privater Videos per Suche geleakt und die Videos angesehen werden
  • Mit einer Anfrage alle 30 Sekunden ließ sich ein Echtzeit-Feed privater Partner-Uploads aufbauen — eine reale Bedrohung, weil Unternehmen Produktankündigungsvideos oft vorab privat hochladen und dies für Insider-Wetten auf Prognosemärkten missbraucht werden könnte
  • 12.000 US-Dollar Prämie (hohe Berichtsqualität)

• Offenlegung von Widevine-DRM-Schlüsseln

  • Das Partnerportal-API von Widevine, dem weltweit größten von Disney, Netflix u. a. genutzten DRM-System, war öffentlich zugänglich
  • Die gesamte Organisationsliste ließ sich dumpen, PGP- und AES-Schlüssel bestimmter Organisationen abrufen und entschlüsseln, und man konnte sich selbst zu beliebigen Organisationen hinzufügen, um Geräteverwaltung zu übernehmen
  • 16.004,40 US-Dollar Prämie (hohe Berichtsqualität)

• plx.corp.google.com

  • Die zugrunde liegende DataHub-API der internen nur für Mitarbeiter gedachten Analyseplattform PLX war offengelegt, sodass sich Metadaten aktiver Mitarbeitertabellen abrufen ließen
  • In der Staging-API konnte man sich per setIamPolicy selbst als Dataset-Admin hinzufügen und dadurch vertrauliche YouTube-Daten dumpen, darunter Tabellen mit bis zu 2,1 PB
  • Innerhalb einer Stunde als P0/S0 anerkannt; beide Schwachstellen brachten jeweils 12.000 US-Dollar

Cross-Tenant-Schwachstellen im Translation Hub

• Im Produkt Translation Hub zur Verwaltung großskaliger Dokumentübersetzungen wurden mehrere Zugriffskontrollprobleme gefunden
• ListOperations funktionierte ohne OAuth-Token und leckte interne Dienstkontonamen, GCS-Bucket-Namen und interne Tabellennamen
• Mit dem Bearer-Token irgendeines Google-Kontos ließen sich Daten anderer Projekte abrufen, darunter E-Mail-Adressen von Übersetzern und vertrauliche Dateinamen laufender Aufträge
• Änderte man mit UpdateProjectConfig die Konfiguration des Opfers auf einen beliebigen GCS-Pfad, ließ sich über gemeinsam genutzte Dienstkonto-Berechtigungen ein privates GCS-Objekt als Base64 exfiltrieren
• Zusammen brachten die drei Bugs 36.500 US-Dollar

YouTube TV CMS

• In einer API für YouTube-CMS-Konten, mit der sich beliebige Videos striken, claimen oder monetarisieren lassen, prüfte der Campaign-Endpunkt überhaupt keine Beziehung zum Aufrufer
• GET /v1/campaigns dumpte ohne Scoping alle Campaigns im gesamten System; Ändern, Kopieren und Löschen war ebenfalls allein per ID möglich
• Als Nebeneffekt wurden sensible E-Mail-Adressen von CMS-Konten offengelegt; 24.000 US-Dollar Prämie (hohe Berichtsqualität)

Vertex AI Search for Commerce

• Die conversationalSearchCustomizationConfig des Produkts für Retail-Suche und Empfehlungen erlaubte ohne Zugriffskontrolle das Lesen und Ändern beliebiger Projekteinstellungen
• Beim Lesen wurden System-Prompts (Model Preamble) von Kunden sowie Klassifizierungsbeispiele mit internen Policy-Notizen offengelegt
• Beim Schreiben ließ sich ein Prompt-Injection-Payload in den System-Prompt der kundenorientierten Such-KI einschleusen; 30.000 US-Dollar Prämie

Cloud Console GraphQL

• Selbst interne, im Internet nicht veröffentlichte Dienste waren über Proxy-Oberflächen indirekt erreichbar; die Cloud Console (Codename Pantheon) proxyte gRPC-Backends per GraphQL

• Umgehung der Signaturprüfung

  • Jede Anfrage prüft normalerweise eine Query-Signatur (querySignature), was Manipulation erschwert; entdeckt wurde jedoch, dass nicht authentifizierte Queries in Staging die Signatur nicht prüfen
  • Per Introspection wurden 3.448 Schemas abgegriffen und auf GitHub archiviert; mit dem Konzept eines „query path“ wurde GraphQL in die bestehende KI-Fuzzing-Infrastruktur integriert

• App-Engine-Request-Logs

  • GetDashboardAppStats lieferte ohne IAM-Prüfung — sogar ohne nötige Authentifizierung — 24 Stunden App-Engine-Logs beliebiger Projekte zurück
  • Da in Anfrage-URLs Passwort-Reset-Links und Tokens enthalten sein konnten, gab es 18.000 US-Dollar und die Kennung CVE-2026-8934

• Vertex Assistant

  • Durch Analyse von 5 GB Frontend-JavaScript wurde die versteckte experimentelle Funktion Vertex Assistant identifiziert und per DevTools-Feature-Flag erzwungen aktiviert
  • Alle zugehörigen Queries funktionierten ohne Authentifizierung allein mit userId; mit Kenntnis der Ziel-E-Mail waren Sitzungslisten sowie vollständige Gesprächsverläufe einseh- und veränderbar, 30.000 US-Dollar Prämie

• Billing Credits der Maps Platform

  • ListBillingAccountCredits funktionierte ohne Berechtigungsprüfung und lieferte per Wildcard Kreditinformationen vieler Kunden
  • Von Google-Mitarbeitern bei Freigaben eingetragene Kunden-PII wurde unverändert im Feld justification offengelegt, 12.000 US-Dollar Prämie

Fazit und Lehren

• In drei Monaten wurden mit diesem Setup mehr als 500.000 US-Dollar an Bounties erzielt; das Veröffentlichte ist nur ein Teil davon
• Die meisten Google-Bugs erforderten keine ausgefeilten Exploits, sondern vor allem Ausdauer; dieselben gebrochenen Muster wiederholten sich überall — fehlende IAM-Checks, nicht authentifiziertes GraphQL, Debug-Endpunkte in Produktion, Sandboxes mit echten Daten
• Die Rolle der KI bestand nicht in Originalität, sondern darin, auf einer für Menschen zu großen Oberfläche offensichtliche Dinge ermüdungsfrei immer wieder zu überprüfen
• Zentrale Erkenntnisse
  • Das operation-id-Reproduktionssystem war der entscheidende Faktor für einen produktiven Workflow — ohne Ein-Klick-Bestätigung bleibt KI-Ausgabe wertloses Rauschen
  • Wenn discovery docs, GraphQL-SDL und Protos vorliegen, kann die KI sinnvoll ableiten, welche Eingaben sich testen lassen
  • Googles serverseitige Oberflächen sind stark standardisiert; wenn Infrastrukturbesonderheiten für die KI abstrahiert werden, kann sie sich stärker auf das eigentliche API-Testing konzentrieren

[j2sus91]

Das ist wirklich ein neuartiges Einkommensmodell des Vibe-Coding.