Cybersicherheit

Google zahlte 90.000 US-Dollar für eine Remote-Code-Execution-Schwachstelle in DevSite und behob sie erst nach zwei Monaten

Simon Köck entdeckte eine nicht dokumentierte Remote-Code-Execution-Schwachstelle in der Architektur von Google DevSite. Sie entstand durch die Wiederverwendung eines OAuth-Geheimnisses als Schlüssel zur Signierung von Flask-Sitzungen in Verbindung mit unsicherer Deserialisierung von Python-Daten. Google stufte die Schwachstelle als S0 ein und zahlte eine Prämie von 90.000 US-Dollar, veröffentlichte die Behebung jedoch erst zwei Monate nach der Meldung.

2026-10-12
4 Min. Lesezeit
16 Aufrufe
certi.news Editorial Team
Google zahlte 90.000 US-Dollar für eine Remote-Code-Execution-Schwachstelle in DevSite und behob sie erst nach zwei Monaten

Google zahlte dem Sicherheitsforscher Simon Köck eine Prämie von 90.000 US-Dollar, nachdem er eine nicht dokumentierte Remote-Code-Execution-Schwachstelle in DevSite entdeckt hatte, der gemeinsamen Plattform hinter developers.google.com und weiteren Dokumentationsseiten. Köck meldete das Problem am 6. August, Google akzeptierte den Bericht am folgenden Tag und stimmte der Prämie am 27. August zu, doch die Behebung wurde erst am 7. Oktober auf die Server ausgerollt.

Google stufte die Schwachstelle mit S0 ein, der höchsten Stufe in seiner Bewertungsskala, und gewährte Köck eine Grundprämie von 75.000 US-Dollar für eine RCE-Schwachstelle in der regulären Anwendungsschicht, zuzüglich eines Aufschlags von 20 Prozent aufgrund der außergewöhnlichen Qualität des Berichts.

Drei Fehler bildeten die Exploit-Kette

DevSite speicherte ein serialisiertes OAuth2WebServerFlow-Objekt aus der veralteten Bibliothek oauth2client in einem Flask-Sitzungscookie. Dadurch wurde ein OAuth-Clientgeheimnis offengelegt. Das Problem wurde jedoch dadurch verschärft, dass dasselbe Geheimnis auch als Schlüssel zur Signierung von Flask-Sitzungen verwendet wurde.

Köck konnte die Signierung der Cookies lokal reproduzieren und gefälschte Sitzungen erstellen, die der Server akzeptierte. Da der OAuth-Flow pickle zur Deserialisierung der Sitzungsdaten verwendete, konnte er das Objekt durch eine signierte, bösartige Pickle-Nutzlast ersetzen und anschließend die Remote-Ausführung von Python-Code nachweisen.

Der Forscher bestätigte die Ausführung mit einer Nutzlast, die die Antwort durch einen sleep-Befehl verzögerte und absichtlich vor der Ausführung tatsächlicher Befehle oder dem Zugriff auf Dateien, Zugangsdaten oder interne Dienste abbrach. Seiner Darstellung zufolge wurden die gefälschten Sitzungen auf den sieben betroffenen Domains akzeptiert, während der Proof-of-Concept auf drei Domains ausgeführt wurde: developers.google.com, docs.partner.android.com und web.dev.

Das Ausmaß der Auswirkungen blieb nicht vollständig geklärt

Köck konnte nicht nachweisen, ob der Server den Inhalt der Google-Dokumentation ändern oder Installationsbefehle und Download-Links ersetzen konnte – ein Szenario, das den Weg für einen Angriff auf die Software-Lieferkette hätte ebnen können. Er testete auch nicht, ob die gefälschten Sitzungen die Identitätsübernahme von Nutzern oder den Zugriff auf deren Daten ermöglichten.

Der Forscher Arvin Shivram, bekannt als @brutecat, wies darauf hin, dass interne App-Engine-Anwendungen üblicherweise auf Stubby, Googles internes System für die Kommunikation zwischen Diensten, zugreifen können. Köck erklärte, dass ein solcher Zugriff, falls dieser Prozess darüber verfügte, die Auswirkungen erheblich ausweiten könnte. Er überprüfte jedoch nicht die Berechtigungen von DevSite oder dessen Zugriffsbereich auf Backend-Dienste.

Warum ist diese Nachricht wichtig?

Der Fall zeigt, dass das Risiko nicht durch einen einzelnen Fehler entstand, sondern durch das Zusammenspiel von drei Praktiken: die Offenlegung eines sensiblen Geheimnisses in einem Cookie, seine Wiederverwendung als Signaturschlüssel und die unsichere Deserialisierung nicht vertrauenswürdiger Daten. Die Behebung jeder einzelnen Verbindung in dieser Kette hätte den Exploit-Pfad unterbrochen. Dadurch werden die Trennung von Geheimnissen und der Verzicht auf pickle in Sitzungsdaten zu grundlegenden Kontrollen und nicht zu optionalen Verbesserungen.

Gleichzeitig wirft die etwa zwei Monate dauernde Frist bis zur Behebung operative Fragen auf, die Google nicht beantwortet hat. Das Unternehmen erklärte nicht, ob es vorübergehende Maßnahmen zur Risikominderung ergriffen, die beiden unterschiedlichen Signaturschlüssel ausgetauscht hatte, die nach Angaben von Köck von den sieben Domains verwendet wurden, oder bestehende Sitzungen ungültig gemacht hatte. Google legte auch kein forensisches Ergebnis dazu offen, ob die Schwachstelle vor der Veröffentlichung des Patches ausgenutzt worden war, und hatte auf eine Anfrage von The New Stack nach einer Stellungnahme zum Zeitpunkt der Aktualisierung des Artikels noch nicht geantwortet.

Nachrichtenquelle
The New Stack - Software Development
Originalquelle öffnen ↗
c
Autor

certi.news Editorial Team

Aus derselben Kategorie

Das könnte Sie interessieren

Alle Nachrichten anzeigen