Understanding Zero-day Exploit of Log4j Security Vulnerability and Solution (CVE-2021-44228, CVE-2021-45046)

Introduction

On 9th December 2021, an industry-wide vulnerability was discovered that specifically affect the Apache Log4j Java library.

The security vulnerability allows an attacker (Hacker) to achieve Remote Code Execution (RCE) on a host.

See the detailed Vulnerability CVE

What it Means

It’s important to note that Apache log4j is a Java package which indicates any platform/application using Java is potentially at risk. This is a fast moving exploit with exploit code being released in the wild after few days this vulnerability was found and Apache has now published a patch to remediate the vulnerability.

Affected Version and a Fix in Hurry

Following versions are affected:

2.0-beta9 <= Apache log4j <= 2.15.0

They initially suggested to migrate it to 2.15. But, as soon as they released. Next day, another security vulnerability popped up.

The Fix

Now, the safe version you need to move is: 2.16.0

The best way to mitigate from this vulnerability is to upgrade to 2.16.0.

If by any chance, you are not able to upgrade to this library version. It is recommended to ensure that you are setting a system property on both client side and server side:

log4j2.formatMsgNoLookups=true

What about People using 1.x

Note: This vulnerability is only affecting log4k library 2.0-beta9 <= Apache log4j <= 2.15.0 So, 1.x is actually safe. But, you should always plan to migrate to the latest libraries.

What was the Vulnerability

This could allows attackers 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 to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack.

Log4j 2.15.0 restricts JNDI LDAP lookups to localhost by default. Note that previous mitigations involving configuration such as to set the system property log4j2.noFormatMsgLookup to true do NOT mitigate this specific vulnerability. Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default. This issue can be mitigated in prior releases (<2.16.0) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).

Maven Libraries to use

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-api</artifactId>
    <version>2.16.0</version>
</dependency>
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.16.0</version>
</dependency>

Hurry Up

Companies are in hurry to fix this ASAP. As, they understand its impact. Almost, everybody is working on upgrading these libraries.

Resources

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046
• https://logging.apache.org/log4j/2.x/
• https://www.lunasec.io/docs/blog/log4j-zero-day/
• https://www.randori.com/blog/cve-2021-44228/
• Spring response
• https://logging.apache.org/log4j/2.x/security.html