Attackers are actively exploiting a critical vulnerability in Apache Log4j, a logging library that’s used in potentially millions of Java-based applications, including web-based ones. Organizations should immediately review if their apps, especially the publicly accessible ones, use the library and should implement mitigations as soon as possible.
A proof-of-concept exploit for the vulnerability, now tracked as CVE-2021-44228, was published on December 9 while the Apache Log4j developers were still working on releasing a patched version. Attacks started soon after, making the flaw a zero-day (unpatched) issue at the moment of exploitation. Apache has since released Log4j 2.15.0 which includes a fix.
The Log4Shell exploit
The vulnerability can lead to remote code execution on the underlying servers that run vulnerable applications and exploiting the issue requires no authentication. The flaw is rated with the maximum severity of 10 on the CVSS scale.
“An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled,” the developers said in their advisory. “From log4j 2.15.0, this behavior has been disabled by default.”
This generally means that if a user can generate a request that includes specifically crafted input, and that request gets logged through Log4j, the vulnerability could be exploited. Since most applications are designed to accept user input in a variety of ways, exploitation is trivial.
The developers credit Chen Zhaojun of Alibaba’s Cloud Security Team with originally reporting the issue in November. Based on developer comments in the bug tracker, the release of a patched version might have been delayed because researchers found a way to bypass the initially proposed fix, so it required additional work and review.
Long-lasting impact
The vulnerability doesn’t affect only Java-based applications and services that use the library directly, but also many other popular Java components and development frameworks that rely on it including reportedly Apache Struts2, Apache Solr, Apache Druid, Apache Flink, ElasticSearch, Apache Kafka and many others.
The community is still working to assess the attack surface, but it’s likely to be huge due to the complex ecosystem of dependencies. Some of the impacted components are extremely popular and are used by millions of enterprise applications and services.
Services run by Apple, Amazon, Twitter, Cloudflare, Steam, Tencent, Baidu and others were reported to be vulnerable. Cloudflare created detection rules in its web application firewall to block exploit attempts and released an advisory. Researcher Florian Roth also published YARA detection rules.
“I expect there’s gonna be a long tail here,” Chris Wysopal, CTO of application security firm Veracode, said in a webinar about the flaw. “There might be applications that you have good visibility into and you find rather quickly, but it is challenging to find all your Java applications.”
“The other challenge is, of course, vendor applications that are written in Java. You know, we saw this with Heartbleed many years ago—which kind of kicked off the whole third-party risk—that a lot of vendor applications were written with the open SSL library and you had to wait for your vendor to patch that. And the same thing could happen here. A lot of appliances, a lot of packaged software use Java, so I would expect that people are going to be asking their vendors when they’re going to be patched.”
It’s likely that enterprises will be busy for months to come chasing down and patching applications vulnerable to this issue, highlighting the importance of vendors implementing software bills of materials. Unfortunately, failing to patch actively exploited flaws in a timely manner can lead to major breaches. The major 2017 Equifax breach was the result of failure to patch an actively exploited Struts2 vulnerability for 2 months in a publicly facing application.
[Update December 13] Log4j has been downloaded 84 million times from the Central Repository of Java components during the last four months, making it one of the most popular components in the Java ecosystem.
“This is akin to someone figuring out mailing a letter into your post box with a specific address written on it allows them to open all your doors in your house,” Brian Fox, the CTO of software supply chain management company Sonatype, tells CSO via email. “Companies need to be aware of Log4j not only in the software they produce, but also in the software they use. Any software written in Java is very likely to contain Log4j somewhere in its stack. This includes embedded devices.”
Attackers are already scanning the internet for applications and services that might be vulnerable to CVE-2021-44228 and traffic monitoring service GreyNoise is reporting that the number of exploitation attempts is ramping up.
Mitigations
[Editor’s note: This section has been updated on December 13 to reflect new information on exploit paths.]
The initial exploits don’t work on Java versions newer than 6u212, 7u202, 8u192 or 11.0.2, because the default configuration in these versions prevent class loading via JNDI (Java Naming and Directory Interface) from remote servers. The exploits leverage JNDI remote class logging to execute malicious payloads from attacker-controlled LDAP servers.
However, security rsearchers have since shown that this JVM (Java Virtual Machine) limitation does not prevent all exploit paths because attackers can build payloads that take advantage of classes in the application’s own classpath instead of remote ones.
“We believe it’s likely only a matter of time before all Java versions, even current Java 11 versions, are impacted when running a vulnerable version of log4j,” researchers from LunaSec said in a mitigation guide. “Just upgrading your Java version is insufficient, and you should not rely on this as a long-term defense against exploitation.”
In addition, in log4j versions higher than 2.10, the issue can be mitigated by setting the system property formatMsgNoLookups to true, setting the JVM parameter -Dlog4j2.formatMsgNoLookups=true or by removing the JndiLookup class from the classpath.
However, the best fix is to update to log4j 2.15.0 because someone could find an alternative path to reach the vulnerable code that doesn’t rely on JNDI. If that happens, the proposed mitigations that rely on limiting JNDI would become ineffective.
Copyright © 2021 IDG Communications, Inc.
