Cybercrime

Problematic Log4j Functionality Disabled as More Security Issues Come to Light

Developers of the widely used Apache Log4j Java-based logging tool have disabled problematic functionality as more security issues have come to light.

<p><strong><span><span>Developers of the widely used Apache Log4j Java-based logging tool have disabled problematic functionality as more security issues have come to light.</span></span></strong></p>

Developers of the widely used Apache Log4j Java-based logging tool have disabled problematic functionality as more security issues have come to light.

It was discovered recently that Log4j version 2.x is affected by a critical remote code execution vulnerability that can be easily exploited to take complete control of a system. The flaw is tracked as CVE-2021-44228, Log4Shell and LogJam, and it has been exploited in attacks since December 1, days before an official patch was released.

Log4Shell attacks have been launched by profit-driven cybercriminals to deliver DDoS malware, cryptocurrency miners, ransomware, and other malicious programs, as well as by Chinese and Iranian state actors.

Exploitation of the vulnerability involves sending a specially crafted request to the targeted system. The request generates a log using Log4j, which leverages the Java Naming and Directory Interface (JNDI) lookup feature to perform a request to an attacker-controlled server, from which a malicious payload is fetched and executed.

CVE-2021-44228 was patched on December 6 with the release of Log4j 2.15.0. However, it was soon discovered that the fix was incomplete in certain non-default configurations, and exploitation could still lead to denial-of-service (DoS) attacks “or worse.”

A new CVE identifier, CVE-2021-45046, was assigned to this issue, and another round of updates was released. The latest versions of Log4j — versions 2.12.2 and 2.16.0 — not only patch this vulnerability, but also completely remove the message lookups feature and disable access to JNDI by default.

“JNDI lookups will now return a constant value. Also, Log4j now limits the protocols by default to only java,” Log4j developers said.

It has also come to light that while the risk of attacks against Log4j version 1.x is lower, systems running this version are still vulnerable to attacks if JNDI is used in their configuration. CVE-2021-4104 has been assigned to this issue and while patches will not be released because version 1.x is no longer supported, mitigations are available.

Risk Based Security has analyzed the three CVEs and noted that CVE-2021-4104 is an “entirely different attack vector.”

Advertisement. Scroll to continue reading.

The security firm pointed out that assigning a separate CVE to the incomplete fix for CVE-2021-44228 may be helpful to some organizations, but it can also cause confusion.

As companies scramble to assess impact, threat actors are increasingly exploiting the Log4Shell vulnerability in their attacks, and many organizations appear to be exposed.

“Wiz research shows that more than 89% of all environments have vulnerable Log4j libraries,” Ami Luttwak, co-founder and CTO of cloud security company Wiz, told SecurityWeek. “And in many of them, the dev teams are sure they have zero exposure — and are surprised to find out that some third-party component is actually built using Java.”

Check Point reported seeing more than one million attack attempts, nearly half of which have been linked to known malicious groups. The company said it had seen exploitation attempts against 44% of corporate networks around the world.

SecurityWeek has compiled a list of tools and other resources that can be useful for defenders concerned about the impact of the Log4Shell vulnerability on their organization.

Related: Industrial Organizations Targeted in Log4Shell Attacks

Related Content

Copyright © 2024 SecurityWeek ®, a Wired Business Media Publication. All Rights Reserved.

Exit mobile version