Interessanterweise wurde dieser Angriffsvektor schom Ende Januar auf der AppSecCali2015 Konferenz von Gabriel Lawrence und Chris Frohoff von Qualcom im Rahmen einer umfangreicheren Präsentation zum Thema "Angriffe durch ungesicherte Deserialisierung von Nutzerdaten" ("Marshalling Pickles – how deserializing objects will ruin your day") präsentiert.
Der Angriff nutzt den ungesicherten Aufruf von Methoden auf deserialisierten Daten während oder nach der Deserialisierung aus.
Wenn die transitiv aufgerufenen Zielmethoden potentiell Schadcode ausführen können, ist das Ziel der Angreifer erreicht.
Die serialisierten Daten wurden in diesem Beispiel mittels Hilfsklassen der Apache Commons Collections Bibliothek präpariert,
welche die transparente Transformation von Werten in Containerobjekten, hier sogar dynamisch durch Nutzung von Reflection erlauben.
Ähnliches wurde damals auch für Groovy’s dynamische Maps demonstriert.
Dabei wurde neben dem Angriff auch ein Tool gezeigt, das entsprechende Schad-"Nutz"-daten erzeugen kann.
Da diese Angriffsmöglichekeit aber eher unspektakulär neben anderen Programmiersprachen und Ansätzen dargestellt wurde,
scheint er der Aufmerksamkeit der Öffentlichkeit und auch anderer Sicherheitsexperten entgangen zu sein.
Erst ein sehr interessanter Vortrag von Matthias Kaiser (Code White, Ulm) Ende Oktober im HackerPraktikum an der Ruhr Uni Bochum ging detaillierter auf die Sicherheitslücke ein
und demonstrierte die Ausnutzbarkeit live am Beispiel einer (seither gefixten) Version von Atlassian Bamboo.
Matthias hat darauf hingewiesen dass diese Schwachstelle schon weit vorher thematisiert wurde, z.B. von Pierre Ernst in einem developerWorks Artikel in 2013.
Das spornte Steve Breen (Foxglove Security) an, diese Sicherheitslücke genauer unter die Lupe zu nehmen und zu zeigen, dass häufig genutzte Java Web- und Applicationserver (u.a. WebLogic, IBM WebSphere, JBoss, Jenkins, OpenNMS) anfällig für diesen Angriff waren.
Dieser auch etwas theatralische Artikel hat dann die weltweite "Welle des Entsetzens" ausgelöst, die wir im November erlebt haben.
Wie zu erwarten war, haben sich viele der nachfolgenden Berichterstatter nicht die Mühe gemacht, die Hintergründer zu verstehen und akkurat zu berichten.
Leider hat Steve Breen es nicht für nötig gehalten, die betroffenen Produkte vor der Veröffentlichung seines Artikels zu benachrichtigen, was normalerweise bei solchen erstmalig nachgewiesenen, kritischen Sicherheitslücken (Zero-Day-Exploit) Usus ist.
Zum einen nehmen sie auf verschiedene Weise serialisierte Java-Objekte über das Netzwerk entgegen und deserialisieren sie ungesichert.
Desweiteren sind Bibliotheken im Klassenpfad enthalten, die zur Ausnutzung dieses Verhaltens genutzt werden können.
Dieser Angriff konnte nur verhindert werden, indem man die entsprechenden Klassen (z.B. InvokerTransformer
) aus der Jar-Dateien der Bibliotheken entfernte.
Mittlerweile wurden aktualisierte Versionen (3.2.2, 4.1) von Apache Commons Collections veröffentlicht, die die Serialisierbarkeit dieser Klassen standardmässig abschalten, aber sie in vertrauenswürdigen Umgebungen durch eine System-Property wieder aktivieren lässt.
Auch für andere Bibliotheken wie Groovy (2.4.4) und Spring (4.1.9, 4.2.3) sind Versionen verfügbar, die nicht mehr für diesen Angriff genutzt werden können.
Da Java-Deserialisierung, besonders auch von Daten die über das Netzwerk empfangen werden, in der Java Welt gang und gäbe ist (dazu später mehr),
ist es sehr augenscheinlich, dass dies nicht die einzige schadhafte Kombination darstellt.
Leider wurde bisher noch nicht genügend Augenmerk auf die Absicherung des Deserialisierungs-Mechanismus gelegt.
Es bleibt zu hoffen, dass Oracle selbst dafür sorgt, dass während der Deserialisierung selbst, der transitive Aufruf bestimmter, potentiell gefährliche Methoden abgeblockt wird.
Aber selbst nach einer erfolgreichen Deserialisierung sollte man Daten, die aus nicht vertrauenswürdigen Quellen stammen, und plötzlich als aktives Objekt in der eigenen JVM leben, mit entsprechender Vorsicht begegnen.
Zum Glück muss man nicht nur auf Sicherheitsexperten vertrauen, sondern kann sich mit einigen quelloffenen Tools selbst ein Bild davon verschaffen,
ob die eigene Infrastruktur potentiell gefährliche Kombinationen enthält.
Die Stimmen, die der Apache Bibliothek die Schuld an allem gaben haben nur teilweise recht.
Zwar machen die dort vorhandenen, serialisierbaren Klassen es deutlich leichter die Sicherheitslücke auszunutzen,
aber das Grundproblem liegt am sorglosen Umgang mit Daten aus nicht vertrauenswürdigen Quellen.
Im Statement der Apache Foundation ist auch genau das nachzulesen:
It is not Apache Commons Collections that is unsafe, it is applications which use Java Serialization in an unsafe way.
If anybody asks you whether an application is unsafe because of Apache Commons Collections,
explain to them that deserializing untrusted data is unsafe, not the presence of generally useful libraries.