Log4Shell Vulnerability: What We Know So Far

The critical flaw in the ubiquitous Log4j utility has sent shockwaves far beyond the security industry – here’s what we know so far.

Just as the holiday season is approaching our doorstep, a critical vulnerability in an Apache code library called Log4j 2 has come knocking at the door. Log4j is an open-source Java-based logging library that is widely used by many products, services and Java components. It’s little surprise that the flaw, which scored a perfect 10 on the CVSS scale and is putting countless servers at risk of complete takeover, has sent shockwaves far beyond the security industry.

Indeed, with proof of concept exploit code already available online, we’re now witnessing a mass race between hackers, who are conducting internet-wide scans and exploiting vulnerable systems, security defenders, who are updating systems and putting mitigations in place, and developers, who are auditing applications and code libraries for any dependencies that might include vulnerable versions of the Log4j library.

What is Log4Shell?

Indexed as CVE-2021-44228, the flaw is a remote code execution (RCE) vulnerability that allows an attacker to run code of their choice on an affected server. Should the adversary somehow get into the local network, even internal systems that are not exposed to the internet can be exploited. Ultimately, an RCE vulnerability means that an attacker doesn’t require physical access in order to run arbitrary code that could lead to complete control over affected systems and the theft of sensitive data.

Timeline

To help make sense of the events around this critical vulnerability, here is a basic timeline:

• November 26: The CVE ID for the vulnerability is reserved.
• December 1: The first known exploit of the vulnerability detected in the wild.
• December 10: The CVE ID is published and a patch is released.
• December 11: At 14:24 CET, ESET’s Network Attack Protection module received a detection update to cover this vulnerability.

December 13: Log4j version 2.16.0 released after the fix in version 2.15.0 was found to be incomplete and still put some systems at risk.

Detection

ESET has released a detection for exploits of this vulnerability that might be present in both incoming and outgoing traffic on Windows systems. Attackers attempting to move laterally from such systems will thus be blocked. Detection of exploit attempts was rolled out with the following detection names:

• JAVA/Exploit.CVE-2021-44228
• JAVA/Exploit.CVE-2021-44228.B

Mitigation Steps

In order to protect yourself from exploits, it’s critical to find all vulnerable versions of the library. Start by making a prioritized list of systems to search through, evaluating them one by one as you go through the list. The tricky part can be sniffing out vulnerable versions existing in Java Archive (JAR) archives as transitive dependencies.

Here are a few basic scripts that you can use (which should be modified to suit your systems):

Detect the Presence of Log4j in Your Systems (Linux and Windows)

This script, available on GitHub, searches for the flawed JndiLookup.class file in any .jar archive on your system.

Linux

• sudo grep -r –include “*.jar” JndiLookup.class /
• 1
• sudo grep -r –include “*.jar” JndiLookup.class /

Windows

• findstr /s /i /c:”JndiLookup.class” C:\*.jar
• 1
• findstr /s /i /c:”JndiLookup.class” C:\*.jar

Detect exploitation attempts of the vulnerability in your logs (Linux)

This script, also available at the GitHub link above, searches for exploitation attempts in uncompressed files in the Linux logs directory /var/log and all its subdirectories:

Grep

• sudo egrep -I -i -r ‘\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+’ /var/log
• 1
• sudo egrep -I -i -r ‘\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+’ /var/log

Zgrep

• sudo find /var/log -name \*.gz -print0 | xargs -0 zgrep -E -i ‘\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+
• 1
• sudo find /var/log -name \*.gz -print0 | xargs -0 zgrep -E -i ‘\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+

Record Results

After running any scripts or detection tools, make sure to record the results so as to help create complete audit documentation of all your systems. An audit should state whether you found Log4j on a system and whether there were any exploitation attempts discovered in the logs.

Move to the latest version of Log4j

The vulnerable versions of Log4j 2 are all log4j-core versions from 2.0-beta9 to 2.14.1. Note that this library is not to be confused with log4j-api, which is not affected by this vulnerability. The best remedy is to update your dependencies to use the latest version, which is 2.15.0. (UPDATE, December 15: The fix included in version 2.15.0 was found to be incomplete in certain non-default configurations and resulted in a new vulnerability (CVE-2021-45046), prompting the Apache Foundation to release version 2.16.0. We recommend applying the latest version.)

Although versions 1.x of Log4j are not impacted by this particular vulnerability, they do have other vulnerabilities. Concrete plans should be in place to migrate to the latest version of the library. In fact, now is as good a time as ever to move forward with those plans.

Block suspicious IP addresses

Finally, IP addresses that are known to be shady can be blocked with your firewall and/or intrusion prevention system.