New Local Attack Vector Expands the Attack Surface of Log4j Vulnerability

Cybersecurity researchers have discovered an entirely new attack
vector that enables adversaries to exploit the Log4Shell
vulnerability on servers locally by using a JavaScript WebSocket
connection.

“This newly-discovered attack vector means that anyone with a
vulnerable Log4j version on their machine or local private network
can browse a website and potentially trigger the vulnerability,”
Matthew Warner, CTO of Blumira, said^[1]. “At this point, there
is no proof of active exploitation. This vector significantly
expands the attack surface and can impact services even running as
localhost which were not exposed to any network.”

WebSockets^[2]
allow for two-way communications between a web browser (or other
client application) and a server, unlike HTTP, which is
unidirectional where the client sends the request and the server
sends the response.

While the issue can be resolved by updating all local
development and internet-facing environments to Log4j 2.16.0,
Apache on Friday rolled out version 2.17.0^[3], which remediates a
denial-of-service (DoS) vulnerability tracked as CVE-2021-45105
(CVSS score: 7.5), making it the third Log 4j2 flaw to come to
light after CVE-2021-45046^[4]
and CVE-2021-44228^[5].

The complete list of flaws discovered to date in the logging
framework after the original remote code execution bug was
disclosed is as follows —

• CVE-2021-44228^[6] (CVSS score: 10.0) – A
  remote code execution vulnerability affecting Log4j versions from
  2.0-beta9 to 2.14.1 (Fixed in version 2.15.0)
• CVE-2021-45046^[7] (CVSS score: 9.0) – An
  information leak and remote code execution vulnerability affecting
  Log4j versions from 2.0-beta9 to 2.15.0, excluding 2.12.2 (Fixed in
  version 2.16.0)
• CVE-2021-45105^[8] (CVSS score: 7.5) – A
  denial-of-service vulnerability affecting Log4j versions from
  2.0-beta9 to 2.16.0 (Fixed in version 2.17.0)
• CVE-2021-4104^[9] (CVSS score: 8.1) – An
  untrusted deserialization flaw affecting Log4j version 1.2 (No fix
  available; Upgrade to version 2.17.0)

“We shouldn’t be surprised that additional vulnerabilities were
discovered in Log4j given the additional specific focus on the
library,” Jake Williams, CTO and co-founder of incident response
firm BreachQuest, said. “Similar to Log4j, this summer the original
PrintNightmare^[10] vulnerability
disclosure led to the discovery of multiple additional distinct
vulnerabilities. The discovery of additional vulnerabilities in
Log4j shouldn’t cause concern about the security of log4j itself.
If anything, Log4j is more secure because of the additional
attention paid by researchers.”

The latest development comes as a number of threat actors have
piled on the Log4j flaws to mount a variety of attacks, including
ransomware infections involving the Russia-based Conti group and a
new ransomware strain named Khonsari. What’s more, the Log4j remote
code execution flaw has also opened the door to a third ransomware
strain known as TellYouThePass that’s being used in attacks against
Windows and Linux devices, according to researchers from Sangfor^[11] and Curated Intel^[12].

Bitdefender Honeypots Signal Active Log4Shell 0-Day Attacks
Underway

The easily exploited, ubiquitous vulnerability, aside from
spawning as many as 60 variations, has presented a perfect window
of opportunity for adversaries, with Romanian cybersecurity firm
Bitdefender noting that more than 50% of the attacks are leveraging
the Tor anonymity service to mask their true origins.

“In other words, threat actors exploiting Log4j are routing
their attacks through machines that are closer to their intended
targets and just because we don’t see countries commonly associated
with cybersecurity threats at the top of the list does not mean
that attacks did not originate there,” Martin Zugec, technical
solutions director at Bitdefender, said^[13].

According to telemetry data collected between December 11 and
December 15, Germany and the U.S. alone accounted for 60% of all
the exploitation attempts. The most common attack targets during
the observation period were the U.S., Canada, the U.K., Romania,
Germany, Australia, France, the Netherlands, Brazil, and Italy.

Google: Over 35,000 Java Packages Affected by the Log4j
Flaw

The development also coincides with analysis from Google’s Open
Source Insights Team, which found that roughly 35,863 Java packages
— accounting for over 8% of the Maven Central repository — use
vulnerable versions of the Apache Log4j library. Of the affected
artifacts, only around 7,000 packages have a direct dependency on
Log4j.

“User’s lack of visibility into their dependencies and
transitive dependencies has made patching difficult; it has also
made it difficult to determine the full blast radius of this
vulnerability,” Google’s James Wetter and Nicky Ringland said^[14]. But on the positive
side of things, 2,620 of the impacted packages have already been
fixed less than a week after disclosure.

“There will likely be some time before we understand the full
fallout of the log4j vulnerability, but only because it’s embedded
in so much software,” Williams said. “This has nothing to do with
threat actor malware. It has to do with the difficulty in finding
the myriad places the library is embedded. The vulnerability itself
will provide initial access for threat actors who will later
perform privilege escalation and lateral movement – that’s where
the real risk is.”