Overview:
On December 9th, a vulnerability (CVE-2021-44228) was released on Twitter along with a POC on Github for the Apache Log4J logging library. The bug was originally disclosed to Apache on November 24th by Chen Zhaojun of Alibaba Cloud Security Team. The impact of this vulnerability has the potential to be massive due to its effect on any product which has integrated the log4j library into its applications. This includes products from internet giants such as Apple iCloud, Steam, Samsung Cloud storage, but thousands of additional products and services will likely be vulnerable. This is just the beginning as Java is heavily used in applications spanning nearly every industry.
What is it?
The vulnerability exists in the way the Java Naming and Directory Interface (JNDI) feature resolves variables. When a JNDI reference is being written to a log, JNDI will fetch all requirements to resolve the variable. To complete this process, it will download and execute any remote classes required. This applies to both server-side and client-side applications since the main requirements for the vulnerability are any attacker-controlled input field and this input being passed to the log.
To orchestrate this attack, an attacker can use several different JNDI lookups. The most popular lookup currently being seen in both PoCs and active exploitation is utilizing LDAP; however, other lookups such as RMI and DNS are also viable attack vectors. It’s worth noting that the simplistic LDAP/RMI attack vectors only work with older JDK versions. There are publications that have demonstrated methods to circumvent this limitation to achieve code execution, albeit with added complexity to the attack.
Java object deserialization vulnerabilities are not a new breed of vulnerabilities or attacks. Previous offensive research such as “marshalsec” can be applied to this vulnerability making code execution simplistic.
**Update 12/20/2021**
On December 18th, a new denial of service (DOS) vulnerability, CVE-2021-45105 was discovered affecting versions 2.0-alpha1 through 2.16.0 of Log4j. To mitigate the original Log4j vulnerability, Apache completely disabled JNDI lookups in version 2.16, however self-referential lookups remained a possibility under non-default configurations. When a nested variable is substituted by the StrSubstitutor class, it recursively calls the substitute() class. When this nested variable recursively references the variable being replaced, it leads to an infinite recursion and a DoS condition on the server. Current research shows this does not lead to code execution, like the previous vulnerabilities.
****
**Update 12/14/2021**
It has been confirmed that Log4j version 1.2 is vulnerable to similar attacks through the JMSAppender component and has been issued CVE-2021-4104. It is important to note this is not as easily exploitable as version 2.x. For exploitation to occur, JMSAppender must be enabled, and set with TopicBindingName or TopicConnectionFactoryBindingName configurations allowing JMSAppender to perform JNDI requests. This is not the default configuration.
****
What can be done about this?
**Update 12/20/2021**
Apache has released a new version of Log4j, version 2.17.0 to address the latest DOS vulnerability. Two additional classes were created that inherit from StrSubstitutor to deal with parsing strings that may contain user input. These additions do not allow recursive evaluation. Due to exploitation of this vulnerability leading to a DOS, it is considered less critical than the previously reported Log4j vulnerabilities which can lead to remote code execution. It is important to note, for exploitation to be successful there are several non-standard conditions that need to be met. As the Log4j situation is continuing to evolve, we recommend upgrading to version 2.17.0, where possible.
*****
**Update 12/14/2021**
Apache has released a new version of Log4j, version 2.16.0. This update disables JDNI by default requiring a user to explicitly turn the JNDI feature on and completely removes support for message lookups. When considering mitigations strategies for the Log4Shell vulnerabilities this should be considered the preferred method of mitigation.
****
There is a lot of information about different ways to mitigate this vulnerability. The most important and complete mitigation is to update log4j to the stable release version 2.17.0. Some sources are reporting that Java versions 6u211, 7u201, 8u191, and 11.0.1 are not vulnerable to this attack. This is not entirely the case. These versions are more resilient to the LDAP attack vector; however, they do not completely mitigate the vulnerability and are still susceptible to attack. To determine if a Java application is running a vulnerable version, a list of the impacted JAR files can be determined based on the hashes linked here.
The McAfee Enterprise ATR (Advanced Threat Research) team has been closely tracking this vulnerability since it became known. Our initial goal was to determine the ease of exploitation using the public PoC, which we have reproduced and confirmed. This was done using the public Docker container, and a client/server architecture leveraging both LDAP and RMI, along with marshalsec to exploit log4j version 2.14.1. We have posted a short video to demonstrate the reproduction for anyone who is struggling with this.
Going forward we plan to test variations of the exploit delivered using additional services such as DNS. We may update this document accordingly with results.
In the meantime, McAfee Enterprise has released a network signature KB95088 for customers leveraging NSP (Network Security Platform). The signature detects attempts to exploit CVE-2021-44228 over LDAP. This signature may be expanded to include other protocols or services, and additional signatures may be released to complement coverage.
Full coverage for this vulnerability can be tracked from our Security Bulletin here.
What’s out there?
Resources for the issue continue to evolve and expand rapidly. A growing list of PoCs and tools can be found here:
https://github.com/tangxiaofeng7/apache-log4j-poc
https://github.com/christophetd/log4shell-vulnerable-app
https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
https://www.greynoise.io/viz/query/?gnql=tags%3A%22Apache%20Log4j%20RCE%20Attempt%22
https://rules.emergingthreatspro.com/open/
https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes
About the Author
Steve Povolny
Steve Povolny is the Head of Advanced Threat Research for McAfee Enterprise, which delivers groundbreaking vulnerability research spanning nearly every industry. With more than a decade of experience in network security, Steve is a recognized authority on hardware and software vulnerabilities, and regularly collaborates with influencers in academia, government, law enforcement, consumers and enterprise businesses ...
Read more posts from Steve Povolny
Douglas McKee
Douglas McKee is a Principal Engineer and Senior Security Researcher for the Advanced Threat Research team, focused on finding new vulnerabilities in both software and hardware. Douglas has an extensive background in vulnerability research, penetration testing, reverse engineering, malware analysis, and forensics and throughout his career has provided software exploitation training to many audiences, including ...
Read more posts from Douglas McKeeCategories: McAfee Enterprise ATR