The computer security industry is bracing for travel on long, bumpy roads littered with Log4j security problems as experts warn that software dependency patching hiccups will slow global mitigation efforts.
The sheer scale and impact of the crisis became a bit clearer this week with Google’s open-source team reporting that a whopping 35,863 Java packages in Maven Central are still using defective versions of Log4j library. (Editor’s note: Maven Central is the largest and most significant Java package repository).
“This means that more than 8% of all packages on Maven Central have at least one version that is impacted by this vulnerability,” according to a note from researchers James Wetter and Nicky Ringland of Google’s Open Source Insights Team.
“As far as ecosystem impact goes, 8% is enormous. The average ecosystem impact of advisories affecting Maven Central is 2%, with the median less than 0.1%,” the Google team explained.
The vulnerability, flagged as CVE-2021-44228, was first discovered and reported by the Alibaba cloud security team on November 24 this year. Less than two weeks later, exploitation was spotted in the wild, prompting the release of multiple high-priority patches and an industry-wide scramble to apply practical mitigations.
[ READ: Exploits Swirling for Major Security Defect in Apache Log4j ]
Over the last two weeks, nation-state APT actors linked to China, Iran, North Korea and Turkey have added exploits for the code-execution flaw into hacking toolkits and there are multiple reliable reports that ransomware and botnet gangs are also launching Log4j malware exploits.
With security programs around the world in full-blown crisis mode, experts are warning that eradicating the problem will be a long, laborious process because of software dependencies and so-called “transitive dependencies” that make patching very difficult.
“[It’s still] difficult to determine the full blast radius of this vulnerability,” said Google’s Wetter.
Among the 35,863 vulnerable Java artifacts on Maven Central, the Google team found that direct dependencies account for around 7,000 of the affected artifacts, meaning that any of their versions depend upon an affected version of log4j-core or log4j-api, as described in the CVEs.
“The majority of affected artifacts come from indirect dependencies (that is, the dependencies of one’s own dependencies), meaning log4j is not explicitly defined as a dependency of the artifact, but gets pulled in as a transitive dependency,” the researchers explained.
The team described a “mammoth effort” among rapid responders to find and fix the underlying security vulnerabilities but noted that tens of thousands of artifacts are blocked from being patched.
[ READ: Microsoft Spots Multiple Nation-State APTs Exploiting Log4j Flaw ]
“At the time of writing, nearly five thousand of the affected artifacts have been fixed. This represents a rapid response and mammoth effort both by the log4j maintainers and the wider community of open source consumers. That leaves over 30,000 artifacts affected, many of which are dependent on another artifact to patch (the transitive dependency) and are likely blocked.”
The main issue at stake is that most artifacts depend on Log4j indirectly, meaning that the deeper the vulnerability is in a dependency chain, the more steps are required for it to be fixed.
“For greater than 80% of the [affected] packages, the vulnerability is more than one level deep, with a majority affected five levels down and some as many as nine levels down,” the Google team said. “These packages will require fixes throughout all parts of the tree, starting from the deepest dependencies first.”
The researchers believe it will be “a long wait, likely years” before all the artifacts affected by the Log4j vulnerabilities are fully patched.
[ SEE: Continuously Updated – Log4Shell Tools and Resources for Defenders ]
Threat hunters at edge security giant Akamai Technologies say there’s already “a global tsunami of malicious activity” linked to the Log4j flaws and warn that the vulnerability will have a very long attack tail.
A research note from Akamai warns of scanning reconnaissance in “massive, successive waves” as attackers found new attack vectors, firewall filter bypasses and exploit variations.
“From our data we can tell that ~57% of the attacking infrastructure sending log4j exploits was already known to Akamai from previous attacks — essentially, the tsunami came from existing malicious actors being opportunistic as much as it did from new attackers,” Akamai said, noting that networks in the U.S. are bearing the brunt of the attacks.
Related: Exploits Swirling for Major Security Defect in Apache Log4j
Related: Microsoft Spots Multiple Nation-State APTs Exploiting Log4j Flaw
Related: Log4j Update Patches New Vulnerability That Allows DoS Attacks
Related: Log4Shell Tools and Resources for Defenders – Continuously Updated
