Apache Log4j Threatens, Well, Everything
It doesn’t get much worse than this, at least according to cybersecurity experts. The RCE bug currently being actively exploited in the widely used Apache Log4j promises to leave a trail of damage and destruction in its wake, even for those who quickly take action against it.
“This is a worst-case scenario. The combination of Log4j’s ubiquitous use in software and platforms; the many, many paths available to exploit the vulnerability; the dependencies that will make patching this vulnerability without breaking other things difficult and the fact that the exploit itself fits into a tweet,” said Casey Ellis, founder and CTO at Bugcrowd. “It’s going to be a long weekend for a lot of people.”
Even though it’s still early on, Dor Dali, director of information security at Vulcan Cyber, classified the Log4j vulnerability “as very critical. I would classify it in the top three worst vulnerabilities of 2021.”
Ellis stressed the need to mitigate this vulnerability immediately. “The immediate action is to stop what you’re doing as a software shop and enumerate where Log4j exists and might exist in your environment and products,” Ellis said. “It’s the kind of software that can quite easily be there without making its presence obvious, so we expect the tail of exploitability on this vulnerability to be quite long.”
The Log4j2 Java logging library, home to the newly discovered zero-day exploit, is ubiquitous and the vulnerability, CVE-2021-44228, also known as Log4Shell, is easy to exploit, promising an impact that “is quite severe,” Free Wortley, CEO at LunaSec and Chris Thompson, a developer at Lunasec, wrote in a blog post.
“It wouldn’t be a stretch to say that every enterprise organization uses Java, and Log4j is one of the most popular logging frameworks for Java,” noted Dali. “Connecting the dots: The impact of this vulnerability has the reach and potential to be substantial if mitigation efforts aren’t taken right away.”
The exploit, for which a proof-of-concept (POC) was posted on GitHub, could hand attackers full server control simply through logging a certain string.
“At a high level, this bug allows an attacker to deliver a malicious payload and use the payload to trigger the Log4Shell vulnerability, which then injects a secondary stage of the attack to execute arbitrary code,” Chris Morgan, senior cyber threat intelligence analyst at Digital Shadows, said of the flaw he called extremely high risk.
In Apache Log4j2 version 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,” according to a MITRE alert. “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.”
That behavior has been disabled by default, starting with Log4j version 2.15.0. For the earlier versions, it can be mitigated “by setting system property log4j2.formatMsgNoLookups to “true” or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class),” the notice said. “Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against remote code execution by defaulting ‘com.sun.jndi.rmi.object.trustURLCodebase’ and ‘com.sun.jndi.cosnaming.object.trustURLCodebase’ to ‘false,’” according to the notice.
Those users who “change the setting back to ‘false’ remain vulnerable to attack and, as a result, it is highly recommended that this is not returned to its previous setting,” said Morgan, who noted the easily exploited vulnerability is likely to attract nation-state actors. “Organizations are advised to update to version 2.15.0 and maintain additional vigilance on logs associated with susceptible applications.”
Already “attackers have reportedly attempted to scan for servers susceptible to this bug, with proof-of-concepts related to Log4j also demonstrating that the scale of susceptible applications is also likely to be high; the bug reportedly affects several popular third-party applications and software used by enterprise organizations, including a host of popular frameworks like Apache Struts,” Morgan said.
Although “the specifics of how attacking this vulnerability may play out are still a bit open-ended, given the widespread use and position of the underlying software, it absolutely looks like a good candidate for malicious network ingress which means network defenders should be on guard for suspicious outbound traffic that may indicate command-and-control,” said Tim Wade, technical director, CTO team at Vectra. “This is an example of how critical effective detection and response capabilities are, and really exposes how risky the ‘prevent, patch and pray’ strategy that’s so widely adopted in legacy security programs really is.”
Since “webapps running this kind of setup typically would process sensitive information, the mitigations in question should be applied immediately, which includes updating Java,” said John Bambenek, principal threat hunter at Netenrich. “Web application firewalls (WAFs) should also be updated with an appropriate rule to block such attacks.”
