Google zahlt 250.000 Dollar für einen Root in der Cloud. Das ist die neue Höchstprämie im Cloud Vulnerability Reward Program, kurz Cloud VRP, wie SecurityWeek berichtet.
Die Stufe gilt für Sicherheitslücken, die einem Angreifer vollständige administrative Kontrolle über beliebige Google-Cloud-Organisationen oder -Projekte verschaffen könnten.
Eine Cloud lässt sich als Hochhaus mit hunderten Wohnungen vorstellen. Jede Partei hat ihren eigenen Schlüssel, die Hausverwaltung hat einen Generalschlüssel. Die entscheidende Sicherheitsfrage lautet nicht, ob jemand eine Wohnungstür aufbekommt. Sie lautet, ob jemand den Generalschlüssel nachbauen kann, ohne je einen echten Schlüssel in der Hand gehabt zu haben. Für diesen Nachweis zahlt Google künftig sechsstellig.
Was die neue Stufe technisch verlangt
Die höchste Prämie ist laut Bericht für „high-impact architectural research“ gedacht, also für Forschung, die nicht an einem einzelnen Fehler hängt, sondern an einem Konstruktionsfehler. Ausgezahlt wird sie an Forschende, die nachweisen können, dass sie die Rolle „roles/owner“ oder eine vollständige IAM-Kontrolle über beliebige Google-Cloud-Organisationen oder -Projekte erlangen. IAM steht für Identity and Access Management, die Schicht, die festlegt, wer welche Ressource anfassen darf.
Die Ausschlusskriterien sind strenger, als man bei einer solchen Summe vermuten könnte. Der Angriffspfad darf nicht auf bereits vorhandenem Zugriff auf ein Projekt beruhen, nicht auf vorher kompromittierte Zugangsdaten und nicht auf Interaktion mit Nutzern oder Social Engineering. Wer einen gestohlenen Schlüssel weiterreicht, gewinnt nichts. Gesucht wird der Nachbau des Generalschlüssels aus dem Nichts.
Google will außerdem Berichte bewerten, die Remote Code Execution in Borg zeigen, der zugrundeliegenden Produktionsinfrastruktur des Konzerns, oder einen Root in der Produktion. Auch diese Fälle fallen unter die neue Stufe. Laut Programmbeschreibung wird die Prämie gezahlt, wenn die Analyse von Einstiegspunkt, Ausführungskontext und Angriffsfläche belegt, dass eine vollständige Übernahme eines fremden Mandanten oder Projekts tatsächlich möglich ist. Nicht die Behauptung zählt, sondern der Beweis.
Borg, Root und die Grenzen des Erlaubten
Der Verweis auf Borg zeigt, wie weit die Prämie reicht. Borg ist jene Ebene unter allen Google-Diensten, auf der die Arbeitsteilung zwischen Maschinen stattfindet. Code dort auszuführen bedeutet potenziell, die Verfügbarkeit von Diensten zu stören oder Daten zwischen Kunden zu verschieben, die strikt getrennt bleiben müssen. Diese Trennung, in der Fachsprache Tenant Isolation, ist das Fundament, auf dem das Geschäftsmodell jeder Cloud ruht.
Chris Betz, Sicherheitschef von Google Cloud, hat die Spielregeln deshalb deutlich formuliert. Sobald ein Forschender irgendeine Form von Ausführung in Borg erreiche, müssten alle weiteren Versuche sofort eingestellt werden. Eskalation, das Auslesen von Produktions-Zugangsdaten und laterale Bewegung seien nicht erlaubt und führten zum Ausschluss. Wer für das Aufzeigen einer Tür bezahlt wird, will nicht, dass der Finder durchs ganze Haus läuft.
Man kann das als Einschränkung lesen oder als das eigentliche Angebot. Eine Prämie dieser Größe ist nur sinnvoll, wenn beide Seiten wissen, wo der Prüfbereich endet. Bug-Bounty-Programme beruhen auf einer stillschweigenden Vereinbarung: Der Angreifer bekommt Geld statt Ärger, der Hersteller bekommt Wissen statt eines Vorfalls. Je höher die Summe, desto präziser muss diese Vereinbarung formuliert sein.
Der kryptografische Beweis statt des echten Angriffs
Michael Cote, bei Google Cloud für das Vulnerability Reward Program verantwortlich, hat den praktischen Kniff hinter der neuen Stufe erklärt. Hohe Anreize brauchten klare und sichere Regeln, sagt er, und man wolle unter keinen Umständen, dass Forschende ihre Exploits gegen echte Kundenprojekte testen. Stattdessen gibt es einen deterministischen Proof-of-Root-Mechanismus, der auf einem eigens dafür bestimmten Servicekonto beruht. Wer unbefugten Zugriff auf diese Identität erlangt, kann das kryptografisch belegen.
Ein Nachweis, der ohne Schaden an fremden Daten auskommt, verändert die Ökonomie der Fehlersuche. Forschende müssen nicht mehr abwägen, ob sie einen Schritt weitergehen dürfen, und der Anbieter muss nicht befürchten, dass eine Meldung aus einer laufenden Produktionsumgebung stammt. Der Beweis wird zum Artefakt, das sich weitergeben lässt, statt zu einer Erzählung über das, was theoretisch möglich gewesen wäre.
Für Betreiber einer Cloud-Umgebung ist daran eine zweite Lehre interessant. Wenn ein Anbieter seine eigene Vertrauenskette so sorgfältig prüfen lässt, verschiebt sich der Druck auf die Konfiguration darüber. Die meisten realen Vorfälle entstehen nicht durch Borg, sondern durch zu weit gefasste Rollen, vergessene Servicekonten und Schlüssel, die niemand mehr braucht. Das Hochhaus mag sicher gebaut sein, die Wohnungstür bleibt trotzdem offen, wenn der Schlüssel unter der Fußmatte liegt.
Warum KI die Suche verändert, aber nicht ersetzt
Betz beschreibt, worauf es bei dieser Klasse von Fehlern ankommt. Das Umgehen der Mandantentrennung und komplexe logische Fehler zwischen mehreren Diensten verlangten menschliche Kreativität, Intuition und rigorose Systemanalyse, kombiniert mit der Leistungsfähigkeit agentischer Systeme. Agentisch meint Werkzeuge, die nicht nur einen Vorschlag machen, sondern selbstständig mehrere Schritte ausführen, prüfen und Varianten durchspielen.
Cote wird mit einer Beobachtung zitiert, die nachdenklich macht. Forschende, die zum ersten Mal dabei sind, aber ihre eigene Intuition mit agentischen Werkzeugen verbinden, fänden im Durchschnitt interessantere Fehler als Anfänger vor zwei Jahren. Nicht das Wissen wächst schneller, sondern die Zahl der Versuche. Wer eine vage Vermutung hat, kann sie heute in Minuten hundertfach durchrechnen lassen.
Der Engpass bleibt derselbe. Wer Fehler auf Architekturebene finden will, muss verstehen, wie Dienste miteinander reden, wo Vertrauen weitergereicht wird und an welcher Stelle eine Annahme zu großzügig formuliert ist. Ein Werkzeug kann diese Annahme nicht hinterfragen, wenn niemand weiß, dass sie existiert. Cote sagt, für die neue Stufe müssten tiefe architektonische Intuition und KI zusammenkommen. Das eine ohne das andere reicht nicht.
Was das für Cloud-Sicherheit und Bug-Bounty-Programme bedeutet
Google erhöht nicht die Belohnung für aufgehebelte Wohnungstüren, sondern für den Nachweis, dass die Schließanlage selbst fehlerhaft ist. Das ist ein Signal darüber, wo der Konzern die teuren Probleme vermutet: nicht im einzelnen Fehler, sondern darin, wie mehrere Dienste zusammenspielen und dabei Vertrauen weitergeben. Dort entstehen Schwachstellen, die sich nicht mit einem Patch beheben lassen, weil sie in der Logik stecken.
Für die Bug-Bounty-Landschaft setzt die Summe einen Maßstab. 250.000 Dollar für einen einzigen Nachweis verschieben die Aufmerksamkeit weg von Massenabarbeitung und hin zu wenigen, sehr tiefen Untersuchungen. Gleichzeitig wächst mit der Automatisierung das Rauschen. Google hat in jüngerer Zeit andere Programme verengt, weil massenhaft automatisch erzeugte, unbrauchbare Meldungen eingingen. Ein hoher Preis für Spitzenfunde und strengere Filter für den Durchschnitt sind zwei Seiten derselben Bewegung.
Für Betreiber heißt das konkret zweierlei. Erstens lohnt sich der Blick in die eigenen IAM-Strukturen mehr als die Suche nach spektakulären Lücken, weil die Rolle „roles/owner“ in vielen Umgebungen deutlich häufiger vergeben wird, als die Arbeit erfordert. Zweitens zeigt das Beispiel, wie ein sauberer Prüfrahmen aussieht: ein klar abgegrenztes Ziel, ein Nachweis ohne Nebenwirkung, eine Abbruchregel, die vorher feststeht. Diese drei Elemente lassen sich auf jeden internen Sicherheitstest übertragen, unabhängig davon, ob dafür jemals 250.000 Dollar gezahlt werden.
Quelle: securityweek.com
