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.
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.
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.
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.
Webinar:
Log4Shell Vulnerability
Find + Fix + Verify
For adversaries, Christmas has come early and Log4Shell is their golden goose. Hackers are discovering multiple ways to use this vulnerability to gain access to your network like never before.
Snehal Antani and Anthony Pillitiere of Horizon3.ai will join moderator David Raviv of New York Information Security Group to discuss this new threat on the cybersecurity landscape and how you can use a find + fix + verify approach to prioritize your log4j remediations and get back to enjoying the holiday season.
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.
Additional Resources
- Understanding Log4Shell: the Apache log4j2 Remote Code Execution Vulnerability (CVE-2021-44228)
- Apache Log4j Vulnerability Guidance
- log4j-jndi-be-gone: A simple mitigation for CVE-2021-44228
- CVE-2021-44228 – Zero Day Vulnerability in Apache Log4j That Allows Remote Code Execution (RCE)
- The Log4Shell 0-day, four days on: What is it, and how bad is it really?
- Guidance for preventing, detecting, and hunting for CVE-2021-44228 Log4j2 exploitation
- Log4Shell explained – how it works, why you need to know, and how to fix it
- BlueTeam CheatSheet *Log4Shell*
- Zero-Day Exploit Targeting Popular Java Library Log4j
- Log4j overview related software
- Log4j RCE 0-day actively exploited
- Apache Log4j2
- CVE-2021-44228 Apache Log4j RCE Attempts Dec 14th 10:58AM ET
