Log4j Security Vulnerabilities, from Version Checks to Workarounds

Announcing the December 30 Log4j security vulnerability and sharing measures to tackle the problem

We are sharing the following Log4j security vulnerabilities announced on December 30th.

CVE-2021-45105: 2.0-beta9 through 2.16.0 versions (except Log4j 2.3.1, 2.12.3)
CVE-2021-44832: 2.0-beta9 through 2.17.0 versions (except Log4j 2.3.2, 2.12.4)

The above vulnerabilities can be remediated as follows.

Java 8 and later: Update to Log4j 2.17.1
Java 7: Update to Log4j 2.12.4
Java 6 : Update to Log4j 2.3.2

* If you use only log4j-api-*.jar file without log4j-core-*.jar file, you are not affected by the above vulnerability.

If a new update is not possible, you can apply the following workaround (CVE-2021-45105 only)

Change ${ctx:loginId} or $${ctx:loginId} to (%X, %mdc, or %MDC) in PatternLayout

Remove ${ctx:loginId} or $${ctx:loginId}

Introduction

Hi, I am Becky from WhaTap Labs. In the previous post, we have briefly introduced vulnerabilities in Log4j and how to identify them.

Since then, you may have seen news that the latest version of Log4j is also vulnerable to bypass attacks, and Becky will summarize what new mitigations are available.

What is Log4j and why is it at risk?

Log4j is a JAVA-based open-source utility that is widely used in enterprise applications and websites. It keeps a record of everything that happens in the course of a service's behavior. We use Log4j to check for breaches and anomalies.

This Log4j vulnerability starts with the Java Naming and Directory Interface (JNDI) and the Lightweight Directory Access Protocol (LDAP). JNDI is an interface that has been added to Java since the late 1990s. It is a directory service that allows Java programs to find data through directories.

Java programs can find Java objects through the aforementioned JNDI and LDAP. To make it easier for the Log4j in question here, certain syntaxes are used to view Java objects. These syntaxes are also available when logs are written. Hackers can find where logs are logged and exploit vulnerabilities.

Log4j vulnerability versions and how to check them

For each vulnerability, the affected Log4j versions are slightly different. According to the December 13 announcement, Log4j versions 2.0-beta9 through 2.14.1 (with the exception of 2.12.2) and down to 1.x. were affected. However, on December 15, it was announced that the newest version, 2.15.0, is also at risk if a bypass attack is made.

1.CVE-2021-44228: Remote code execution vulnerability in Apache Log4j 2 (Log4j 2.0-beta9 through 2.14.1, excluding 2.12.2)

2.CVE-2021-45046: Denial of Service Vulnerability in Apache Log4j 2 (Log4j 2.0-beta9 through 2.12.1 and 2.13.00 through 2.15.0)

3.CVE-2021-4104: Remote Code Execution Vulnerability in Apache Log4j 1.2 (Log4j 1.x)

Some people downgrade from Log4j 2.x to 1.x because the above version is vulnerable. Log4j 1.x has been out of technical support since 2015, and downgrading will not provide you with technical support, but rather increase your chances of being exposed to security threats. If you are reading this, we strongly recommend that you upgrade your version.

You can check if you are using a vulnerable version of Log4j in the following ways

1. You can find information about the product you are using Log4j on here.

https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

2. Check if log4j is installed on Linux: You can type the command below. You can also check the log4j-core version in this way.

- find / -name 'log4j*'

3. Check if log4j is installed on Windows

4. You can also use public tools.

a. How to use Syft and Grype tools: https://github.com/anchore/grype

b. How to use a vulnerability scanner: https://github.com/logpresso/CVE-2021-44228-Scanner

5.If you are a WhaTap user, you can check it more easily.

You can check it in [Application] → [Agent Settings] under [Library version] feature. Try searching for log4j-core

b. Alternatively, you can also try opening your application's pom.xml or gradle.build file and searching for log4j-core

Log4j version-specific workarounds

First, it is best to update to the latest version, you can find the latest version at Download Apache Log4j 2.

*The latest version of Log4j was changed as of the date the blog content was published. Log4j 2.17.0 vulnerabilities may also be found, so please check and update the latest version information from time to time.

You can check the latest version at https://logging.apache.org/log4j/2.x/download.html .

However, it may not be practical to update and revalidate the library in a short period of time, so you can take the following preemptive measures depending on your version

1. For Log4j versions from 2.0-beta9 to 2.10.0: You can remove JndiLookup from log4j-core. Executing the command below in the library path will remove JndiLookup.class.

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

2. If your Log4j version is 2.10 through 2.14.1: set the lo4j2.formatMsgNoLookups or LOG4J_FORMAT_MSG_NO_LOOKUPS environment variable to true.

3. How to limit JndiLookup functionality with JVM options: Run the application with the option -Dlog4j2.formatMsgNoLookups=true.

java -Dlog4j2.formatMsgNoLookups=true -jar myapp.jar

4. If your Log4j version is 1.x: You can modify or delete the code after checking to use JMSAppender.

Closing thoughts

I am sure many IT people are worried that even the latest version of Log4j is vulnerable to bypass attacks. As a SaaS service provider in the same industry, WhaTap Labs is also following the situation closely.

WhaTap is not related to the Log4j security vulnerability.