© Excellent backgrounds/Shutterstock.com
Java Magazin
Anatomie einer Remote Code Execution

Angriff auf die Java-Deserialisierung

Kaum eine andere Sicherheitslücke hat in den letzten zwölf Monaten mehr Aufmerksamkeit bekommen und wurde zugleich von der Tragweite her dennoch unterschätzt wie das Thema rund um Java-Deserialisierung. In diesem Artikel nehme ich Sie mit zu den Details eines solchen Angriffs, versuche verbreitete Missverständnisse aufzuräumen und diskutiere Wege zur Absicherung.

Christian Schneider


Wir schreiben das Jahr 2006, als bereits erste Veröffentlichungen zu einem grundsätzlichen Problem mit der Java-Deserialisierung in der Securityszene auftauchen [1]. Damals eher geeignet, um die JVM crashen zu lassen, legte dies für lange Jahre unbemerkt den Grundstein für die Weiterentwicklung von Angriffen, die knapp eine Dekade später 2015 und 2016 ihren vorläufigen Höhepunkt mit Veröffentlichungen der Securityforscher Christopher Frohoff und Kollegen gefunden hat [2]. In den letzten Monaten sind zahlreiche Patches hierzu in großen und kleinen Produkten erschienen, eine Menge Unsicherheit verursacht worden und darauf basierend einige Missverständnisse entstanden. Um nur ein Missverständnis zu nennen: Die Apache Commons Collections seien die Problemursache. Diese weit verbreitete Bibliothek ist höchstens Teil eines viel größeren und grundsätzlicheren Problems, aber auf keinen Fall die Ursache. Um Licht ins Dunkel zu bringen, versuche ich anhand von Beispielen den Finger in die Wunde zu legen und abschließend praktische Tipps zur Absicherung zu diskutieren [3].

Zutaten für einen Angriff

Damit ein Angreifer erfolgreich im Rahmen einer Java-Deserialisierung seinen bösartigen Code auf dem anzugreifenden Zielsystem ausführen kann, sind zwei Voraussetzungen notwendig. Als Erstes muss der Angreifer eine Schnittstelle finden, die versucht, seine Daten zu deserialisieren. In der Securityszene sprechen wir hier von so genannten Endpoints für Untrusted Java Deserialization. Erst wenn ein Angreifer einen solchen Endpoint mit seinen maliziösen Daten befüllen kann, ist er im Spiel. Man könnte nun meinen: Dann haben die meisten Systeme kein Problem. Denn nur ein kleiner Bruchteil der typischen Architekturen setzt auf Java-Serialisierung. Jedoch schlummert hier der Teufel im Detail, denn es gibt weitaus mehr Frameworks, Technologien und Produkte, die Java-Serialisierung als Teil ihrer Remote-Kommunikation nutzen als vermutet. Um nur ein paar besonders prominente Kandidaten zu nennen: HTTP-Invoker, JMS, JMX, RMI, AMF und ViewState. Spätestens anhand der hohen Anzahl an Patches zu dem Thema in den letzten Monaten lässt sich ablesen, wie überraschend weit verbreitet doch auf Java-Serialisierung gesetzt wird. Somit räume ich mit dem ersten Missverständnis auf, dass nur direkt auf Java-Serialisierung setzende Anwendungen betroffen sein können: Die Angriffsoberfläche ist deutlich größer, wenn eingesetzte Frameworks, Technologien und Produkte indirekt Java-Serialisierung verw...

Java Magazin
Anatomie einer Remote Code Execution

Angriff auf die Java-Deserialisierung

Kaum eine andere Sicherheitslücke hat in den letzten zwölf Monaten mehr Aufmerksamkeit bekommen und wurde zugleich von der Tragweite her dennoch unterschätzt wie das Thema rund um Java-Deserialisierung. In diesem Artikel nehme ich Sie mit zu den Details eines solchen Angriffs, versuche verbreitete Missverständnisse aufzuräumen und diskutiere Wege zur Absicherung.

Christian Schneider


Wir schreiben das Jahr 2006, als bereits erste Veröffentlichungen zu einem grundsätzlichen Problem mit der Java-Deserialisierung in der Securityszene auftauchen [1]. Damals eher geeignet, um die JVM crashen zu lassen, legte dies für lange Jahre unbemerkt den Grundstein für die Weiterentwicklung von Angriffen, die knapp eine Dekade später 2015 und 2016 ihren vorläufigen Höhepunkt mit Veröffentlichungen der Securityforscher Christopher Frohoff und Kollegen gefunden hat [2]. In den letzten Monaten sind zahlreiche Patches hierzu in großen und kleinen Produkten erschienen, eine Menge Unsicherheit verursacht worden und darauf basierend einige Missverständnisse entstanden. Um nur ein Missverständnis zu nennen: Die Apache Commons Collections seien die Problemursache. Diese weit verbreitete Bibliothek ist höchstens Teil eines viel größeren und grundsätzlicheren Problems, aber auf keinen Fall die Ursache. Um Licht ins Dunkel zu bringen, versuche ich anhand von Beispielen den Finger in die Wunde zu legen und abschließend praktische Tipps zur Absicherung zu diskutieren [3].

Zutaten für einen Angriff

Damit ein Angreifer erfolgreich im Rahmen einer Java-Deserialisierung seinen bösartigen Code auf dem anzugreifenden Zielsystem ausführen kann, sind zwei Voraussetzungen notwendig. Als Erstes muss der Angreifer eine Schnittstelle finden, die versucht, seine Daten zu deserialisieren. In der Securityszene sprechen wir hier von so genannten Endpoints für Untrusted Java Deserialization. Erst wenn ein Angreifer einen solchen Endpoint mit seinen maliziösen Daten befüllen kann, ist er im Spiel. Man könnte nun meinen: Dann haben die meisten Systeme kein Problem. Denn nur ein kleiner Bruchteil der typischen Architekturen setzt auf Java-Serialisierung. Jedoch schlummert hier der Teufel im Detail, denn es gibt weitaus mehr Frameworks, Technologien und Produkte, die Java-Serialisierung als Teil ihrer Remote-Kommunikation nutzen als vermutet. Um nur ein paar besonders prominente Kandidaten zu nennen: HTTP-Invoker, JMS, JMX, RMI, AMF und ViewState. Spätestens anhand der hohen Anzahl an Patches zu dem Thema in den letzten Monaten lässt sich ablesen, wie überraschend weit verbreitet doch auf Java-Serialisierung gesetzt wird. Somit räume ich mit dem ersten Missverständnis auf, dass nur direkt auf Java-Serialisierung setzende Anwendungen betroffen sein können: Die Angriffsoberfläche ist deutlich größer, wenn eingesetzte Frameworks, Technologien und Produkte indirekt Java-Serialisierung verw...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang