Log4j: Security pros call for urgent patch implementation as in-the-wild exploitation continues

Initial, ‘incomplete’ patch created path to denial-of-service attacks

Users of popular Java logging library Apache Log4j have been urged to apply a second patch related to the critical ‘Log4Shell’ vulnerability after the initial fix was bypassed.

The CVSS 10-rated vulnerability continues to dominate the infosec headlines amid evidence of active, hostile exploitation.

Maintainers and vendors of countless downstream applications have been rushing to update their own software in the wake of the bombshell bug, which enables attackers to achieve remote code execution (RCE) on target systems.

CATCH UP ‘Log4Shell’ flaw poses critical threat to applications using ‘ubiquitous’ Java logging package Log4j

DoS threat

The Apache Logging Services project released Apache Log4j 2.16.0 on Monday (December 13) after the first update, version 2.15.0, was found to be “incomplete in some non-default configurations and could allow an attacker to execute a denial-of-service (DoS) attack”, according to an Apache Software Foundation (ASF) blog post published yesterday (December 14).

Users still on Java 7 should upgrade to the Log4j 2.12.2 release, said the ASF.

The first flaw (CVE-2021-44228), which affects Log4j2 versions up to and including 2.14.1, allows 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 project maintainers rushed out the first fix, which restricted JNDI LDAP lookups to localhost by default, after the proof of concept (PoC) surfacing on Twitter and GitHub.

However, this patch then spawned a fresh flaw (CVE-2021-45046) that, if abused in certain contexts, could enable attackers to mount a DoS attack by crafting malicious input data using a JNDI Lookup pattern.

Previous configuration-related mitigations do not mitigate the latest vulnerability, the ASF has emphasized.

Apache also recommend that, while the Log4j 1.x series is not known to be affected by either CVE, users running versions from the first release line should still update to the latest release line, since the first has reached end of life and no longer receives security patches.

In-the-wild exploitation

In a detailed technical write-up, cybersecurity firm Trend Micro said it has “observed threat actors dropping Mirai variants and Kinsing coinminers onto vulnerable servers”.

“While some of the network traffic is simple, other threat actors are using obfuscation in the expression to hide their traffic,” it added.

Trend Micro also noted that “ransomware operators were also reportedly exploiting Log4Shell, particularly those behind the Khonsari ransomware family”, and that “Mirai might use the affected systems as part of its botnet for activities such as distributed denial of service (DDoS) or spamming”.

It added: “Though the attacks in the wild are predominantly delivered over HTTP, the vulnerability could be exploited over any protocol wherein user input data is logged using Log4j.”

Downstream scramble

Log4j has been widely distributed via a mirror system, and more recently via a Content Delivery Network (CDN), while many organizations have shipped the library as part of their projects, products or services.

Trend Micro has catalogued potentially vulnerable products, applications, and plugins and the actions taken or pending from vendors to address and/or mitigate the vulnerability. These include packages or applications from RedHat, VMware, and Atlassian.

The Apache Security Team has compiled a list indicating whether various Apache projects are known to be affected or not with links to updates if available.

No other Apache Logging Services sub-projects, such as Log4net or Log4cxx, are impacted.

Risk factor

“Unless you have been hiding under a rock with your eyes closed and your fingers in your ears, you have heard of a zero-day exploit in the Java logging library known as Apache Log4j,” said Dustin Childs, communications manager for Trend Micro’s Zero Day Initiative (ZDI).

“If you run a server built on open source software, there’s a good chance you are impacted by this vulnerability,” he added. “Check with all the vendors in your enterprise to see if they are impacted and what patches are available.”

Brian Fox, CTO of DevSecOps specialist Sonatype, has compared the flaw to the notorious Struts vulnerability that compromised Equifax to devastating effect in 2017.

“The combination of scope and potential impact here is unlike any previous component vulnerability I can readily recall,” he told The Daily Swig last week.

Numerous tools have already been developed for enterprise users to scan for affected systems.