Second Log4j vulnerability carries denial-of-service threat, new patch available

A second vulnerability impacting Apache Log4j has been discovered as the security industry has scrambled to mitigate and fix a severe zero-day Java library logging flaw (CVE-2021-44228) dubbed Log4Shell. The new vulnerability, CVE 2021-45046, could allow attackers to craft malicious input data using a JNDI lookup pattern resulting in a denial-of-service (DoS) attack, according to the CVE description.

A patch for the new exploit, which removes support for message lookup patterns and disables JNDI functionality by default, has already been released, with the Log4j 2.15.0 fix for the original flaw “incomplete in certain non-default configurations.”

Log4j vulnerability continues to threaten organizations

The discovery of this second vulnerability is indicative of the ongoing security risks posed by the Log4j issue, which is rated 10 out of 10 on the CVSS vulnerability rating scale. Data from across the sector has revealed vast numbers of threat actors exploiting Log4Shell to target businesses, with warnings of the imminent arrival of a self-propagating worm also causing public concern.

“The first vulnerability created a risk of remote code execution, and because Log4J is so widely used, this impacted many different types of software,” Matthew Gracey McMinn, head of threat research at Netacea, tells CSO. “As such, fixing this was a priority. However, it seems that the first patch, while preventing the remote code execution, may not be 100% successful if you have a very custom set up.” The danger of this new, second vulnerability is the threat of DoS attacks, he adds.

Cybercriminals can exploit this vulnerability very easily and bring down servers and applications that they can run the exploit against. “A specially crafted message sent to a vulnerable server is all it takes to compromise it and exploit this vulnerability,” Gracey McMinn says.

Prioritize patching and defense-in-depth to mitigate risk

Gracey McMinn urges organizations to install the new patch as soon as they can, without disabling business critical services. “More generally, businesses need to consider the need for things like JNDI to be enabled for specific servers. Log4j is necessary for many applications, but JNDI is not a necessary feature for many businesses,” he says.

Where updating or disabling is not possible, a defense-in-depth model can come into its own, Gracey McMinn continues. “No single piece of code should be a critical failure for a business, and an attacker who successfully exploits Log4j should not then have unfettered access to and control of an entire network. Subsequent layers of defense should be in place to prevent the attack at later stages. In that way, the impact of any attack can be minimized.”