Pierluigi Paganini December 18, 2021

Multiple flaws in the Log4J library are scaring organizations worldwide while threat actors are already exploiting them. 2.17 is the third fix issued in a week.

While the experts were warning that threat actors are actively attempting to exploit a second vulnerability, tracked as CVE-2021-45046, disclosed in the Log4j library a third security vulnerability made the headlines.

Let’s analyze the timeline for the log4J vulnerabilities. The first vulnerability, tracked as CVE-2021-44228 (aka Log4Shell) made the headlines last week, after Chinese security researcher p0rz9 publicly disclosed a Proof-of-concept exploit it. The issue is a critical remote code execution zero-day vulnerability that affects the Apache Log4j Java-based logging library.

The impact of the issue is devastating, thousands of organizations worldwide are potentially exposed to attacks and security experts are already reported exploitation attempts in the wild.

Immediately after the disclosure of the exploit, Microsoft researchers reported that Nation-state actors from China, Iran, North Korea, and Turkey are now abusing the Log4Shell (CVE-2021-44228) in the Log4J library in their campaigns. Some of the groups exploiting the vulnerability are China-linked Hafnium and Iran-linked Phosphorus, the former group is using the flaw to attack virtualization infrastructure, the latter to deploy ransomware.

The Apache Software Foundation (ASF) quickly released a patch (Log4J 2.15.0 version) for the Log4Shell vulnerability (CVE-2021-44228), but this fix partially addressed the flaw in certain non-default configurations. An attacker with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) can craft malicious input data using a JNDI Lookup pattern triggering a denial of service (DOS) condition.

Both issues were addressed with the release of the Log4j 2.16.0 version that fixed the CVE-2021-45046 by removing support for message lookup patterns and disabling JNDI functionality by default.

“Hot on the heels of CVE-2021-44228 a second Log4J CVE has been filed CVE-2021-45046. The rules that we previously released for CVE-2021-44228 give the same level of protection for this new CVE.” states CloudFlare.”This vulnerability is actively being exploited and anyone using Log4J should update to version 2.16.0 as soon as possible, even if you have previously updated to 2.15.0. The latest version can be found on the Log4J download page.”

But the bad news were not ended, because researchers at security firm Praetorian warned of a third security vulnerability the Log4j version 2.15.0 that was released to fix the initial Log4Shell.

This third vulnerability can be exploited by attackers to exfiltrate sensitive data in certain circumstances.

“However, in our research we have demonstrated that 2.15.0 can still allow for exfiltration of sensitive data in certain circumstances. We have passed technical details of the issue to the Apache Foundation, but in the interim, we strongly recommend that customers upgrade to 2.16.0 as quickly as possible.” states the post published by Praetorian.

The Apache Software Foundation (ASF) was forced to release the third version in a week (version 2.17.0) to fix a ‘High’ severity Denial of Service (DoS) vulnerability in the log4j 2.16 tracked as CVE-2021-45105.

The CVE-2021-45046, initially rated as a low-severity (3.7), but yesterday its severity level was increased to a Critical-severity (9.0) by the Apache Software Foundation because experts found a new way to bypass the fix second fix released by the Foundation.

The CVE-2021-45105 vulnerability received a CVSS score of 7.5, it is a DoS flaw that impacts log4j 2.16. The experts pointed out that even if JNDI lookups were disabled in version 2.16, self-referential lookups remained a possibility under certain circumstances. 

“Apache Log4j2 versions 2.0-alpha1 through 2.16.0 did not protect from uncontrolled recursion from self-referential lookups,” reads the advisory published by ASF. “When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process.”

“Apache Log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3) did not protect from uncontrolled recursion from self-referential lookups. This allows an attacker with control over Thread Context Map data to cause a denial of service when a crafted string is interpreted. This issue was fixed in Log4j 2.17.0 and 2.12.3.” reads the advisory for this issue.

The Apache Software Foundation (ASF) fixed the CVE-2021-45105 flaw with the release of log4j version 2.17.0 (for Java 8).

Follow me on Twitter: @securityaffairs and Facebook

Pierluigi Paganini

(SecurityAffairs – hacking, Log4J)

[adrotate banner=”5″]

[adrotate banner=”13″]