“This newly discovered attack vector means that anyone with a vulnerable version of Log4j on their machine or local private network can browse a website and potentially trigger the vulnerability,” said Matthew Warner, CTO of Blumira. “At this point, there is no evidence of active exploitation. This vector greatly expands the attack surface and can impact even services running as a local host that have not been exposed to any network.”
WebSockets allow two-way communications between a web browser (or other client application) and a server, unlike HTTP, which is one-way where the client sends the request and the server sends the response.
While the issue can be resolved by updating all local and internet development environments to Log4j 2.16.0, Apache deployed version 2.17.0 on Friday, which fixes a denial of service (DoS) vulnerability identified as CVE- 2021-45105 (CVSS score: 7.5), making it the third Log 4j2 flaw to be discovered after CVE-2021-45046 and CVE-2021-44228.
The complete list of vulnerabilities discovered to date in post-release journaling of the original remote code execution bug is as follows:
- CVE-2021-44228 (CVSS Score: 10.0) – A remote code execution vulnerability affecting Log4j versions 2.0-beta9 through 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 2.0-beta9 through 2.15.0, except 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 unreliable deserialization flaw affecting Log4j version 1.2 (No patch available; Upgrade to version 2.17.0)
“We shouldn’t be surprised that additional vulnerabilities have been discovered in Log4j given the additional specific focus on the library,” said Jake Williams, CTO and co-founder of incident response company BreachQuest. Similar to Log4j, this summer the original disclosure of the PrintNightmare vulnerability led to the discovery of several additional distinct vulnerabilities. The discovery of additional vulnerabilities in Log4j should not be of concern to the security of log4j itself. On the contrary, Log4j is more secure because of the extra attention paid by researchers.
The latest development comes as a number of threat actors have piled on the loopholes in Log4j to launch a variety of attacks, including ransomware infections involving the Russia-based Conti group and a new strain of ransomware named Khonsari. Additionally, the Log4j remote code execution flaw has also opened the door for a third ransomware strain known as TellYouThePass which is being used in attacks against Windows and Linux devices, according to researchers at Sangfor and Curated. Intel.
Bitdefender Honeypots Reports Active Log4Shell 0-Day Attacks In Progress
The pervasive and easily exploitable vulnerability, in addition to spawning up to 60 variants, presented a perfect window of opportunity for adversaries, with Romanian cybersecurity firm Bitdefender noting that more than 50% of attacks use the anonymity service. Tor to hide their true origins.
“In other words, threat actors operating Log4j route their attacks through machines closer to their intended targets and it’s not because we don’t see countries commonly associated with cybersecurity threats at the top of the line. list that the attacks are not originating. over there, ”said Martin Zugec, director of technical solutions at Bitdefender.
According to telemetry data collected between December 11 and 15, Germany and the United States alone accounted for 60% of all attempted exploitation. The most common attack targets during the observation period were the United States, Canada, United Kingdom, Romania, Germany, Australia, France, Netherlands, Brazil and Italy.
Google: more than 35,000 Java packages affected by the Log4j flaw
The development also coincides with analysis by Google’s Open Source Insights team, which found that approximately 35,863 Java packages – representing over 8% of the Maven Central repository – use vulnerable versions of the Apache Log4j library. Of the affected artifacts, only about 7,000 packages have a direct dependency on Log4j.
“The lack of user visibility into their dependencies and transitive dependencies made it difficult to apply patches; it also made it difficult to determine the full radius of action of this vulnerability,” said James Wetter and Nicky Ringland from Google. But on the bright side, 2,620 of the impacted packages have already been fixed within a week of disclosure.
“It will probably be some time before we understand the full implications of the log4j vulnerability, but only because it is built into so much software,” said Williams. “It has nothing to do with malware from malicious actors. It has to do with the difficulty in finding the myriad of places where the library is embedded. The vulnerability itself will provide initial access to malicious actors who will later perform privilege escalation and lateral movement – that’s where the real risk is. “