Log4Shell RCE Vulnerability in Apache Log4j: The Gift No One Wished For

Log4Shell, the bombshell RCE vulnerability in Apache Log4j, was the early Christmas gift nobody wanted. It was a far cry from the newest Mac Book or big screen TV that was on our wish list and more akin to an early visit from Krampus to deliver yet another itchy sweater from your mother in-law.

This wasn’t even a new gift. The vulnerability (CVE-2021-44228) dates to 2013 when Log4j 2.0-beta9 was released. The ubiquity of the Log4j framework in applications ranging from Elastic Search to Adobe, to AWS, to VMware, and thousands of other productivity-centric products and services, means this threat is one that web-connected businesses must assume is active. An analysis of our pentesting data using NodeZero, our autonomous pentesting platform,  identified and provided proof of exploit for over 105 unique instances of the CVE within our customers’ environments. Of these, over half were attributed to vulnerable instances of VMware vCenter, vRealize, and Horizon.

How Log4Shell Works

Outside of a few releases, Log4Shell affects any Java application using a version of the Apache log4j2 library from log4j 2.0-beta9 through 2.15.0. Attackers exploit a vulnerable application by passing crafted user input to it, hoping that the application will log that input. The crafted user input contains a special string of the form “${jndi:…}”. JNDI stands for Java Naming and Directory Interface. It’s a Java-specific abstraction used to query “naming” services on the network for resources like configuration.

When the application receives and logs malicious input from an attacker, the vulnerable log4j2 component performs a JNDI lookup and connects over the network to attacker-controlled servers. These servers return malicious commands to the vulnerable application in the form of serialized Java objects. When these objects are deserialized, the attacker-provided commands are executed, giving the attacker access to the application host.

Using NodeZero to Manage Log4Shell Risk

NodeZero helped them execute four steps to manage Log4Shell risk:

1. Identify all applications using vulnerable versions of log4j.
2. Test those applications to confirm exploitability.
3. Apply vendor suggested upgrades or patches.
4. Most importantly, verify that the remediation actually eliminates the risk.

This last step often gets overlooked. Organizations often put blind trust in vendor upgrades without further verification. They shouldn’t. A recent Log4Shell use case from one of our newest customers highlights how NodeZero proved the customer remained at risk of Log4Shell remote code execution, even after a seemingly successful Log4j2 remediation. 

Before NodeZero

This customer is a large digital marketing and print media business with a highly segmented network. While their IT team is small, they are very capable. As soon as news about Log4Shell broke last year, they did exactly the right thing and went on the offensive, proactively identifying and remediating Log4Shell using vendor specified updates and patches. In this instance, they reviewed the VMware advisory put out on December 10, 2021, which directed them to upgrade to a fixed version of VMware. At the time, they were not NodeZero customers but confirmed the patch did indeed provide them with protection from Log4Shell.

With NodeZero

The organization systematically deployed NodeZero to test their segmentation and network hardening.

In the first month alone, they ran eight autonomous penetration tests. Recently, the client started experiencing an issue with their hypervisor cluster. After troubleshooting, they upgraded VCenter to a later release which resolved all the issues they were having. Just as we preach time and again; whenever any change, update, or patch occurs in your network, one should immediately use NodeZero to verify the fix. That addressed steps 1-3 outlined above.

Step 4 – “I already fixed that. How can I still be at risk?”

We hear this from customers repeatedly. They complete steps 1-3 and believe they are done.

Not this customer.

The day after they patched, they ran a full pentest of their network of about 600 hosts and quickly identified that the recent upgrade introduced more exploitable vulnerabilities, including Log4j2 RCE, again. In hardening their network, the customer unknowingly reintroduced the vulnerability to their environment.

They quickly repatched their system and ran a quick verification pentest to confirm they were once again protected. Had they not used NodeZero, there is high likelihood they would have remained vulnerable and exploitable.

Teaming Up for Success

Horizon3.ai Customer Success Team and our newest client worked together securing their network. Here is the breakdown of events:

1. Client proactively remediated Log4j2 weakness immediately after news broke.
2. Client was protected for the last several months. 
3. Client installed a vendor specified update and unknowingly re-introduced the Log4Shell RCE vulnerability into their network.
4. Client ran a NodeZero pentest the next day, where NodeZero provided proof of VMware Horizon Log4Shell vulnerability and exploitation.
5. Client deployed patch management.
6. Client ran a verification pentest where NodeZero confirmed successful remediation.

If you run a patch, pentest. If you run an update, pentest. If you install new equipment, pentest. If you forgot the last time a pentest was ran, pentest. By partnering with Horizon3.ai you can do so quickly and cost-effectively. Like this customer, you can have the power of a nation-state level hacker in your back pocket.

Want to Learn More About Log4Shell?

Check out this blog post to learn how our customers use NodeZero to find and fix Log4Shell.