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

[ Anmerkung des Herausgebers – Der Verkauf des NGINX ModSecurity WAF- Moduls für NGINX Plus endete offiziell am 1. April 2022 , und mit Wirkung zum 31. März 2024 wird es nicht mehr unterstützt . Weitere Einzelheiten finden Sie unter „F5 NGINX ModSecurity WAF wird eingestellt“<.htmla> in unserem Blog.]

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

Die Sicherheitslücke in der Anwendungsbibliothek Apache Struts ( CVE-2017-5638 ), die zum Diebstahl von 143 Millionen Konten bei Equifax führte, ist ein Beispiel für einen Exploit, der praktisch gepatcht werden kann. Das Kennzeichen der Sicherheitslücke ist das Vorhandensein der Zeichenfolgen #cmd= oder #cmds= in den HTTP-Headern „Content-Type“ , „Content-Disposition“ oder „Content-Length“ . (Weitere Einzelheiten finden Sie unten .)

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

SecRule REQUEST_HEADERS:Inhaltstyp|REQUEST_HEADERS:Inhaltslänge|REQUEST_HEADERS:Inhaltsdisposition "@rx #cmds?=" "id:5638,auditlog,log,deny,status:403"

Wir definieren die Regel mit SecRule und geben drei Parameter an:

1. Die zu suchenden Anforderungsheader in Form von drei REQUEST_HEADERS -Variablen, die durch ODER verknüpft sind
2. Der PERL‑kompatible reguläre Ausdruck (PCRE), wie durch @rx angegeben, der die angegebenen Anforderungsheader nach Zeichenfolgen durchsucht, die #cmd= oder #cmds= enthalten.
3. Die zu ergreifenden Maßnahmen

Wenn ModSecurity im aktiven Sperrmodus konfiguriert ist, wird jeglicher Datenverkehr gelöscht, der mit dem PCRE übereinstimmt, und somit die Regel ausgelöst.

Erfahren Sie mit unserem eBook, wie Sie NGINX und ModSecurity verwenden: ModSecurity 3.0 und NGINX: Kurzanleitung

Warum Virtual Patch?

In vielen Fällen ist es schneller, eine Regel in ModSecurity bereitzustellen, als den betroffenen Code zu patchen, erneut zu testen und dann in der Produktion bereitzustellen.

Betrachten Sie als Beispiel die Apache Struts-Sicherheitslücke: Da es sich bei Struts um eine Anwendungsbibliothek und nicht um ein Betriebssystempaket handelt, kann die Aktualisierung in einer Unternehmensproduktionsumgebung einige Zeit in Anspruch nehmen. Im Rahmen des Upgrades auf eine neue Version von Struts muss jede Struts-abhängige Anwendung neu erstellt und mit der neuesten Struts-Bibliothek getestet werden. Eine große Organisation verfügt möglicherweise über Hunderte von Anwendungen, jede mit ihrer eigenen Version der Struts-Anwendungsbibliothek. Dadurch ist sie angreifbar, bis jede einzelne Anwendung aktualisiert wird.

Wenn die benutzerdefinierte ModSecurity-Regel eingerichtet ist, können Sie die Produktionssoftware sorgfältig und nach einem angemessenen Zeitplan patchen, ohne dem Druck einer Anfälligkeit ausgesetzt zu sein. Sobald die gesamte betroffene Software aktualisiert ist, kann die benutzerdefinierte Regel außer Betrieb genommen werden.

So funktioniert der Exploit CVE-2017-5638

Bei Apache Struts CVE-2017-5638 handelt es sich um eine Sicherheitslücke bei der Remote-Befehlsausführung (RCE). Durch diese Art von Sicherheitslücke kann der Angreifer beliebige Befehle auf Zielsystemen ausführen, beispielsweise /bin/bash oder cmd.exe . Mit dieser Fähigkeit kann der Angreifer dann das Dateisystem und das Netzwerk nach vertraulichen Daten durchsuchen und verfügt dabei über dieselbe Zugriffsebene wie der Java-Anwendungsserver. Wenn der Java-Anwendungsserver beispielsweise als Root ausgeführt wird, verfügt der Angreifer über Root- Berechtigungen auf dem Zielsystem.

Laut dem offiziellen CVE tritt die Sicherheitslücke auf, wenn ein Angreifer einen fehlerhaften HTTP-Header vom Typ „Content-Type“ , „Content-Disposition“ oder „Content-Length“ sendet. Apache Struts löst eine Ausnahme aus, wenn diese HTTP-Header keinem der erwarteten Werte entsprechen. Das Problem tritt auf, weil der Ausnahmebehandlungscode versucht, den nicht maskierten, ungültigen Header zu drucken. (In diesem Kontext bedeutet „nicht maskiert“, dass den verdächtigen Befehlen keine Zeichen vorangestellt werden, die ihre Ausführung verhindern – Escape-Zeichen –, wie dies normalerweise beim Drucken von Code geschieht.)

Der Angreifer kann einen OGNL-Ausdruck ( Object Graph Navigation Library ) in den Content-Type- Header einfügen. OGNL kann Systembefehle ausführen. Wenn der nicht maskierte, ungültige Header gedruckt wird, wird der OGNL-Ausdruck ausgewertet und alle Systembefehle innerhalb des OGNL-Ausdrucks werden ausgeführt.

Exploits sind normalerweise eine Variation des folgenden Curl -Befehls.

curl -H "Inhaltstyp: %{(#_='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 Schlüsselsyntax befindet sich in der zweiten Hälfte des Befehls: jeweils eine Instanz der Zeichenfolgen #cmd= und #cmds= (oben hervorgehoben). Auf jede Zeichenfolge folgt der auszuführende Systembefehl.

Zusammenfassung

Die bevorzugte Lösung besteht immer darin, anfällige Software sofort zu patchen. Das Patchen von Produktionssoftware kann jedoch zeitaufwändig sein und überstürzte Aktualisierungen können riskant sein. Das Erstellen eines virtuellen Patches für anfällige Software mit ModSecurity kann Zeit gewinnen.

Mit virtuellem Patchen erstellen Sie eine benutzerdefinierte ModSecurity-Regel, um Datenverkehr zu blockieren, der die Sicherheitslücke (z. B. CVE-2017-5638) ausnutzen könnte. Auf diese Weise schützen Sie Ihre Site vor Angriffen. Sie können dann die Produktionsserver sorgfältig und innerhalb angemessener Zeitpläne patchen, ohne befürchten zu müssen, in der Zwischenzeit Opfer von Angriffen zu werden.

Wenn Sie mehr über ModSecurity und NGINX ModSecurity WAF erfahren möchten, laden Sie bitte unser eBook ModSecurity 3.0 und NGINX herunter: Kurzanleitung .

Ressourcen

• CVE-2017-5638 – Der offizielle CVE-Hinweis
• CVE-2017-5638: Anatomie der Apache Struts-Sicherheitslücke – Ein wertvoller Überblick über die Sicherheitslücke
• Apache Struts Security Bulletin S2‑045 – Apache Struts-Seite zur Sicherheitslücke mit einem Workaround
• Benutzerkommentar zum ArsTechnica-Forum Benutzerkommentar – Erklärung, warum das Patchen von Apache Struts nicht einfach ist

[Der Verkauf des NGINX ModSecurity WAF-Moduls für NGINX Plus endete offiziell am 1. April 2022 , und mit Wirkung zum 31. März 2024 wird es nicht mehr unterstützt . Weitere Einzelheiten finden Sie unter „F5 NGINX ModSecurity WAF wird eingestellt“<.htmla> in unserem Blog.]