Log4Shell Vulnerability is the Coal in our Stocking for 2021

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.

What can be done about this?

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.15.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 will be posting 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.