vulnerability in apache

Log4j Vulnerability with a New Local Attack Vector.

An Expanded Attack Surface for Log4j Vulnerability with a New Local Attack Vector.

Researchers have discovered an entirely new means of exploiting the Log4Shell vulnerability locally by using a JavaScript WebSocket connection.

Matthew Warner, CTO of Blumira, described the newly-discovered attack vector as meaning that anyone with a vulnerable Log4j version on their machine or local private network can browse a website and trigger the vulnerability. As of now, there is no proof of active exploitation. This vector expands the attack surface significantly and can affect services that are running locally and do not have any network exposure.”

With WebSockets, web browsers (or other client applications) can communicate two-way with a server, as opposed to HTTP, which is unidirectional, i.e. the client sends the request and the server responds.

The issue can be resolved by updating all local development and internet-facing environments to Log4j 2.16.0, however, Apache on Friday released version 2.17.0, which resolves a denial-of-service vulnerability tracked as CVE-2021-45105 (CVSS score: 7.5), making this the third Log4j2 flaw to come to light after CVE-2021-45046 and CVE-2021-44228.

Following the original disclosure of the remote code execution bug, the following flaws have been discovered in the logging framework:

  • CVSS score: 10.0) – A remote code execution vulnerability affecting Log4j versions 2.0-beta9 to 2.14.1 (Fixed in version 2.15.0)
  • The vulnerability (CVE-2021-45046) affects Log4j versions from 2.0-beta9 through 2.15.0 (Fixed in version 2.16.0) – An information leak and remote code execution vulnerability.
  • XSS vulnerability in Log4j versions 2.0-beta9 to 2.16.0 (Fixed in version 2.17.0) CVE-2021-45105 (CVSS score: 7.5) – A denial-of-service vulnerability.
  • An untrusted deserialization flaw in Log4j version 1.2 (No patch available; upgrade to version 2.17.0) (CVSS score: 8.1)

  Several threat actors have exploited the Log4j flaws to mount a variety of attacks, including ransomware infections involving the Russia-based Conti group and a new strain of ransomware named Khonsari. Moreover, researchers from Sangfor and Curated Intel have found that the Log4j remote code execution flaw has also exposed a third ransomware strain called TellYouThePass, which is being used in attacks against Windows and Linux devices.

Over 35,000 Java packages are affected by the Log4j flaw according to Google.

According to an analysis by Google’s Open Source Insights Team, over 8% of the Maven Central repository uses vulnerable versions of the Apache Log4j library. Only 7,000 packages directly depend on Log4j out of the impacted artifacts. James Wetter and Nicky Ringland from Google said: “Users’ lack of visibility and transitive dependencies make it difficult to apply patches; this also makes it difficult to determine the full operational radius of this vulnerability.” But on the bright side, 2,620 affected packages were fixed within a week of being revealed.

“It’s probably going to be a while before we fully understand the full meaning of the log j vulnerability, but only because it’s built into so much software,” Williams said. “It has nothing to do with malware from malicious actors. It involves the difficulty of finding the multitude of places where the library is embedded. The vulnerability itself would provide initial access to threat actors, who would later perform privilege escalation and side migrations – that’s where the real risk is. “