Network security researchers have discovered a new attack vector that can be used by attackers to locally exploit the Log4Shell vulnerability on the server through a JavaScript WebSocket connection.
“This newly discovered attack vector means that anyone with a vulnerable version of Log4j on their machine or local private network can browse the site and may trigger the vulnerability,” Blumira CTO Matthew Warner, Say“At this point, there is no evidence of active exploitation. This vector significantly expands the attack surface and can even affect services running as a local host that is not exposed to any network.”
Network socket Allows two-way communication between the Web browser (or other client applications) and the server, which is different from HTTP, which is one-way, the client sends a request and the server sends a response.
Although the problem can be solved by updating all local development and Internet-oriented environments to Log4j 2.16.0, Apache launched version 2.17.0 on Friday, which fixes the denial of service known as CVE-2021- (DoS) vulnerability. 45105 (CVSS score: 7.5), this is the third Log 4j2 vulnerability exposed after CVE-2021-45046 and CVE-2021-44228.
After the original remote code execution error was disclosed, the complete list of defects found in the log framework so far is as follows:
- CVE-2021-44228 (CVSS score: 10.0)-A remote code execution vulnerability that affects 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 disclosure and remote code execution vulnerability affecting the Log4j version, 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)-Untrusted deserialization defect affecting Log4j version 1.2 (no fix available; upgrade to version 2.17.0)
Jack Williams, chief technology officer and co-founder of incident response company BreachQuest, said: “Given the additional focus on libraries, we shouldn’t be surprised to find more vulnerabilities in Log4j.” “Similar to Log4j, the original one this summer The PrintNightmare vulnerability disclosure led to the discovery of multiple additional and different vulnerabilities. The discovery of additional vulnerabilities in Log4j should not cause concerns about the security of log4j itself. If anything, Log4j is more secure because of the extra attention given by researchers.”
The latest development is due to the use of Log4j vulnerabilities by many threat actors to launch various attacks, including ransomware infections involving the Conti group of Russia and a new ransomware strain called Khonsari. More importantly, the Log4j remote code execution flaw also opened the door to the third type of ransomware TellYouThePass, which, according to researchers, was used to attack Windows and Linux devices. Sanfo and Curated Intel.
Bitdefender honeypot sends out a signal that Log4Shell is conducting a 0-day attack
In addition to generating as many as 60 variants, this easy-to-exploit and ubiquitous vulnerability provides an excellent window of opportunity for attackers. Bitdefender, a Romanian cybersecurity company, pointed out that more than 50% of attacks use Tor anonymity. Cover up their true situation. origin.
“In other words, threat actors using Log4j route their attacks through machines that are closer to their intended target. Just because we don’t see countries usually associated with cybersecurity threats at the top of the list does not mean that the attack was not initiated. There,” Martin Zugec, Director of Technical Solutions, Bitdefender, Say.
According to telemetry data collected between December 11 and 15, Germany and the United States alone accounted for 60% of all development attempts. The most common targets during the observation period were the United States, Canada, the United Kingdom, Romania, Germany, Australia, France, the Netherlands, Brazil, and Italy.
Google: More than 35,000 Java packages are affected by Log4j flaws
This development also coincides with the analysis of the Google Open Source Insights team, which found that approximately 35,863 Java packages-accounting for more than 8% of the Maven central repository-use a vulnerable version of the Apache Log4j library. Of the artifacts affected, only about 7,000 packages directly depend on Log4j.
“Users’ lack of visibility into their dependencies and transitive dependencies makes patching difficult; it also makes it difficult to determine the full explosion radius of this vulnerability,” Google’s James Wetter and Nicky Ringland SayOn the positive side, 2,620 affected packages have been fixed in less than a week after the disclosure.
“It may take a while for us to understand the full consequences of the log4j vulnerability, but this is only because it is embedded in so much software,” Williams said. “This has nothing to do with threat actor malware. It has to do with the difficulty of finding the countless places where the library is embedded. The vulnerability itself will provide the threat actor with initial access, which will then perform privilege escalation and lateral movement-this is the real The risk is.”
