Log4Shell Vulnerability is the Coal in our Stocking for 2021

By Steve Povolny and Douglas McKee · January 19, 2022

Overview

On December 9, 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 24 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, including products from internet giants such as Apple iCloud, Steam, Samsung Cloud storage, and thousands of additional products and services. This is just the beginning as Java is heavily used in applications spanning nearly every industry, but there are precautions and strategies businesses can employ like proactive protection to build resiliency and safeguard against these more modern and prevalent threats.

What is it?

The vulnerability exists due to the way the Java Naming and Directory Interface (JNDI) feature resolves variables. When a JNDI reference is written to a log, JNDI fetches all requirements to resolve the variable. To complete this process, it downloads and executes 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.

How it is evolving + what is being done

• On December 14, it was confirmed that Log4j version 1.2 is vulnerable to similar attacks through the JMSAppender component and was issued CVE-2021-4104. It is important to note this is not as easily exploitable as versions 2.0-alpha1 through 2.16.0. 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.

Following this confirmation, Apache released a new version of Log4j, version 2.16.0. This update disabled JDNI by default requiring a user to explicitly turn the JNDI feature on and completely removed support for message lookups.

• Then, on December 18, 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.0, 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.

From here, Apache released a new version of Log4j, version 2.17.0, to address the latest DoS vulnerability. Two additional classes were created from StrSubstitutor to manage 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.1, where possible, in addition to taking this time to review overall security strategies and practices as we embark on this new year.

A positive outlook ahead

There is a lot of information about different ways to mitigate this vulnerability, with the potential for humans and machines to learn and adapt together in an always-on way. As threats become more dynamic, strategies and processes need to as well to ensure business operations are optimized and protected. Log4j represents an actionable opportunity for businesses to shift from thinking about threats as an inevitable detriment, and instead view them as an opportunity for growth, learning, and adaptation to build resiliency and a business advantage moving forward.

We have been closely tracking this vulnerability since it became known, as we recognize how critical it is for security to be a living entity to keep pace with fast-evolving threats like Log4j. 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.

Going forward we plan to test variations of the exploit delivered using additional services such as DNS. In the meantime, We have 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.

Looking for more resources?

Full coverage for this vulnerability can be tracked from our Security Bulletin here and a growing list of PoCs and tools can be found here:

• https://github.com/pedrohavay/exploit-CVE-2021-44228
• 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
• https://github.com/corretto/hotpatch-for-apache-log4j2
• https://github.com/nccgroup/log4j-jndi-be-gone