The Log4j crisis continues, with new developments almost daily.
Among the latest developments
–Apache has issued a third update to correct bugs in the Java-based logging library for open source applications
–a new way has been discovered by researchers at Blumira that threat actors might use to compromise IT systems vulnerable to bugs in the library;
–the Conti ransomware group is reportedly exploiting VMware vCenter Server instances through the Log4j vulnerabilities;
–the exploit, known by some researchers as Log4Shell or LogJam, is reportedly being used to deploy TellYouThePass ransomware, an old and inactive ransomware family;
–to help IT teams find applications that include older versions of Log4j2, Google has updated its free fuzzing service, called OSS-Fuzz;
–the issue is so serious that the U.S. Cybersecurity and Infrastructure Security Agency (CISA) has told American federal agencies to forget the Dec. 24 deadline for patching or mitigating IT systems — they have to do it ASAP.
UPDATE: In a statement this morning, Canada’s Communications Security Establishment (CSE), which protects federal IT systems, said its work continues. “While the government continues to operate with an abundance of caution, we have no indication that these vulnerabilities were exploited. The government has robust systems and tools in place to monitor, detect and investigate potential threats and takes active measures to address and neutralize them.”
To give an idea of the size of the problem, Google said more than 35,000 Java packages, amounting to over eight per cent of the Maven Central repository — the most significant Java package repository — are impacted by the recently disclosed log4j vulnerabilities.
As of Sunday, nearly 5,000 of the affected artifacts have been fixed. This represents a rapid response and a mammoth effort both by the log4j maintainers and the wider community of open source consumers, Google said. But it leaves 30,000 packages to be fixed.
“Most artifacts that depend on log4j do so indirectly,” Google emphasized. “The deeper the vulnerability is in a dependency chain, the more steps are required for it to be fixed.” For greater than 80 per cent of the packages, the vulnerability is more than one level deep, with a majority affected five levels down (and some as many as nine levels down). These packages will require fixes throughout all parts of the tree, starting from the deepest dependencies first.”
The latest patch. Apache says application developers need to update Log4j libraries to version 2.17 to ensure that recursive lookups do not cause services to fail through a distributed-denial-of-service attack. It addresses CVE-2021-45105.
New attack vector
Blumira’s security team said it discovered the potential for an alternative attack vector in the Log4j vulnerability, which relies on a Javascript WebSocket connection to trigger remote code execution on internal and locally exposed unpatched Log4j applications.
Earlier reports said the impact of Log4j was limited to vulnerable servers. “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,” Blumira said. The client itself generally has no direct control over these WebSocket connections, the report said, which can silently initiate when a webpage loads. WebSocket connections within the host can be difficult to gain deep visibility into, which increases the complexity of detection for this attack.
“This vector significantly expands the attack surface and can impact services even running as localhost which were not exposed to any network.”
Its proof of concept was released Thursday. At that point the company hadn’t seen any active exploitation.
A common part of browsers, WebSockets are used for applications like chat and alerts on websites to pass data back and forth. But, the report notes, WebSockets are not restricted by same-origin policies like a normal cross-domain HTTP request and they expect the server itself to validate the Origin of the request.
Blumira urges developers or IT teams to update internal applications and internet-facing environments using Log4j to version 2.16 as soon as possible. (As mentioned above the latest version is 2.17.). They should review and update or implement egress filtering to ensure that callbacks are not successful in many cases; detect when .*/java.exe is the parent process for cmd.exe/powershell.exe – this is potentially very noisy; and ensure that your host detection for exploitation of Cobalt Strike, Trickbot, and related common attacker tools are functioning as intended and that you have the needed visibility to do so.
They should also implement NoScript on untrusted sites to avoid javascript randomly being loaded and initiating WebSockets.
Known exploits
Threat researchers at AdvIntel said the Conti ransomware gang has already successfully exploited VMware vCenter installations that are vulnerable to the Log4j2 weaknesses and used it for lateral movement in a compromised network. Conti began looking for vulnerable vCentre instances almost as soon as the hole was publicly announced.
The news site Curated Intelligence says threat reports in the Chinese-speaking community indicate Log4Shell is being used to deploy TellYouThePass ransomware, an old and until now inactive ransomware family. The story says several researchers reported this on Twitter as far back as December 13th.
New tool
Open-source software development teams that use Google’s OSS-Fuzz program to uncover security coding errors can now use it to help find Log4j libraries. Google said partnered with the security company Code Intelligence to provide continuous fuzzing for Log4j, as part of OSS-Fuzz. Also as part of this partnership, Code-Intelligence improved their Jazzer fuzzing engine to make it capable of detecting remote JNDI lookups. For those who don’t know, fuzz testing — or fuzzing — inserts random data into an application to see if the software crashes.
Meanwhile, the exhaustive — and sometimes exhausting — hunt to root out all instances of Log4j has sparked a resurgence in the idea of having CIOs/CISOs demand developers include a software bill of materials (SBOM) in their applications to at least help find reported flaws.
But an article from SC Media quotes experts saying an SBOM doesn’t solve everything. SBOM would not identify what applications run in an environment, or where they are running, says the story, nor force in-house application designers to abide by the SBOM requirements or guarantee that the SBOMs were kept track of in any usable way.