Two years on, 1 in 4 apps still vulnerable to Log4Shell
- Reference: 1702306869
- News link: https://www.theregister.co.uk/2023/12/11/log4j_vulnerabilities/
- Source link:
Research from security shop Veracode revealed that the vast majority of vulnerable apps may never have updated the Log4j library after it was implemented by developers as 32 percent were running pre-2015 EOL versions.
Prior investigations from Veracode also showed that 79 percent of all developers never update third-party libraries after first introducing them into projects, and given that Log4j2 – the specific version of Log4j affected by the vulnerability – dates back to 2014, this could explain the large proportion of unpatched apps.
[1]
A far smaller minority are running versions that were vulnerable at the time of the [2]Log4j vulnerability's disclosure in December 2021. Only 2.8 percent are still using versions 2.0-beta9 through 2.15.0 – post-EOL versions that remain exposed to Log4Shell, the industry-coined moniker of the vulnerability's exploit.
[3]
[4]
Some 3.8 percent are still running version 2.17, a post-patch version of the Java logger that's not exposed to Log4Shell attacks, but is vulnerable to a separate remote code execution (RCE) bug (CVE-2021-44832).
The researchers believe this illustrates a minority of developers that acted quickly when the vulnerability was first disclosed, as was the advice at the time, had returned to older habits of leaving libraries untouched.
[5]
Altogether, just shy of 35 percent remain vulnerable to Log4Shell, and nearly 40 percent are vulnerable to RCE flaws.
The EOL versions of Log4j are also vulnerable to three additional critical bugs announced by Apache, bringing the total to seven high and critical-rated issues.
"At a surface level, the numbers above show that the massive effort to remediate the Log4Shell vulnerability was effective in mitigating risk of exploitation of the zero-day vulnerability. That should not be surprising," [6]said Chris Eng, chief research officer at Veracode.
[7]
"The bigger story at the two-year anniversary, however, is that there is still room for improvement when it comes to open source software security. If Log4Shell was another example in a long series of wake-up calls to adopt more stringent open source security practices, the fact that more than one in three applications currently run vulnerable versions of Log4j shows there is more work to do.
"The major takeaway here is that organizations may not be aware of how much open source security risk they are exposed to and how to mitigate it."
[8]Regulator, insurers and customers all coming for Progress after MOVEit breach
[9]curl vulnerabilities ironed out with patches after week-long tease
[10]Fresh curl tomorrow will patch 'worst' security flaw in ages
[11]Five Eyes nations detail dirty dozen most exploited vulnerabilities
The larger issue at play isn't just the failure to apply patches. According to [12]Sonatype , the number of Log4j downloads containing vulnerable versions just in the last seven days stands at 26 percent of a total 3.7 million.
It's a phenomenon that hasn't changed much since Log4Shell's disclosure either, with 26 percent of all downloads since December 2021 vulnerable to the RCE exploit.
When it was first revealed, the vulnerability in Log4j catalyzed widespread fear in the infosec community, given its critical nature and the number of organizations whose software relied on it – a figure Veracode believed to have been around 88 percent at the time.
The predictions were that the bug was so dangerous, so exploitable, and so serious that it would haunt the industry for many months into 2022, and others like the US Department of Homeland Security speculated it could [13]linger for longer than a decade .
The director at the US Cybersecurity and Infrastructure Security Agency (CISA) [14]said at the time it was the "most serious" vulnerability she had seen in her career.
However, fast action and urgent awareness campaigns ultimately meant the damage wasn't as intense as many first feared.
Log4Shell did cause some high-profile issues, though, such as an [15]attack on a US government network at the hands of Iranian state-sponsored cybercriminals, and the [16]Belgian defense ministry mere weeks into the furore.
Though most organizations patched to secure versions within weeks rather than dealing with exploits, often the biggest pain felt was the patching process itself, which could have involved hundreds of apps, depending on the organization. ®
Get our [17]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZXdANlJR4tTuIkjx2itpCwAAAFg&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://www.theregister.com/2021/12/10/log4j_remote_code_execution_vuln_patch_issued/
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZXdANlJR4tTuIkjx2itpCwAAAFg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZXdANlJR4tTuIkjx2itpCwAAAFg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZXdANlJR4tTuIkjx2itpCwAAAFg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://www.veracode.com/blog/research/state-log4j-vulnerabilities-how-much-did-log4shell-change
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZXdANlJR4tTuIkjx2itpCwAAAFg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[8] https://www.theregister.com/2023/10/16/infosec_in_brief/
[9] https://www.theregister.com/2023/10/11/vulnerabilities_in_curl_receive_patches/
[10] https://www.theregister.com/2023/10/10/curl_patch_in_update/
[11] https://www.theregister.com/2023/08/07/in_brief_security/
[12] https://www.sonatype.com/resources/log4j-vulnerability-resource-center
[13] https://www.theregister.com/2022/07/14/dhs_warns_expect_log4j_risks/
[14] https://www.theregister.com/2022/04/28/most_exploited_vulnerabilities_2021/
[15] https://www.theregister.com/2022/11/16/iranian_cyberspies_log4j/
[16] https://www.theregister.com/2021/12/21/belgium_defence_ministry_log4j_exploited/
[17] https://whitepapers.theregister.com/
No surprise really
Some orgs will be on top of things and use tools that will alert them to the vulnerability issues & help resolve them
e.g. whitesource AKA mend.io provide some good commercial tools*, and there's plenty of free tools that can help.
Unfortunately lots of orgs don't do that (even though, with open source its easier to keep on top of things as ultimately you have the code and can update dependencies etc.)
There are nasty areas where issues can creep in with many dependencies and code vulnerabilities.
If you use product X, that has a dependency on product Y (amongst many other products),
Lets say product Y has a nasty vulnerability, that is fixed in version 6.0
Your product X, uses Y 5.8
Y6.0 has some breaking functionality changes compared to 5.8 e.g. removes some decrepitated APIs that X uses.
In this scenario its not just the easy fix of get Y 6.0
You also need either the developer of X to change their code to be compatible with Y6.0 (or rearchitect it to not need Y) or, worse case, you need to make changes to product X codebase yourself.
Breaking changes across versions preventing the "easy fix" of just grabbing patched version of product at fault (& typically a patch only been done in a newer release and not back ported to older versions with different APIs / functionality) is one of the main causes I have seen of code with known CVEs still being used as the fix is non trivial.
You can easily find products with a large number of dependencies on other products (which is sensible in a way, e.g. why reinvent the wheel and write lots of code to export your data to CSV when you can use product M to do the hard work and you just make a few lines change to call to it (saving you time and effort) - but the issues of non maintained products, breaking chnages can come back to bite.
For the many, many faults of MS, they have been reasonably good at keeping breaking changes to API / method calls to a minimum, this is not always the case in *some* open source projects, where APIs /methods can often change a lot across versions.
* Lots of commercial tools out there, just mentioned mend.io based on having actually used some of their tools
I recently ran into this with mremote-ng, a windoze software client for ssh and remote desktop use, so like something mostly system administrators would use was still using an ancient vulnerable log4net, a variation of log4j with the same vulnerabilities. My FortiClient EPP software noticed it to alert, luckily I had some enterprise security to do so, but how many others do not?
Looking up the software project's github to post an issue, someone else with the same alert from FortiClient told them years ago, and they closed it, telling someone to get the "nightly" version vs. the ancient and non-updated main app from the website that you know, 99% of people including myself would just download to use. I opened a new ticket asking them patch the main version ffs too, and finally did after some nagging and public shaming, but by this point I already uninstalled it, cursed having to use anything like that on windoze in the first place.
Anything on windoze, particularly 3rd party software I imagine is all a rats nest of vulnerable dependencies that never get updated. I use windoze for anything as little as possible for that reason alone, usually only keeping it around as my visio runtime.