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 FlexNet Manager can help you identify and remediate this vulnerability.
For the status of impacted Flexera products, please see this announcement.
Vulnerability Details
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.
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].
To note, Apache also released a version 2.12.2 based on Java 7 even though the Apache Log4j team doesn’t support the Java 7 platform 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.
Even the Log4j 1.x version branch, which is End of Life (EOL) though, could be exposed to a similar exploitation scenario 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
How FlexNet Manager Can Help
FlexNet Manager customers can 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.
