OWASP Top Ten 2017 (de)

A8:2017-Unsichere Deserialisierung

 Languages: en [de] es
Bedrohungsquellen / Angriffsvektoren Schwachstellen Auswirkungen
Anw.-
spezifisch		 Ausnutzbarkeit: 1 Verbreitung: 2 Auffindbarkeit: 2 technisch: 3 Geschäftl. ?
Das Ausnutzen von Fehlern in der Deserialisierung ist nicht trivial, zumal vorhandener Angriffscode selten ohne weitere Anpassungen einsetzbar ist.
Dieser Eintrag in den Top 10 basiert auf einer Expertenumfrage in der Community Dieser Eintrag in den Top 10 basiert auf einer Expertenumfrage in der Community und nicht auf messbaren Fallzahlen.
Einige Werkzeuge können Deserialisierungsschwachstellen entdecken, allerdings ist häufig eine manuelle Überprüfung des Fundes nötig. Es ist zu erwarten, dass belastbareres Zahlenmaterial zur Verfügung stehen wird, sobald die Tools zur Erkennung weiter entwickelt sind.
Die Auswirkungen von Deserialisierungsfehlern sollten nicht unterschätzt werden. Diese Schwachstelle kann durchaus zu “Remote-Code Execution” führen, einem der schwerwiegendsten Angriffe überhaupt.
Die Auswirkungen auf das Unternehmen hängen vom Schutzbedarf der Anwendung und ihrer Daten ab.
Ist die Anwendung verwundbar?
Anwendungen oder APIs können verwundbar sein, wenn Sie bösartige oder vom Angreifer manipulierte Objekte deserialisieren.Dies kann zu zwei Hauptangriffsarten führen:
* Angriffe mittels Objekt- und Datenstrukturen, die es Angreifern ermöglichen, die Anwendungslogik zu verändern oder Programmcode auszuführen. Dies ist möglich, sofern die Anwendung auf Klassen zugreifen kann (inkl. Standardklassen), deren Verhalten während oder nach der Deserialisierung manipuliert werden kann.
* Übliche Angriffe mittels Datenmanipulation: dazu zählen Angriffe gegen die Zugriffskontrolle, wobei existierende Datenstrukturen genutzt und deren Inhalt manipuliert werden.
Serialisierung wird häufig eingesetzt bei:
* Remote- und Inter-Prozess Kommunikation (RPC/IPC)
* Wire-Protokollen, Webservices, Message-Brokern
* Caching/Persistenz
* Datenbanken, Cache-Servern, Dateisystemen
* HTTP-Cookies, HTML-Formular-Parameter oder API-Authentifizierungs-Token.
Wie kann ich das verhindern?
Der einzig sichere Weg ist es keine serialisierten Objekte aus nicht vertrauenswürdigen Quellen anzunehmen oder nur serialisierte Datenstrukturen zu nutzen, die ausschließlich einfache Datentypen erlauben.
Andernfalls ziehen Sie folgende Empfehlungen in Betracht:
* Versehen Sie alle serialisierten Objekte mit einer digitalen Signatur, um so zu verhindern, dass bösartige Objekte erzeugt oder Daten manipuliert werden können.
* Achten Sie auf eine strikte Typisierung während der Deserialisierung und bevor Objekte erzeugt werden. Zumeist wird hier nur eine bekannte Menge an Klassen benötigt. Es wurde bereits gezeigt, das diese Maßnahme umgangen werden kann. Es ist daher nicht ratsam, sich alleine hierauf zu verlassen.
* Isolieren Sie den für die Deserialiserung zuständigen Programmcode und führen Sie ihn in einer eigenen Umgebung mit möglichst geringen Berechtigungen aus.
* Protokollieren Sie alle Ausnahmefehler, die bei der Deserialisierung auftreten (z.B. unerwartete Objekt-Typen).
* Begrenzen oder überwachen Sie ein- und ausgehende Netzwerkaktivitäten von Containern oder Servern, die Deserialisierungen ausführen. * Überwachen und melden Sie, wenn ein Nutzer auffällig häufig eine Deserialisierung nutzt.
Mögliche Angriffsszenarien
Szenario 1: Eine React basierte Anwendung nutzt einige Spring Boot-Microservices. Die Programmierer dieser funktionalen Sprache haben darauf geachtet, dass ihr Programmcode „unveränderbar“ ist. Daher serialisieren Sie den Benutzerstatus und transferieren diesen so mit jeder Anfrage hin und her. Ein Angreifer entdeckt die „rO0“-Base64-Signatur des Java-Objekts und nutzt das Werkzeug Java Serial Killer, um Remote-Code-Execution auf dem Anwendungsserver auszuführen.

Szenario 2: Ein PHP Forum nutzt die PHP-Objekt-Serialisierung um ein „Super-Cookie“ zu erzeugen, dieses enthält Angaben zur User-ID, Rolle, einen Passwort-Hash und weitere Informationen:
a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user";
 i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
 Ein Angreifer verändert nun das serialisierte Objekt, um sich selbst Admin-Rechte zu verschaffen:
a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin";
 i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
Referenzen