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.
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
There are some cases where the current exploits might not work even though Log4j is vulnerable, for example if the host system uses a Java version that’s higher than 6u212, 7u202, 8u192 or 11.0.2. That’s because these versions added improved protection for JNDI (Java Naming and Directory Interface) remote class loading, which is needed for the exploit to work.
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.
