Security Experts Sound Alarm on Zero-Day in Widely Used Log4j Tool

Security experts are sounding the equivalent of a five-alarm fire on a critical new zero-day vulnerability in Log4j, a logging framework that is ubiquitously present in Java software.

The flaw (CVE-2021-44228) could allow remote attackers to run arbitrary code on any application that uses Log4j and is already being actively exploited. Some vendors have observed mass scanning activity — presumably by threat actors — for vulnerable applications, and there are some reports of exploit activity against organizations. Attacks against the flaw take little skill to execute and are being fueled by proof-of-concept code in the wild.

“This is a worst-case scenario,” warns Casey Ellis, founder and CTO of crowdsourced vulnerability disclosure platform Bugcrowd. Making it so is the combination of Log4j’s ubiquitous use in software and platforms, the numerous paths available to exploit the vulnerability, the dependencies that will make it difficult to patch without breaking other things, and the fact that the exploit itself fits into a tweet, he says. 

“It’s going to be a long weekend for a lot of people,” Ellis says.

The flaw affects all versions of Log4j, from 2.0-beta9 to 2.14.1. The Apache Foundation has assigned it a maximum severity rating of 10 and has released an updated version
of the software (Log4j 2.15.0), which addresses the issue. The foundation has also published a mitigation measure for versions of Log4j versions 2.10 and later, which organizations can implement to protect against remote code execution via the vulnerability.

In a blog published Friday, Sonatype
described the new Log4j flaw as even worse than the infamous 2017 remote code execution vulnerability in Apache Struts (CVE-2017-5638) that was the root cause of the massive breach at Equifax. With that flaw, it took attackers less than two days to start exploiting organizations around the world. 

The newly disclosed vulnerability is potentially more far-reaching than the Struts vulnerability because Log4j is far more widely used, Sonatype said. 

“The impact is comparable to previous Struts vulnerabilities, like the one that impacted Equifax, because the attacks can be done remotely, anonymously without login credentials, and leads to a remote exploit,” said Sonatype CTO Brian Fox in an emailed statement. “The combination of scope and potential impact here is unlike any previous component vulnerability I can readily recall.”

Even the NSA’s GHIDRA reverse-engineering tool is not immune from the threat. In a tweet shared Friday, NSA’s director of the Cybersecurity Directorate said the Log4j vulnerability posed a significant threat for exploitation because of its widespread inclusion in software frameworks, including GHIDRA. 

“This is a case study in why the software bill of material (SBOM) concepts are so important to understand exposure,” wrote the NSA’s director of cybersecurity, Rob Joyce.

The Apache Foundation says the vulnerability is tied to a failure by certain features in the Java Naming and Directory Interface (JNDI) — which is used in configuration, log messages, and parameters — to protect against attacker controller LDAP servers and other endpoints. As a result, an attacker who can control log messages or log message parameters can execute malicious code loaded from LDAP servers when a certain message lookup behavior is enabled. The updated version of Log4j has disabled this behavior by default.

Chris Morgan, threat intelligence analyst at Digital Shadows, says the vulnerability looks extremely high risk. 

“At a high level, this bug allows an attacker to deliver a malicious payload [and] use the payload to trigger the vulnerability, which then injects a secondary stage of the attack to execute arbitrary code,” he says.

Given the scale of affected devices and exploitability of the bug, it is highly likely to attract considerable attention from both cybercriminals and nation-state-associated actors. 

“Organizations are advised to update to version 2.15.0 and place additional vigilance on logs associated with susceptible applications,” Morgan says.

Arshan Dabirsiaghi, co-founder and chief scientist at Contrast Security, says the newly disclosed issue in Log4j is the largest Java vulnerability in years. Organizations must evaluate the flaw’s potential impact in their environments and consider how to mitigate the threat. He assesses the vulnerability as easy to exploit, especially because videos and proof-of-concept code are already publicly available. 

For organizations, the vulnerability is easy enough to mitigate one app at a time, but it’s considerably harder to do so at scale.

“Companies need a live view of their dependencies actually in use by their application portfolio,” says Dabirsiaghi. “This allows them to do two things: alert the particular developers using the problematic library and measure their progress against removing it from their organization.”

Read More HERE