RCE 0-day exploit found in log4j2

Introduction

There has been a new 0-day exploit discovered by Chen Zhaojun of the Alibaba Cloud Security Team. This exploit, CVE-2021-44228, is particularly alarming as it is within Apache Log4j2, a very popular logging platform used for Java.

What can happen with the log4j2 exploit?

There is functionality within Log4j2 that supports replacement of log entries through JNDI and LDAP. The log entries are templatized using variables that are replaced through lookups done in real time. This functionality does not have any protections in place to validate the data being entered.

Due to this, an attacker with access to an LDAP source that Log4j2 is connecting to can inject malicious code that has the potential for service interruption, data exfiltration, or even system takeover.

Who is affected by the log4j2 exploit?

Anyone running Apache Log4j2 version 2.14.1 or below. If you are running a Java application, it is worthwhile to review the package, either manually or through a package manager such as Maven, being used to verify if Log4j2 is being used, and if so, what version.

You may think you are not using Log4j2, but considering how ubiquitous it has become, it is worth the time to verify.

How do I remediate the log4j2 exploit?

The most effective solution is to upgrade to Log4j2 version 2.15.0 or above, but that can be a heavy lift and can take teams quite some time to complete. There are a couple of immediate steps that can be implemented more easily as shown below.

We recommend implementing one of these as soon as possible until upgrades are completed.

1. Setting the formatMsgNoLookups system property to True. The following option can be added to your JVM startup command:   -Dlog4j2.formatMsgNoLookups=True
2. You may remove the JNDI lookup functionality from the classpath. The path to the class is: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

How do I know if I’ve been exploited?

Review any and all logs that are created by your Java applications. Grep your logs for system commands such as ‘ps’, ‘bash’, ‘nc’, and ‘os’ that are used to probe that an exploit has functioned and is getting data back.

This is where the importance of log centralization and monitoring really comes into play. Without the ability to quickly and easily search across your logs, it is very difficult to be able to investigate scenarios such as this.

There are zero day exploits found fairly regularly, but to have one found in extremely popular, user controlled and managed software libraries is particularly frightening.

Please take the time to review your applications, ensure you are not affected by reviewing your log entries for anything unexpected, and patch your systems.