Following the discovery of the vulnerability CVE-2021-44228, known as “Log4Shell”, the Apache Foundation confirmed an additional flaw that affects the supposedly patched version of Log4J2 (2.15.0), resulting in a new officially documented vulnerability CVE 2021-45046 that reports the possibility of using malicious input data through JNDI Lookup patterns, resulting in a denial of service (DOS) attack. The promptly released version Log4j2 2.16.0 also fixes the latter!
Please note that the below article already suggested the installation of the latest version:
The world now faces a new critical zero-day exploit that operates on the most popular logging library of the Java ecosystem: Log4j2, the second version of the notorious Java library. As a consequence, Advantio’s own ZeroRisk Scoring Engine is now including a plugin capable of testing your public assets against this vulnerability.
In certain conditions, attackers can leverage vulnerabilities that allow remote execution of code without authentication mechanisms. Technically, the library can’t protect against attackers making use of remote LDAP and JNDI endpoints to execute malicious code remotely onto systems running Log4j2 when message lookup substitution is enabled.
The exploit has been officially documented as a CVE-2021-44228 with the maximum CVSS score of 10 which makes this exploit highly resonating in the industry. Also known by the code name of "Log4Shell", this exploit is also particularly concerning considering the wide adoption of the Log4j2 library in the programming ecosystem.
Java developers of the past two decades might remember the Log4j library before it officially became a project of the Apache Software Foundation and standard-de-facto for logging in a Java-based IDE. Its version 2 was released in 2014 and introduced a series of improvements, particularly in the field of Asynchronous Logging. Generally speaking, any developer with any Java experience is familiar with Log4j.
What Log4j2 versions are affected by the Log4Shell and how to remediate?
In practice, all versions of Log4j are affected including version 1 (which should be deprecated in favor of version 2 as it contains additional attack vectors and is officially EOL).
Version 2 (Log4j2) is affected up until version 2.15.0 which contains the corrected code. Apache also released version 2.16.0 in a stable branch and we suggest you upgrade immediately to this version (also available via maven repository.)
In theory, remediation should be seamless in most cases as it simply implies an upgrade that contains full backward compatibility. In other cases, the impact might be elevated as software needs to be adapted once the library is upgraded to a secure version.
Additionally, common Java development frameworks like Spring might contain ad-hoc guidance. Finally, for versions higher or equal to 2.10, the vulnerability can be mitigated without upgrading as per official guidance. For example, our ZeroRisk Scoring Engine is fully capable of identifying the Log4Shell vulnerability in your public assets so that remediation activities are facilitated.
You may be interested to know, security monitoring and active protection mechanisms such as Web Application Firewalls should play an equally important role to ensure systems are not targeted by malicious vectors. In this case, the attack vectors should be blocked with the definition of dedicated signatures.
Which systems are affected?
We need to consider any system directly using Log4j2 (and even indirectly) could be affected, despite existing technical testing that may say otherwise. We also need to consider the chance that Log4j2 is also used as a core component for third-party libraries in an organization’s software. Thus, a thorough analysis of all software dependencies is mandatory to ensure a comprehensive resolution is applied. Java being a widely used technology for empowering software in all sectors, from fintech to safety-critical environments and medical devices, the vulnerability must be seriously and promptly addressed.
How can Advantio help?
Our experts have defined a lightweight assessment to quickly make sure your systems are not affected by this vulnerability. We run our assessments which also leverage the use of our ZeroRisk Scoring Engine, a solution that will support you along the remediation path efficiently and quickly. Please contact us should you need our support on this topic.