0-day exploit on a popular Java logging library.

First released by Sun Microsystem in 1995, Java is a popular programming language and reliable computing platform on which many applications and services are built. One of the most popular logging packages for Java is Apache Log4j 2.x and it was subject to a 0-day exploit (CVE-2021-44228) which allows for remote command execution (RCE) by logging a certain string.

Table of Contents

• Is it really that serious?
• How does it work?
• Does it apply to me?
• I don’t have any Java applications on my infrastructure, should I be concerned?
• How to fix it
• How to test it
• What could be done to systematically manage this type of vulnerability in the future?

Is it really that serious?

The impact of this vulnerability is quite high but hard to quantify, given it’s one of the most used libraries on Java enterprise software, and how strict their deployment/infrastructure are, how easy it is to exploit, and the possibility of full server control. As an example, it was found in Minecraft servers which allowed the commands to be typed into chat logs as these were then sent to the logger. More details on the vulnerability are available here. Over the next days/weeks it’s expected to see an increase of attacks — botnets, servers takeover, ransomware, etc…

How does it work?

A malicious user will input an evil payload on an HTTP request that must be logged, forcing the vulnerable version of Apache Log4J to connect using Java Naming and Directory Interface (JNDI) and execute a query to a Lightweight Directory Access Protocol (LDAP) instance and download a malicious Java class to the Log4J server.

Credits: Fastly

Not only an RCE vulnerability

Log4J lookups not only allow for JNDI lookup, which means that several data can be extracted from the host executing the Java application. For example, it allows for Environment, Spring Boot, Main Arguments, etc… lookups. A malicious user can extract any environment variables values, e.g. cloud provider credentials.

Does it apply to me?

The vulnerable versions of Log4J are versions 2.0 to version 2.14.1 inclusive. The first fixed version was 2.15.0 but it was found that it was incomplete in certain non-default configurations. The new patched version is 2.16.0, which removes support to message lookup patterns and disables JNDI functionality by default. Earlier versions of Log4J also have vulnerabilities and as a library are end of life, so should be upgraded away from a security and dependency best practice. Even if you think you don’t use Log4J, or that you don’t have any Java applications you should have a look over your software inventory and look for these hashes. Also, according to LunaSec, some JDK versions are not affected by the LDAP attack vector due to com.sun.jndi.ldap.object.trustURLCodebase being by default false — JNDI cannot load remote code using LDAP. Nonetheless, RCE can still be a possibility by using other attacking vectors through this vulnerability.

I use SLF4J API instead of Log4J

SLF4J is just an API to let messages go through, so if Log4J is being used then SLF4J does not mitigate this vulnerability.

I use Logback, am I affected?

Logback recently released version 1.2.8, which disables all JNDI lookup JDBC code, even though a successful RCE would need all the following conditions to be met:

• Write access to logback.xml.
• Use of versions < 1.2.8.
• Reloading of poisoned configuration data (needs application restart or scan=true, set prior to attack). More details here and here.
  

I don’t have any Java applications on my infrastructure, should I be concerned?

Yes, you should. Given how popular Java is, it’s very likely you might be running a Java software on your infrastructure that contains an affected version of Apache Log4J.

Vendors

• AWS
• Atlassian
• Cisco
• cPanel
• Debian
• Docker
• MongoDB
• Okta
• Red Hat
• VMware
• Ubiquiti
• Ubuntu
• Zscaler
  

A more complete list can be found here.

Tools

At the time of writing, the following tools may still be affected by this vulnerability (even the latest versions):

• Apache Struts
• Apache Flink
• Apache Solr
• Apache Druid
• MyBatis
• Spring Boot Starter Log4J
  

A more extensive list is being updated here and here.

Containers

The most popular container platform is Docker. Some insights have been shared about this Apache Log4J CVE:

The configuration for the docker scan command previously shipped in Docker Desktop versions 4.3.0 and earlier unfortunately do not pick up this vulnerability on scans. Please update to Docker Desktop 4.3.1+ with docker scan 0.11.0+, which we released today, 11 December 2021.

So if you are running a version of Docker <= 4.3.0 you need to update and reschedule a scan for all your container images.

Container images

At the time of this writing some of the listed container images below may still contain vulnerable versions of Log4J:

• Couchbase
• Elasticsearch
• Flink
• Geonetwork
• Lightstreamer
• Logstash
• Neo4j
• Nuxeo
• Solr
• Sonarqube
• Storm
• XWiki
  

How can I search for Log4j usages?

You can use several approaches here, either by listing the dependencies on your project or manually checking for any Log4j usage. Or you can use some specific tools (like log4shell scan) that use hashes of known vulnerable Log4j classes.

On an infrastructure, look for several patterns on the existing logs and thoroughly analyse each possible (attempt) attack.

Read here for more detailed information.

How to fix it?

Before applying any possible fix that you find, be mindful that it might be outdated or wrong and it will still leave you vulnerable to attacks. Always double-check and test it locally, if possible. A curated list of common bad advice is available here.

We strongly encourage you to update to the latest version if you can: https://logging.apache.org/log4j/2.x/download.html

The other options available while you upgrade the dependency are:

• Disable JNDI lookups in log4j versions >= 2.10.0, by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
• On versions < 2.10.0, remove the JndiLookup class from the classpath.
  

What not to do

• Apply a rule in your web application firewall (WAF). You are still susceptible to nested payloads.
• Update every logging pattern to have %m{nolookups} instead of %m on logging config files.
  

How to test it?

Details on how to test this vulnerability are available here.

What could be done to systematically manage this type of vulnerability in the future?

This vulnerability is a dependency management challenge mainly, as there are also transient dependency challenges to mitigate this risk.

Bots that check dependencies automatically:

• Renovate
• Dependabot
  

Sources:

• https://www.lunasec.io/docs/blog/log4j-zero-day/
• https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide/
• https://www.randori.com/blog/cve-2021-44228/
• https://www.fastly.com/blog/digging-deeper-into-log4shell-0day-rce-exploit-found-in-log4j
• https://www.docker.com/blog/apache-log4j-2-cve-2021-44228/
• https://snyk.io/blog/log4j-rce-log4shell-vulnerability-cve-2021-4428/
• https://success.trendmicro.com/solution/000289946
• https://www.bleepingcomputer.com/news/security/log4j-list-of-vulnerable-products-and-vendor-advisories/
• https://www.tomitribe.com/blog/cve-2021-44228-log4shell-vulnerability/
• https://threatpost.com/zero-day-in-ubiquitous-apache-log4j-tool-under-active-attack/176937/
• Second most used Programming language according to August 2021 PYPL Index (https://statisticstimes.com/tech/top-computer-languages.php)