“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. “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 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, 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 and CVE-2021-44228.
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 (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 (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 (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 (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 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 and Curated Intel.
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.
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. 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,” William 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.”