There have been millions of downloads of outdated, vulnerable Log4j versions despite the emergence of a serious security hole in December 2021, according to figures compiled by the firm that runs Apache Maven’s Central Repository.
That company, Sonatype, said it had seen four million downloads of exploitable Log4j versions from the repository alone between 10 December and the present day, out of a total of more than 10 million downloads over those past four weeks.
Tracked as CVE-2021-44228 aka Log4shell, the original vulnerability affected version 2.14 and earlier of the 2.x branch of the Apache logging utility. It was patched on December 10 in version 2.15.
Briefly, logged data that included user-provided strings could trigger the execution of arbitrary code fetched from a remote server. More vulns were found in the following days: CVE-2021-45056, CVE-2021-45105, and CVE-2021-44832.
Sonatype’s field CTO Ilkka Turunen told The Register the number of downloads of pre-2.15 versions of Log4j from the Maven central repository was oddly high. Around 40 per cent of downloads initiated from the UK alone over the past couple of days were of outdated versions.
“Now, it’s not entirely clear to us whether or not it’s legacy software, whether or not it is testing versions, and things like this, but what it seems to suggest is that there is a population of users that are downloading it,” Turunen told The Register, adding that these people are probably “completely unaware” that their version is outdated.
Maven’s central repository is where a large number of Java-based projects retrieve required libraries from.
Interestingly enough, Sonatype said about 42 per cent of total downloads of Log4j over the weekend were of the very latest versions, 2.17 and 2.17.1 – the main Log4shell vulnerabilities were addressed by 2.16 – which suggests that at least some organisations are not just installing the patched versions of 2.15 or 2.16 but picking up the very latest.
As for the cause of the outdated downloads, Turunen opined: “There’s this sort of long tail of, of software where it’s still being built… not necessarily as a direct dependency.”
With the US Federal Trade Commission having threatened legal action against American organisations that don’t upgrade Log4j to non-exploitable versions, there’s little excuse in the English-speaking world for not having noticed the fact that there’s something up with Log4j. Apache itself, to its credit, wasn’t shy about highlighting this on its own site. If you’re pulling in the logging code from a remote repo, perhaps as part of an automated process, now is a good time to double-check exactly what you’re getting.
Exploitation of Log4j vulns appears to have been visibly limited despite high levels of vuln scanning being detected once the news was out there. There’s an interesting Twitter thread about that here, suggesting exploitation may have been under-reported for various reasons.
That said, Belgium’s defence ministry was successfully attacked via the Log4j hole, though ministerial spokespeople did not elaborate on how exactly the attackers got in nor what they did once they had succeeded.
In addition, a frustrated Chinese ministry lashed out at Alibaba Cloud for reporting the vulnerability to Westerners in the first place, the tech giant having apparently not waited long enough between local disclosure and disclosure to the wider world. ®