[Updated] Log4j zero-day “Log4Shell” arrives just in time to ruin your weekend

If you’re running a service that relies on Apache Struts or uses the popular Apache Log4j utility we hope you haven’t made plans for the weekend.

An exploit listed as CVE-2021-44228 was made public on December 9, 2021. The exploit is simple, easy to trigger, and can be used to perform remote code execution (RCE) in vulnerable systems, which could allow an attacker to gain full control of them. All an attacker has to do is get the affected app to log a special string. For that reason, researchers have dubbed the vulnerability “Log4Shell”.

The vulnerability has a CVSS score of 10.0 out of a possible 10. It impacts Apache Log4j versions 2.0-beta9 to 2.14.1. Mitigations are available for version 2.10 and higher.

Log4j is an open source logging library written in Java that was developed by the Apache Software Foundation. Millions of applications use it, and some of them are enormously popular—such as iCloud, Steam, and Minecraft—so the potential reach of this problem is enormous.

How it works (simplified)

A logger is a piece of software that keeps a record of what’s happed on some part of a computer system. Logs can be used to determine if software is running smoothly, or to investigate events leading up to an error if something goes wrong. Generally speaking, IT and security folks want to log as much as they can.

As is the case for many loggers, Log4j also performs some basic operations to make the output easier to understand for us mere humans. One of these operations is variable substitution, which look for patterns like ${something}, and replaces them with other pieces of information.

This vulnerability lies in the replacement of the string ${jndi: This pattern triggers the Java Naming and Directory Interface, which can load Java resources from another computer, anywhere on the Internet.

Unfortunately, lots of applications log data that comes from their users without first sanitising it, and it’s possible for attackers to sneak variable substitution patterns into logs by including them in things like HTTP headers, or input fields.

The vulnerability is triggered with a simple string, sent to a vulnerable server:


When the vulnerable application logs the string it triggers a lookup to an attacker-controlled remote LDAP server (example.com in our scenario). The response from the malicious server contains a path to a remote Java class file that’s injected into the server process.

Having tricked the vulnerable application into loading their Java class, attackers can use it to execute commands with the same level of privilege as the application that uses the logging library.

Used in the wild

After the 0-day was posted on Twitter, along with a proof-of-concept that was published on GitHub, the exploit has already been spotted being used in the wild by CERT New Zealand, CERT Austria, and CERT Germany. Along with many others, they are seeing automated systems trying to exploit the vulnerability.

Given how common this library is and how serious the consequences of a relatively easy-to-exploit vulnerability can be, this is a recipe for disaster. Many organizations will not even realize they are vulnerable.

According to researcher Marcus Hutchins, in the case of Minecraft, attackers were able to get remote code execution on Minecraft servers by simply pasting the malicious string into the chat box. Similar examples exist for a number of other popular services.

Preventing Log4j exploits

Mitigations are available for versions of Log4j 2.10.0 and up. Version 2.15.0 is not vulnerable by default. Note that there may be other dependencies, such as your Java version, that need to be updated before you can upgrade. Fixing the vulnerability may not be straightforward, but it is urgent.

The Apache log4j project advises that if you are unable to upgrade, for whatever reason, you can use the following mitigations:

  • In version 2.10.0 or higher by switching the log4j2.formatMsgNoLookups system property, or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. This can be done by adding ‐Dlog4j2.formatMsgNoLookups=True to the JVM command for starting the application.
  • For 2.7 up to and including 2.14.1, all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m.
  • For r2.0-beta9 up to and including 2.10.0, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

Sadly, there is little, if anything, that users of affected systems can do to make themselves less vulnerable to the consequences. No doubt many systems will be affected and system administrators will want to treat anomalies with extreme caution.

So, if you’re an administrator looking forward to a quiet weekend, you know what to do!

Update: Dec 13, 5:00 am, PT—Widespread scanning and exploitation

After close examination of this vulnerability, researchers found that it had been actively exploited prior to the public disclosure, going back as far as December 1. The mass exploitation however, started after the disclosure.

The majority of attacks so far seem to be coming from established botnets like Mirai and others, including some cryptomining botnets. But Microsoft warned that is has seen the some attacks that resulted in a drop of Cobalt Strike. Cobalt Strike is a collection of threat emulation tools provided by HelpSystems to work in conjunction with the Metasploit Framework. But cybercriminals are often using it as a backdoor that provides an ideal foothold to start lateral movement in a network.

Update: Dec 13, 7:00 am, PT—Fears of a Log4j worm

As the security community wrestles with the vast scale of the Log4j problem, fears are growing that it may be “wormable” and that an Internet worm could appear in the next few days. (A worm is a piece of malware that infects vulnerable systems and then uses them to find and infect other systems.)

Because their rate of replication is exponential, worms can spread extremely quickly. In 2003, the SQL Slammer worm spread around the world in about ten minutes, and in 2017 the WannaCry ransomware worm spread around the world in a matter of hours, before its kill switch was activated.

Stay safe, everyone!