Google DevSite RCE: Wie ein geleaktes Secret Remote Code Execution ermöglichte

Der Sicherheitsforscher Simon Koeck entdeckte im August 2026 eine kritische Remote Code Execution (RCE)-Schwachstelle in Googles gemeinsamer DevSite-Plattform. Der Fehler ermöglichte es einem Angreifer, beliebigen Code auf Servern auszuführen, die Entwicklerdokumentationen für Dienste wie Firebase und Android hosten, indem er einen falsch konfigurierten Flask-Session-Cookie ausnutzte. Google zahlte Koeck nach Bestätigung des Problems, das mehrere hochkarätige Subdomains betraf, 90.000 US-Dollar für den Bericht.

Was passiert ist

Koeck kartierte den OAuth-Authentifizierungsfluss, der auf Googles Entwicklerdokumentationsseiten, einschließlich developers.google.com, verwendet wird. Er bemerkte, dass der während des OAuth-Handshakes ausgegebene Flask-Session-Cookie ungewöhnlich groß war, etwa 1.200 Bytes. Da Flask-Cookies signiert, aber nicht verschlüsselt sind, dekodierten er die Payload, um deren Inhalt zu untersuchen. Darin fand er ein pickle-serialisiertes Objekt, das eine Instanz von oauth2client.client.OAuth2WebServerFlow enthielt. Entscheidend war, dass dieses Objekt die Google-OAuth-client_id und das client_secret im Klartext enthielt.

Die Präsenz des Client-Secrets in einem clientseitigen Cookie war bereits ein erheblicher Sicherheitsfund. Koeck erkannte jedoch, dass die Implikationen weiter gingen, als er testete, ob dieses Secret auch als Flask-SECRET_KEY zum Signieren des Cookies selbst verwendet wurde. Indem er den Signierungsschlüssel aus dem exponierten Client-Secret unter Verwendung der Standardlogik der itsdangerous-Bibliothek von Flask ableitete, konnte er die Signatur des Cookies offline erfolgreich reproduzieren. Das bedeutete, dass der Server ein Secret verwendete, das innerhalb genau der Daten gespeichert war, die er schützen wollte, um die Integrität dieser Daten zu verifizieren.

Mit der Fähigkeit, gültige Session-Signaturen zu fälschen, konnte Koeck die vorgesehenen Sicherheitskontrollen umgehen. Die Anwendungslogik rief das OAuth-Flow-Objekt aus der Session ab und deserialisierte es mit pickle.loads(). Da Pythons Pickle-Modul während der Deserialisierung beliebigen Code ausführen kann, wenn es auf bestimmte Opcodes trifft, und da Koeck nun valid signierte Cookies erstellen konnte, hatte er unauthentifizierte Remote Code Execution erreicht. Er demonstrierte dies, indem er Payloads injizierte, die den Server dazu brachten, für spezifische Zeiträume zu schlafen, was bewies, dass der Code auf dem Backend ausgeführt wurde, ohne auf sensible Produktionsdaten zuzugreifen.

Wie es funktioniert

Die Schwachstelle basierte auf einer Kette von drei spezifischen Fehlkonfigurationen. Erstens speicherte die Anwendung sensible Credentials (das OAuth-Client-Secret) direkt im Session-Cookie des Benutzers. Zweitens verwendete sie dasselbe Client-Secret als kryptografischen Schlüssel zum Signieren des Session-Cookies, was eine zirkuläre Abhängigkeit schuf, bei der der Schlüssel für jeden öffentlich war, der das Cookie inspizierte. Drittens deserialisierte die Anwendung benutzergesteuerte Daten aus dem Cookie unter Verwendung von Pythons pickle-Modul, das inhärent unsicher für nicht vertrauenswürdige Eingaben ist, da es Objektinstanziierung und Methodenaufrufe während des Ladevorgangs erlaubt.

Flask verwendet die itsdangerous-Bibliothek zum Signieren von Cookies und leitet typischerweise einen spezifischen Signierungsschlüssel vom Haupt-SECRET_KEY unter Verwendung von HMAC-SHA1 ab. Koeck replizierte diese Ableitung lokal unter Verwendung des geleakten Client-Secrets. Nachdem er bestätigt hatte, dass die Signatur übereinstimmte, erstellte er ein neues Session-Cookie. Er fügte eine bösartige Pickle-Payload unter dem erwarteten Session-Key ein, signierte sie mit dem abgeleiteten Schlüssel und sandte sie an den Server. Der Server verifizierte die Signatur erfolgreich, extrahierte das Pickle-Objekt und führte die eingebetteten Anweisungen aus, wie z. B. den Aufruf von time.sleep().

Wichtige Details

• Die Schwachstelle bestand in der gemeinsamen DevSite-Plattform und betraf developers.google.com, firebase.google.com, developer.android.com, source.android.com und docs.partner.android.com.
• Der Flask-Session-Cookie enthielt ein pickle-serialisiertes OAuth2WebServerFlow-Objekt mit dem live OAuth-client_secret im Klartext.
• Das OAuth-client_secret wurde als Flask-SECRET_KEY zum Signieren des Session-Cookies verwendet, was es Angreifern ermöglichte, gültige Sessions zu fälschen.
• Remote Code Execution wurde durch die Verwendung von time.sleep(N)-Payloads nachgewiesen, wobei die Antwortzeiten des Servers exakt mit der injizierten Schlafdauer übereinstimmten.
• Google klassifizierte das Problem als S0 (kritisch) RCE und vergab eine Bounty von 90.000 US-Dollar, berechnet aus einer Basis von 75.000 US-Dollar plus einem Multiplikator von 1,2x für die Berichtsqualität.
• Die Behebung umfasste das Rotieren von Secrets, das Trennen von Signierungsschlüsseln von OAuth-Credentials, das Speichern von Flow-Objekten serverseitig und das Ersetzen von Pickle durch ein sicheres Datenformat.

Warum es wichtig ist

Dieser Vorfall verdeutlicht die Gefahren der Verwendung komplexer Serialisierungsformate wie Pickle für Daten, die Vertrauensgrenzen überschreiten. Während Pickle praktisch ist, um den Zustand von Python-Objekten zu erhalten, bietet es keinen Mechanismus, um einzuschränken, welche Klassen oder Funktionen während der Deserialisierung aufgerufen werden können. In Kombination mit einem kompromittierten Signierungsschlüssel wird es zu einem direkten Weg zur Remote Code Execution. Entwickler gehen oft davon aus, dass signierte Cookies manipulationssicher sind, aber wenn der Signierungsschlüssel geleakt oder schlecht verwaltet wird, verschwindet diese Garantie vollständig.

Für Engineering-Teams dient dies als Erinnerung daran, wie Secrets verwaltet und rotiert werden, zu auditieren. Die Verwendung eines Credentials für mehrere Zwecke – wie sowohl API-Authentifizierung als auch Session-Signierung – erhöht die Schadensreichweite eines einzelnen Leaks. Es unterstreicht auch die Bedeutung, sensible Zustände serverseitig zu halten. Cookies sollten nur opake Referenzen oder minimale, nicht-sensible Daten enthalten, insbesondere bei Authentifizierungsflüssen, die Drittanbieter wie Google OAuth beinhalten.

Was Sie tun können

• Auditieren Sie das Session-Management Ihrer Anwendung, um sicherzustellen, dass Signierungsschlüssel von anderen Credentials wie API-Secrets oder OAuth-Tokens getrennt sind.
• Verwenden Sie keine Credentials für mehrere Zwecke.
• Halten Sie sensible Zustände serverseitig.
• Ersetzen Sie unsichere Serialisierungsformate wie Pickle durch sichere Alternativen.