Identifying Apache Log4j JNDI Vulnerability “Log4Shell” and Variants (CVE-2021-44228, CVE-2021-45046, CVE-2021-45105, CVE-2021-4104)

Resnofendri
Level 7 Flexeran
Level 7 Flexeran
3 0 1,480

Recently, a vulnerability within Apache Log4j caught widespread public attention and has security, operational and development teams alike scrambling for analyzing the impact within their own eco system and to apply mitigations if necessary. The wide use of Log4j and the ease of the exploitation of the vulnerability makes this vulnerability very suitable for quick and effective use within exploitation campaigns. Shortly after publication of the vulnerability Proof of Concepts (PoCs) and reports of exploitation began to arrive. 

Various teams across different Flexera solutions have been working overtime to ensure that our customers get immediate visibility on the impact of this and other vulnerabilities. This article is intended to help explain how Flexera Data Platform (with Technopedia) can help you identify and remediate this vulnerability.

For the status of impacted Flexera products, please see this announcement.

 

How Flexera Data Platform (with Technopedia) Can Help

Affected products may be detected in your inventory to provide a directional assessment. This can help you determine where to look closer, but a definitive vulnerability status may not be possible due to a lack of version granularity depending upon the application in question.

Data Platform customers can expect to see:

  • All impacted Apache log4j products and/or releases are captured in Technopedia
  • Any existing discovered data (a.k.a. evidence) that maps to the impacted products and/or release are recognized. Note that any new evidence that customers bring in their inventory may still need to go through the gap-fill process.
  • If the entitlement to InfoSec Content Pack is active:
    • impacted products will be identified with any CPE’s associated with the impacted products and/or releases are linked
    • up-to-date Secunia Advisory information linked to the available CPE’s is provided 
    • CVE references associated with the vulnerabilities. The publication is dependent upon review/approval by the National Vulnerability Database (NVD).
    • threat intelligence associated with the advisory (as provided by Flexera’s Secunia Research)
  • If the entitlement to Lifecycle and Support Content Pack is active:
    • lifecycle dates (EOL and/or Obsolete dates) for Apache log4j releases which can help you determine supported versions and the upgrade path(s)

 

Vulnerability Details

The Beginning (Remote Code Execution, CVE-2021-44228)

To have a look at how the vulnerability works, we must look at the Log4j functionality of lookups. Essentially, this functionality allows values to be added to the Log4j configuration [1]. One part of the functionality allows JNDI lookups where multiple protocols are supported – one being LDAP. If an attacker can control parts of what gets logged, then arbitrary code might be downloaded from an attacker-controlled LDAP server (or other JNDI endpoints). The request for the download will be initiated from your own system. Such control is not uncommon, just think about servers logging User-Agent HTTP headers, usernames or chat messages from chat interfaces.

A logged string may contain something like the below string and an attack will potentially go ahead.

Snag_1511da1c.png

This vulnerability affects Apache Log4j versions prior to 2.15.0 and can be referenced via the CVE identifier CVE-2021-44228.

Thread Context Map - Incomplete Fix (Remote Code Execution, CVE-2021-45046)

However, the fix for CVE-2021-44228 in version 2.15.0 is incomplete, which led to the acknowledgment of a further vulnerability that is exploitable in certain configuration scenarios [3]. Essentially, exploitability relies on the use of a non-default Pattern Layout with a Context Lookup and where an attacker has control over Thread Context Map (MDC) input data.

Said variant received the additional CVE identifier CVE-2021-45046. This vulnerability is fixed in version 2.16.0 of Apache Log4j.

Initially, the vulnerability was only expected to be exploitable to result in a Denial of Service (DoS) impact and was rated with a lower severity, but Apache revisited their analysis and admitted that arbitrary code execution is possible [4].

Thread Context Map – The Sequel (Denial of Service, CVE-2021-45105)

The story could have ended there, but, unfortunately, a further vulnerability has been acknowledged shortly after [5].

The vulnerability, associated with the CVE identifier CVE-2021-45105, has a lower impact, namely, its remote exploitation through Thread Context Map data results in a Denial of Service (DoS) condition solely. The issue results from an uncontrolled recursion when handling self-referential lookups and causes a stack overflow and process termination in the end.

The Apache Log4j team has released the version 2.17.0 to fix this CVE.

To note, Apache also released versions in the 2.3.x and 2.12.x branches even though the Apache Log4j team doesn’t support the Java 6 and Java 7 platforms anymore. Users of Log4j need to keep in mind, that such lack of support will result in unfixed security issues down the road and thus can hardly be recommended.

End of Life Branch – The Prequel? (Limited Vector Code Execution, CVE-2021-4104)

Even the Log4j 1.x version branch, which is End of Life (EOL) though, could be exposed to a similar exploitation scenario like the original vulnerability in the 1.2 version. However, the vector is severely more limited as the JMSAppender needs to be used by an application and any potential attacker needs write access to the Log4j configuration [2]. Typically, such write access will be restricted to privileged persons when following security best practices and thus will likely result in a lower risk from this specific variation of the vulnerability.

This variation affecting Apache Log4j version 1.2 can be referenced via the CVE identifier CVE-2021-4104 and also is referred to as “Log4Shell”.

Keep in mind, that using any product version that is EOL constitutes a large risk on its own as security issues won’t get fixed. The recommendation, as always, is to upgrade any EOL versions to a supported and secure product version.

References

[1] https://logging.apache.org/log4j/2.x/manual/lookups.html

[2] https://mail-archives.apache.org/mod_mbox/www-announce/202112.mbox/raw/%3C1a5a0193-71c4-0613-ca92-f5...

[3] https://lists.apache.org/thread/83y7dx5xvn3h5290q1twn16tltolv88f

[4] https://logging.apache.org/log4j/2.x/security.html 

[5] https://lists.apache.org/thread/6gxlmk0zo9qktz1dksmnq6j0fttfqgno

 

How Other Flexera Solutions Can Help

To see how other Flexera solutions can help customers get immediate visibility on the impact of this and other vulnerabilities, please go this main article on the Community Hub where you can find the complete detail across all Flexera solutions.