Log4Shell:

Critical Vulnerability that Enables Remote Code Execution

Overview of Log4Shell

Apache log4j is one of the most widely used Java logging libraries. The vulnerability assigned as CVE-2021-44228 (along with CVE-2021-45046) is easily exploitable and allows attackers to run their code on your server.

Countless applications are built with Java components that range from critical infrastructure like VMware products to other open-source projects like Apache Solr, Apache Druid, and many more.

Nearly any input that is eventually logged by a log4j2 logger will interpret the user input, causing the application to reach out to a malicious JNDI server and potentially execute arbitrary Java code. Just as “Java is the language of possibilities,” Log4Shell is the vulnerability of possibilities.

Read Blog

Using NodeZero to Find and Fix Log4Shell

Some vendors, like VMware and Cisco, have had to issue advisories for dozens of affected products. A variety of security tools have come up in the last few weeks to assist companies in remediating Log4Shell. Most of these tools stop at the point of detecting Log4Shell, with varying degrees of accuracy. NodeZero detects if an application is vulnerable by checking for DNS requests originating from the application. In this recent Red Team blog, you’ll find an example of inducing a DNS request from a vulnerable VMware vRealize Operations Manager application.

Understanding Log4Shell

On November 30, 2021, the Apache log4j2 team became aware of a bug that would allow injection of malicious input that could allow for remote code execution. It was only on December 9 that the security community largely became aware of this finding and the far reaching impacts.

Read Blog

Log4Shell Attack Scenarios

We have narrowed it down to two separate attack scenarios, both which lead us to the same conclusion: we have work to do.

Download Details in PDF

External Attack

Consider an attack scenario where the adversary is using an Internet connection to access a web application. As we speak, attackers are engaging in a ‘spray and pray’ campaign. In other words, they are indiscriminately targeting online hosts for indications of log4j use. This indiscriminate fire comes in a couple varieties:

Form-Field-Fuzzing and http header manipulation:

In this scenario, they are using an LDAP server pre-loaded with an exploit the victim will ask for Discovery can be initiated by a mass targeting campaign using http header manipulation where a jndi query is included in the http header.

Entering a jndi lookup string into an existing user input field:

In this scenario, the attacker initiated the victim to reference the exploit. The vulnerable application will load the attacker’s exploit as intended, Java deserializes (downloads) the class and executes it…enabling the attacker to gain remote code execution (RCE) privileges on the host running the application.

Internal Attack

Once an adversary has gained access to your network, they can leverage Log4Shell to achieve lateral movement and Remote Code Execution (RCE). The potential impact of RCE on your internal network is very, VERY high.

This is where attackers achieve critical impacts. This is also where your crown jewels are used, often by critical Java-based third-party software components like WebSphere, CICS WebServices, Hadoop, Elastic, Atlassian, and numerous others — all of which may be vulnerable.

Moving and communicating laterally to inject malicious payloads and callouts from your enterprise is how an attacker establishes persistence and pervasiveness. You can run a NodeZero pentest to enumerate every host available and check for log4j2 java-based logging underlying your critical applications.

Assume Compromise

The first step in mitigation is conducting a thorough analysis of your network infrastructure. That’s why we pushed an update to NodeZero to detect and pentest Log4Shell in order to understand the depth of compromise.

Putting NodeZero to work is simple:

Set the scope of IP addresses, and NodeZero goes to work scanning and identifying your network hosts.
NodeZero enumerates all hosts in scope and identifies which ones are using log4j.
NodeZero executes a general fuzzing of HTTP headers, paths, and query parameters to check for Log4Shell vulnerability.
The NodeZero attack server will receive a request from you vulnerable hosts, which establishes a connection confirming the Log4Shell vulnerability.
The vulnerable application will load NodeZero’s exploit when Java deserializes (downloads) the object it requested.
Once the object is received and executed, it enables NodeZero to gain remote code execution (RCE) privileges on the target hosting the vulnerable application.

Customers can schedule a cooperative review with the Horizon3 AI Customer Success Team by emailing customer.success@horizon3.ai.

Run a Pentest

FAQ

What is my likelihood of being impacted by this?

Very high. The vulnerability assigned as CVE-2021-44228 (along with CVE-2021-45046) is easily exploitable. Nearly any input that is eventually logged by a log4j2 logger will interpret the user input, causing the application to reach out to a malicious JNDI server and potentially execute arbitrary Java code.

This means the potential for Remote Code Execution (RCE) is very, VERY HIGH.

What should I be looking for?

Identifying every application, device, and service using the log4j library is going to be an ongoing effort. This List of vendor advisories can be used to research applications known to use log4j and recommended patches and fixes.

What are my options?

1. REMEDIATE: Upgrade the Log4j library: If you are on Java 8 or later, upgrade to version 2.17. If you are on Java 7, upgrade to version 2.12.3. If you are on Java 6, upgrade to version 2.3.1.

2. MITIGATE: If you are unable to upgrade Log4j, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

If you are unable to rebuild your affected application(s) to upgrade Log4J or remove JndiLookup.class, seek vendor guidance on remediation/mitigation strategies. For general Log4j guidance, consult the Apache Log4j website.

Does NodeZero test for Log4Shell?

Yes. NodeZero sends a variety of crafted network requests to applications to induce the vulnerability. The vulnerability is detected through the presence of traffic back to NodeZero and Horizon3.ai servers. To gauge the severity of the vulnerability, NodeZero will try to exploit the vulnerability to gather proof that remote code execution is possible. We are continually adding new attack content to detect and exploit Log4Shell.

How can I verify we're protected?

Continue running penetration tests to fix exploitable weaknesses. If you have specific products you’re using with log4j, email us at customer.success@horizon3.ai and provide us your feedback so that we can effectively prioritize exploits and subsequent checks.

Security Strategies

Industry Insights

Attack Research

Attack Content