New Log4j Attack Vector Discovered

Organizations working to reduce exposure to attacks targeting the Log4j remote code execution (RCE) vulnerability disclosed Dec. 9 have a couple of new considerations to keep in mind.

Security researchers at Blumira have discovered that threat actors can potentially trigger the RCE flaw on internal and locally exposed Log4j applications via a JavaScript WebSocket connection — suggesting the attack surface may be much larger than first thought. Meanwhile, the Apache Foundation over the weekend released yet another update to fix a third vulnerability in the logging framework in recent days, meaning that organizations will once again need to patch their software to remain fully protected against the threat.

According to Blumira, attackers can exploit the Log4j RCE flaw by luring users to any server that runs JavaScript to initiate a WebSocket connection. WebSocket is a communication protocol that many modern browsers use for bidirectional communication between the server and client. The site would make calls to the user's system or local network using WebSocket. If the victim's host is vulnerable, it is then forced to call out to another attacker-controlled website over LDAP, RMI, DNS, HTTP or other protocol and download malicious JavaScript for exploiting the Log4j RCE, says Matthew Warner, CTO and co-founder of Blumira.

"If the victim had a vulnerable version of Log4j and it was logging out requests to paths being requested and/or the origin of those requests, it would trigger the Log4j JNDI lookup to the malicious host," Warner says. "No additional effort would be required."

Warner says Blumira's research shows the impact of Log4j isn't limited to vulnerable servers.

"Anyone with a service that utilizes a vulnerable Log4j version on their machine or local private network can browse a website and potentially trigger the vulnerability," Warner says. It significantly expands the attack surface and is another weapon that operators of phishing and malicious advertising scams are likely to exploit, he says. 

The new attack vector should not complicate matters for organizations that already are following the recommended remediation steps for Log4j. "However, it does highlight the importance of patching all local development and internal servers," Warner says.

Three Vulnerabilities — So Far
Log4j is a near-ubiquitous logging tool in Java environments. Since Dec. 9, three unique vulnerabilities have been disclosed in the logging framework, each of varying severity. The most serious one is the critical RCE vulnerability (CVE-2021-44228) that the Apache Foundation disclosed Dec. 9.^. The flaw exists in a Java Naming and Directory Interface (JNDI) lookups feature that is enabled by default in versions Log4j 2.0-beta9 to Log4j 2.14.1. 

Attackers can exploit the feature to take complete remote control of vulnerable systems, which can include Internet-facing systems, internal systems, network components, virtual machines, industrial control and SCADA systems, and cloud-hosted assets.

The Apache Foundation released an updated version of the logging framework (Log4j 2.15.0) for Java 8 users on Dec. 10 to address the vulnerability amid reports of attackers actively seeking to exploit the flaw.

It then followed up with a second update on Dec. 13 (Log4j 2.16.0 for Java 8 and Log4j 2.12.2 for Java 7) because the original fix basically ended up opening systems to denial-of-service (DoS) attacks (CVE 2021-45046) under certain conditions.

On Dec. 18, the Apache Foundation issued another update (Log4j 2.17.0 for Java 8) to address a third, infinite recursive vulnerability in Log4j (CVE-2021-45105) that it described as allowing for DoS attacks. 

"Infinite recursion is code calling itself again and again and again," says Saryu Nayyar, CEO of Gurucul. "Eventually, it will overflow the memory allocated to it, and provide the ability to inject malicious code outside of the defined memory space."

Both CVE 2021-45046 and CVE-2021-45105 can only be exploited under specific nondefault conditions and are therefore considered less severe than CVE-2021-44228, the flaw that was disclosed on Dec. 9, which affects a very wide swath of organizations.

According to security researchers at Google, the bug affects more than 35,000 Java packages — or more than 8% — of all packages on Maven Central, one of the largest repositories of Java packages. The pervasiveness of the flaw and the relative ease with which it can be exploited has attracted widespread attention within the threat actor community.

Security vendors have reported seeing numerous financially motivated attackers as well as state-backed threat groups from countries such as Iran, China, and Turkey actively trying to exploit the flaw.

The activity prompted the US Cybersecurity & Infrastructure Security Agency (CISA) to issue an emergency directive Friday ordering all civilian federal agencies to take a series of measures to identify, patch, or mitigate vulnerable systems. Agencies have until Dec. 23 to comply with the requirements of the directive.

The latest developments come amid signs that organizations are making at least some progress in addressing the threat. An analysis that cloud security vendor Wiz conducted shows that 10 days after the flaw was disclosed, organizations on average have patched some 45% of their vulnerable cloud resources. However, the vendor found that 45% of vulnerable machines remain unprotected against the threat. Of these systems, 25% had administrative privileges and 7% were exposed to the Internet.

Meanwhile, a dashboard that Sonatype launched this week to track Log4j downloads showed that there were more than 4.6 million downloads of the logging tool since Dec. 10. Forty percent of what the company described as the "most recent downloads" were of vulnerable versions of Log4j.