Googles Entwicklerserver konnten dazu gebracht werden, Code auszuführen, ohne dass sich ein Angreifer anmelden musste.
Der Sicherheitsforscher Simon Köck entdeckte eine Schwachstelle in Googles DevSite-Plattform, durch die ein Authentifizierungsgeheimnis offengelegt wurde und Angreifer vertrauenswürdige Sitzungen fälschen konnten. In Verbindung mit der unsicheren Verarbeitung von Daten konnte die Lücke die Remote-Code-Ausführung auf dem Server ermöglichen.
Google hat das Problem inzwischen behoben und Köck für die Entdeckung 90.000 US-Dollar gezahlt. Der Fall zeigt, wie sich zwei Sicherheitsschwachstellen verbinden können und ein offengelegtes Zugangstoken in eine weitaus schwerwiegendere Kompromittierung verwandeln kann.
Ein Cookie enthielt den zu seiner Überprüfung verwendeten Schlüssel
Bei der Untersuchung des OAuth-Anmeldevorgangs auf developers.google.com bemerkte Köck ein etwa 1.200 Byte großes Flask-Sitzungscookie. Besucher erhielten es, bevor sie auf Googles Anmeldeseite weitergeleitet wurden.
Laut Köck enthielt das dekodierte Cookie eine OAuth-Client-ID und ein Client-Geheimnis. In der Implementierung von DevSite konnte das offengelegte Geheimnis auch zum Signieren von Flask-Sitzungscookies verwendet werden, sodass ein Angreifer Cookies erstellen konnte, die die Anwendung als gültig akzeptierte.
Eine separate Schwachstelle befand sich im OAuth-Callback. Er verwendete Python's pickle.loads(), um ein in der Sitzung gespeichertes Objekt wiederherzustellen – ein Vorgang, bei dem durch unsichere Deserialisierung vom Angreifer kontrollierte Anweisungen ausgeführt werden können. Gefälschte Cookies konnten daher schädliche Anweisungen in die Funktion einschleusen.
Um die Schwachstelle zu testen, ohne Betriebssystembefehle auszuführen, erstellte der Forscher time.sleep()-Payloads. Die Serverantworten verzögerten sich um etwa drei, fünf und acht Sekunden und entsprachen damit den angeforderten Zeitspannen. Cookies mit veränderten Signaturen wurden abgewiesen, was seine Feststellung stützte, dass der Server die Testfunktionen ausgeführt hatte.
Vier weitere Entwicklerseiten akzeptierten gefälschte Sitzungen
Weitere Tests ergaben, dass der wiedergewonnene Schlüssel bei vier zusätzlichen Websites funktionierte. Gültige Sitzungen wurden auf firebase.google.com, developer.android.com, source.android.com und docs.partner.android.com akzeptiert. Köck dokumentierte keine separaten Tests zur Codeausführung für die einzelnen Hosts.
Google zahlte Köck 90.000 US-Dollar, nachdem das Unternehmen die Schwachstelle als S0-Problem mit Remote-Code-Ausführung eingestuft hatte. Die DevSite-Ingenieure schlossen die Behebung am 7. Okt. ab, noch vor der öffentlichen Bekanntgabe.
Köck berichtete, dass das offengelegte OAuth-Clientgeheimnis noch aktiv war, als er seine Meldung vorbereitete, obwohl er dessen Wert zurückhielt.
Google hat die in seinem Bericht beschriebenen Maßnahmen zur Behebung nicht öffentlich detailliert, daher ist unklar, ob die Korrektur eine Änderung der Sitzungsverwaltung, die Entfernung der unsicheren Deserialisierung oder andere Maßnahmen umfasste. Der gemeldete Status des Zugangstokens belegt nicht, dass der ursprüngliche Angriff weiterhin ausnutzbar war.
Sicherheitsteams sollten ihre Sitzungsverwaltung überprüfen
Die Schwachstelle war spezifisch für Googles DevSite-Implementierung, verdeutlicht jedoch Sicherheitsrisiken, die auch andere Webanwendungen betreffen können.
Entwickler sollten überprüfen, wie ihre Anwendungen Sitzungsdaten speichern und mit Informationen umgehen, die sie von Browsern erhalten. Signierte Cookies können vor unbefugten Änderungen schützen, verschlüsseln ihren Inhalt jedoch nicht zwangsläufig und machen unsichere Deserialisierung nicht sicher.
Sicherheitsteams sollten mehrere Prüfungen priorisieren:
- Sitzungscookies auf offengelegte Zugangsdaten prüfen. Überprüfen Sie, welche Informationen Ihre Anwendungen Browsern zugänglich machen, und entfernen Sie eingebettete Geheimnisse. Nehmen Sie diese Prüfungen in regelmäßige Überprüfungen der Anwendungssicherheit auf, insbesondere bei internetseitig erreichbaren Diensten.
- Unsichere Datenverarbeitung finden. Untersuchen Sie Code, der Objekte aus Informationen wiederherstellt, die Benutzer beeinflussen können, insbesondere Funktionen wie pickle.loads(). Ersetzen Sie riskante Deserialisierungspfade durch validierte Datenformate oder serverseitige Datensätze.
- Gemeinsam verwendete Authentifizierungsdaten überprüfen. Identifizieren Sie Websites, die Signaturschlüssel oder andere sicherheitskritische Zugangsdaten wiederverwenden. Verwenden Sie, wo angemessen, separate Schlüssel und etablieren Sie Verfahren, um offengelegte Geheimnisse regelmäßig zu erneuern und betroffene Sitzungen ungültig zu machen.
- Offengelegte Endpunkte testen und Anwendungsberechtigungen beschränken. Beziehen Sie vor der Anmeldung gestellte Anfragen in Sicherheitstests von Webanwendungen sowie in Codeprüfungen ein. Beschränken Sie die Berechtigungen von Anwendungsprozessen, um den möglichen Zugriff auf vertrauliche Geschäftsinformationen oder verbundene Systeme zu reduzieren.
Der DevSite-Fall zeigt, wie Schwachstellen, die isoliert betrachtet beherrschbar erscheinen, in Kombination wesentlich gefährlicher werden können. Für Entwickler bedeutet die Absicherung der Authentifizierung, nicht nur den Anmeldevorgang zu schützen, sondern auch die Daten, denen Anwendungen nach dem Aufbau einer Sitzung vertrauen.
Weitere Nachrichten aus der Cybersicherheit: SonicWall-Kunden hatten ein enges Zeitfenster für Patches, nachdem Angreifer begonnen hatten, eine kritische Schwachstelle auszunutzen – innerhalb von 48 Stunden nach der Veröffentlichung.