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 One IT Visibility and IT Asset Management can help you identify and remediate this vulnerability.
For the status of impacted Flexera products, please see this announcement.
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.
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
[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 Flexera One IT Visibility Can Help
IT Visibility customers can expect to see any detected installations of impacted Apache log4j products and/or releases in their inventory, providing the evidence already exists in our recognition library (note that any net new evidence may still need to go through the gap-fill process). As IT Visibility is powered by Technopedia, the detection of the impacted products in your inventory will provide a directional assessment as the version granularity may not corresponding directly to the vulnerabilities.
The capability to show the vulnerability information, however, is not currently available in IT Visibility. This is something that we’re actively working on to make available in the first half of 2022.
How Flexera One IT Asset Management Can Help
Similar to IT Visibility, IT Asset Management customers can also expect to see Apache log4j applications which are potentially impacted by this attack. Given the fact that applications granularity in the Application Recognition Library (ARL) is captured only at the major.minor version, further investigation may be needed to identify the subset of installations in their inventory with the exact build and/or patch levels.
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.
