Four million outdated Log4j downloads were served from Apache Maven Central alone despite vuln publicity blitz
(2022/01/11)
- Reference: 1641889632
- News link: https://www.theregister.co.uk/2022/01/11/outdated_log4j_downloads/
- Source link:
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 [1]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.
[2]
Briefly, logged data that included user-provided strings could trigger the [3]execution of arbitrary code fetched from a remote server. More vulns were found in the following days: CVE-2021-45056, [4]CVE-2021-45105 , and CVE-2021-44832.
[5]
[6]
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.
[7]
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 [8]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."
[9]You better have patched those Log4j holes or we'll see what a judge has to say – FTC
[10]Log4j RCE: Emergency patch issued to plug critical auth-free code execution hole in widely used logging utility
[11]Bad things come in threes: Apache reveals another Log4J bug
[12]Sysadmins: Why not simply verify there's no backdoor in every program you install, and thus avoid any cyber-drama?
With the US Federal Trade Commission having [13]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 [14]here , suggesting exploitation may have been under-reported for various reasons.
[15]
That said, Belgium's defence ministry was [16]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 [17]not waited long enough between local disclosure and disclosure to the wider world. ®
Get our [18]Tech Resources
[1] https://www.cisa.gov/uscert/ncas/alerts/aa21-356a
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Yd1jXAlIu55ng5zEIjZIewAAAQY&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://www.theregister.com/2021/12/10/log4j_remote_code_execution_vuln_patch_issued/
[4] https://www.theregister.com/2021/12/19/log4j_new_flaw_cve_2021_45105/
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Yd1jXAlIu55ng5zEIjZIewAAAQY&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Yd1jXAlIu55ng5zEIjZIewAAAQY&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Yd1jXAlIu55ng5zEIjZIewAAAQY&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[8] https://www.theregister.com/2021/12/14/apache_log4j_2_16_jndi_disabled/
[9] https://www.theregister.com/2022/01/05/ftc_log4j_fix/
[10] https://www.theregister.com/2021/12/10/log4j_remote_code_execution_vuln_patch_issued/
[11] https://www.theregister.com/2021/12/19/log4j_new_flaw_cve_2021_45105/
[12] https://www.theregister.com/2021/07/31/enisa_supply_chain_attack_report/
[13] https://www.theregister.com/2022/01/05/ftc_log4j_fix/
[14] https://twitter.com/gmbednarski/status/1479435603976634369
[15] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Yd1jXAlIu55ng5zEIjZIewAAAQY&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[16] https://www.theregister.com/2021/12/21/belgium_defence_ministry_log4j_exploited/
[17] https://www.theregister.com/2021/12/23/alibaba_cloud_in_trouble_with/
[18] https://whitepapers.theregister.com/
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 [1]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.
[2]
Briefly, logged data that included user-provided strings could trigger the [3]execution of arbitrary code fetched from a remote server. More vulns were found in the following days: CVE-2021-45056, [4]CVE-2021-45105 , and CVE-2021-44832.
[5]
[6]
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.
[7]
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 [8]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."
[9]You better have patched those Log4j holes or we'll see what a judge has to say – FTC
[10]Log4j RCE: Emergency patch issued to plug critical auth-free code execution hole in widely used logging utility
[11]Bad things come in threes: Apache reveals another Log4J bug
[12]Sysadmins: Why not simply verify there's no backdoor in every program you install, and thus avoid any cyber-drama?
With the US Federal Trade Commission having [13]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 [14]here , suggesting exploitation may have been under-reported for various reasons.
[15]
That said, Belgium's defence ministry was [16]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 [17]not waited long enough between local disclosure and disclosure to the wider world. ®
Get our [18]Tech Resources
[1] https://www.cisa.gov/uscert/ncas/alerts/aa21-356a
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Yd1jXAlIu55ng5zEIjZIewAAAQY&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://www.theregister.com/2021/12/10/log4j_remote_code_execution_vuln_patch_issued/
[4] https://www.theregister.com/2021/12/19/log4j_new_flaw_cve_2021_45105/
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Yd1jXAlIu55ng5zEIjZIewAAAQY&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Yd1jXAlIu55ng5zEIjZIewAAAQY&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Yd1jXAlIu55ng5zEIjZIewAAAQY&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[8] https://www.theregister.com/2021/12/14/apache_log4j_2_16_jndi_disabled/
[9] https://www.theregister.com/2022/01/05/ftc_log4j_fix/
[10] https://www.theregister.com/2021/12/10/log4j_remote_code_execution_vuln_patch_issued/
[11] https://www.theregister.com/2021/12/19/log4j_new_flaw_cve_2021_45105/
[12] https://www.theregister.com/2021/07/31/enisa_supply_chain_attack_report/
[13] https://www.theregister.com/2022/01/05/ftc_log4j_fix/
[14] https://twitter.com/gmbednarski/status/1479435603976634369
[15] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Yd1jXAlIu55ng5zEIjZIewAAAQY&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[16] https://www.theregister.com/2021/12/21/belgium_defence_ministry_log4j_exploited/
[17] https://www.theregister.com/2021/12/23/alibaba_cloud_in_trouble_with/
[18] https://whitepapers.theregister.com/
Joe W
And I even feel that I saw some type of this behaviour a few years back - maybe with the ssl stuff-up?
spireite
I know this will be an unpopular viewpoint, but why not just yank the bugged versions?
Oh, injetc into said buggy versions a banner/print/whatever.....
If the update is so important (it is), then maybe they should force auto-builds to fail by renaming the vulnerable versions to something the scripts do not find for auto/scripted downloads. You can also poison the vulnerable versions at the source and having them bail out on first call with a log-message "please update".
These would be (very) hard measures, but it may be necessary for the long tail to become shorter.