Dipl.-Inform. Carsten Eilers

Die Schwachstelle in der Java-Library Apache Common Collections wurde von Chris Frohoff und Gabriel Lawrence in ihrem Vortrag Marshalling Pickles auf der AppSec California 2015 präsentiert. Das Problem liegt in der (de)serialisierung von Daten. Deserialisierungs-Schwachstellen sind eine eigene Klasse von Schwachstellen und betreffen nicht nur die Common Collections Library oder Java.

Die meisten Programmiersprachen stellen Funktionen bereit, über die sich Daten in einen Datenstrom umwandeln lassen, der dann gespeichert oder über das Netzwerk übertragen werden kann. Diese Umwandlung bezeichnet man als Serialisierung (serialization). Sollen die Daten später wieder verarbeitet werden, müssen sie ins ursprüngliche Format zurückgewandelt werden, was als Deserialisierung (unserialization) bezeichnet wird. Deserialisierungs-Schwachstellen entstehen, wenn Code serialisierte Daten aus unsicheren Quellen ungeprüft (oder nicht ausreichend gründlich geprüft) deserialisiert. Je nach Sprache und Anwendungsfall kann das alle möglichen Folgen haben. Im schlimmsten Fall kann ein Angreifer darüber Code einschleusen (je nachdem, was mit den Daten nach der Deserialisierung passiert).

Im Fall der Java-Library Common Collections befindet sich eine solche Schwachstelle in der Funktion InvokerTransformer, und es lässt sich darüber erwiesenermaßen Code einschleusen.

Das Fatale an dieser Schwachstelle ist nicht nur, dass es bisher keinen Patch gibt, sondern, dass der alleine nicht ausreicht. Die Library ist sehr weit verbreitet, so dass viele Anwendungen und Frameworks von der Schwachstelle betroffen sind. Und sehr oft verwenden diese Programme eigene Libraries. Es reicht also nicht, wie zum Beispiel bei Shared Libraries unter Linux DIE Common Collections Library (die systemweit verwendet wird) zu aktualisieren, es müssen alle Kopien davon gepatcht werden.

Die Entwickler der Common Collections arbeiten an einem Patch, das eigentliche Problem liegt aber tiefer, siehe unten.

Wann ist eine Java-Anwendung angreifbar?

Ob eine Java-Anwendung die Common Collections und die Funktion InvokerTransformer verwendet, können Sie mit grep herausfinden. Suchen Sie im Verzeichnis der Anwendung mit dem Befehl

grep -R InvokerTransformer .

nach Vorkommen von InvokerTransformer in der Anwendung. Wird etwas gefunden, könnte die Anwendung verwundbar sein. Ob sie es wirklich ist, hängt davon ab, ob serialisierte Daten verarbeitet werden.

Als nächstes müssen Sie daher die Daten der Anwendung daraufhin prüfen, ob darin serialisierte Daten vorkommen. Die erkennen Sie an den Strings

rO0AB

bei Base64-kodierten Daten und

ac ed 00 05

bei Binärdaten (in Hexadezimal-Darstellung).

Wenn Sie serialisierte Daten in gespeicherten Dateien oder im Netzwerkverkehr der Anwendung entdecken, sollten Sie davon ausgehen, dass die 1. deserialisiert werden (sonst könnte die Anwendung ja nichts damit anfangen) und dass das 2. mit Hilfe der verwundbaren Common Collections Library passiert (warum sollte jemand selbst einen Deserialisierer implementieren, wenn er eine Library verwendet, die bereits einen enthält?)

Wenn Sie ganz sicher gehen wollen, können Sie weiter testen. Chris Frohoff und Gabriel Lawrence haben ein PoC-Tool (ysoserial) veröffentlicht, mit dem sich Payloads zur Ausnutzung der Schwachstelle erzeugen lassen. Damit können Sie testen, ob Ihre Anwendung wirklich betroffen ist.

Das ist natürlich nicht ganz so einfach wie hier beschrieben, aber ich möchte ja auch keine Anleitung für Skript-Kiddies veröffentlichen. Stephen Breen hat die Entwicklung seiner 0-Day-Exploits ausführlich beschrieben.

Die veröffentlichten Exploits

Stephen Breen hat für die folgenden Programme 0-Day-Exploits veröffentlicht:

• WebSphere
  WebSphere lauscht auf Port 8880 auf Nachrichten des Tools wsadmin. Ein Angreifer, der Zugriff auf den Port hat (der normalerweise nicht aus dem Internet zugänglich ist), kann darüber seine Payload einschleusen.
• JBoss
  Hier erfolgt der Angriff über das oft aus dem Internet zugängliche Servlet JMXInvokerServlet.
  Red Hat untersucht den Vorfall noch, sofern nötig befinden sich Patches bereits in der Entwicklung. Als Workaround empfiehlt man, die betroffenen .class-Dateien (InvokerTransformer, InstantiateFactory und InstantiateTransfromer) aus allen vorhandenen Common Collections jars zu löschen. Langfristig müssen die Deserialisierungs-Schwachstellen aber behoben werden, indem die Daten vor der Deserialisierung geprüft werden. Die von Red Hat vorgeschlagene vorherige Authentifizierung ist 1. nicht immer möglich und schützt 2. nicht vor einem bösartigen oder missbrauchten Benutzer.
• Jenkins
  Das Command-Line-Tool jenkins-cli.jar lauscht an hohen Ports (die meist nicht aus dem Internet zugänglich sind). Wenn der Angreifer dort seine Payload abladen kann, hat er gewonnen.
  Die Jenkins-Entwickler haben zunächst eine Mitigation zur Abwehr von Angriffen und danach ein Update zur Korrektur der Schwachstelle veröffentlicht.
• WebLogic
  WebLogic lauscht (nur) an Port 7001, der daher oft aus dem Internet zugänglich sein wird. Entsprechend präparierte Daten führen zur Ausführung des darüber eingeschleusten Codes.
  Oracle hat einen Security Alert für die Schwachstelle (die die CVE-ID CVE-2015-4852 erhalten hat) veröffentlicht. Patches befinden sich in der Entwicklung.
• OpenNMS
  OpenNMS wird über Java RMI (Java Remote Method Invocation) angegriffen, das im Allgemeinen auf Port 1099 lauscht. PoC-Code ist bereits in ysoserial enthalten.

Stephen Breen hat PoC-Code auf GitHub veröffentlicht.

Und nun?

Patches gibt es bisher kaum, teilweise sind sie zumindest in Arbeit. Falls Ihre eigene Anwendung betroffen ist, sollten Sie die Schwachstelle korrekt beheben und bis es soweit ist potentielle Angreifer möglichst von der Anwendung fern halten. Wenn das denn geht.

Als Workaround schlägt Stephen Breen das rigorose Löschen alle möglicherweise betroffenen Dateien vor: Nachdem mit

grep -Rl InvokerTransformer .

alle .jar- und .class-Dateien gefunden wurden, die die verwundbare Library enthalten, sollen sie gelöscht werden. Ob die Anwendung danach noch einwandfrei läuft steht natürlich in den Sternen. Und auch wenn demnächst Weihnachten ist und Sterne eine beliebte Dekoration sind sollte man das vielleicht besser nicht ausprobieren. Falls Sie doch so mutig sind, nehmen Sie sich aber auch Stephen Breens zweiten Rat zu Herzen und testen Sie die zusammengekürzte Anwendung ausführlich.

Etwas gezielter ist Stephen Breens zweiter vorgeschlagener Workaround: Die bekannten Exploits basieren alle auf der Klasse InvokerTransformer. Wird die Datei

org/apache/commons/collections/functors/InvokerTransformer.class

aus allen jar-Dateien gelöscht, schlägt der Angriff fehl. Ob die Anwendung trotzdem funktioniert, sollten Sie aber ebenfalls sehr gründlich testen. Ich persönlich würde es aber nicht ausprobieren und stattdessen versuchen, betroffene Anwendungen vor möglichen Angreifern zu schützen. Aber leider wird es nicht in allen Fällen möglich sein, nur vertrauenswürdigen Benutzern Zugriff auf die betroffenen Anwendungen zu gewähren.

Wer hats verbockt? Oder: Bug oder Feature?

Der Übeltäter ist ja leicht auszumachen: InvokerTransformer. Aber ist das wirklich der Schuldige? Der ist so implementiert, dass er die übergebenen Daten nicht überprüft. Und das ist 1. mit Absicht so und 2. dokumentiert.

Hin zu kommt, dass sich darüber letzten Endes dann Code ausführen lässt. Was aber nicht möglich wäre, wenn nicht am Anfang entsprechende Anweisungen eingeschleust würden.

Also sind eigentlich die Entwickler Schuld, die InvokerTransformer mit ungeprüften Eingaben aufrufen. Denn es ist ja allgemein bekannt, dass man alle von einem potentiellen Angreifer manipulierbare Daten, insbesondere also alle Benutzereingaben, vor ihrer Verwendung auf Korrektheit bzw. Ungefährlichkeit prüfen muss. Kurz auch als "Traue nie dem Client!" umschrieben.

Wer auf die Prüfung der Eingaben verzichtet, fängt sich eine Schwachstelle ein. In diesem Fall eben die Deserialisierungsschwachstelle mit Codeausführung, anderswo wird es dann eben zum Beispiel ein Pufferüberlauf (in einem C-Programm) oder eine Remote File Inclusion (in PHP).

Nun ist es in diesem Fall in der Tat etwas schwierig, die Daten vor der Deserialisierung korrekt zu prüfen. Man kann zwar sicher stellen, dass es wirklich serialisierte Daten sind, was sich darin aber verbirgt erfährt man erst, wenn man sie deserialisiert hat. Man kann aber sicher stellen, dass nur die gewünschten Objekt-Typen erzeugt werden. Und man solle natürlich auch darauf achten, nicht blind irgend eine Methode auf irgend welche Objekte los zu lassen. Im Allgemeinen weiß man ja, welche Methode(n) erwünscht sind und welche Objekt-Typen man erwartet. Das muss dann eben auch geprüft bzw. sicher gestellt werden.

Übrigens ist es gar nicht so schwer, die Deserialisierung entsprechend abzusichern.

Carsten Eilers