Significant vulnerabilities bear a striking resemblance to viruses like COVID-19. Is COVID-19 over now? Absolutely not. Does everyone write and talk about it? Not a lot. Is it going away? Not likely. Well, now you can apply the exact same statements to the Log4Shell Vulnerability.
The Log4j/Log4Shell vulnerability six months later
On July 11, 2022, six months after the events of December 2021, the Cyber Safety Review Board (CSRB) published a Log4j/Log4Shell vulnerability report. Page 18 of this report contains the following recommendation for the future:
Organizations must be prepared to address Log4j vulnerabilities for years to come.
CSRB makes it clear that the Log4j/Log4Shell vulnerabilities aren’t going away any time soon. He even points out that organizations should beware of regressions – situations where the current version of software is secure, but a vulnerable version is reintroduced in its place due to an uncontrolled process!
Why is the Log4j security vulnerability still alive and active?
You might be wondering: why is this Log4j security vulnerability still important if it is no longer zero-day and organizations have had six months to fix it? After all, lingering worry is only one of the few similarities between Log4Shell and COVID-19 – other than that, the situation is very different. The vulnerability does not self-propagate and seems very easy to fix – all you need to do is update some software!
Well, Log4Shell is not the first such threat that has persisted for a long time. Believe it or not, you can still find a high percentage of web servers using TLS 1.0 and vulnerable to BEAST attack (originally discovered in 2011, 30% of servers were still found to be vulnerable in 2020) as well as those using SSL 3.0 and vulnerable to poodle attacks (Originally discovered in 2014, 4% of servers were still found to be vulnerable in 2020). There are even quite a few web servers still vulnerable to Heartbleed bug (originally discovered in 2014, but 5 years ago, 200,000 servers were still vulnerable).
The following factors are why such cases still exist and why we can expect the exact same situation with vulnerable versions of the Log4j library:
Reason 1. Too many bugs, too little time
Almost all organizations find it difficult to fix all the bugs in their software before releasing it and for this reason almost all organizations accept the fact that some bugs will pass. It just doesn’t pay to have limited programming resources devoted primarily to fixing bugs and vulnerabilities when developers could instead be working on new features. It’s a calculated risk.
Organizations need to find a point at which it is still profitable to have vulnerable products as long as they have the functionality that customers need. For this reason, some organizations accept the risk from major vulnerabilities like Log4Shell, and instead of spending a lot of time patching all instances of Log4j, they accept their existence to save resources. It doesn’t look fun, but that’s life!
Reason 2. Use of improper software
Before troubleshooting your Log4shell problem, you must first know where you have a Log4shell problem. And many organizations invested in software that gave them a very limited view of the problem, missing the analysis of many assets.
Let’s be honest, while Log4Shell was a nightmare for most, it was a once-in-a-lifetime opportunity for security software makers. While we felt responsible to protect our customers, some wanted to monetize the panic and delivered feature-limited software with false promises that it would fix all Log4j problems. And, yes, many organizations assumed that would be enough, got those “free scanners” and ended up only scratching the surface of the issue.
Detecting and repairing Log4shell is highly dependent on the actual environment, and while we specify that we can help with web-based software and their dependencies, we also provide a mechanism (web asset discovery) that lets you find all of your web-based software so you know what you need to check. Not everyone does that.
Reason 3. Too hard to upgrade
It may seem that all it takes to fix Log4Shell is to upgrade all your instances of Log4j. Unless you’re an admin, you rarely have any idea how difficult and time-consuming these upgrades can be. This is because new releases of any type of software often introduce changes that could cause your entire environment to crash.
Imagine you have a version of Log4j on your server that you need to upgrade. The administrator will not just issue an upgrade command. First, they need to set up a staging environment that fully mirrors that of production. Then they should move all data and software (not just the affected server) to the staging area. Finally, they need to set up a bunch of tests (automatic and manual) to check if everything is working as expected and run those tests on the staging machine. Then they can attempt to upgrade Log4j and run these tests, often for a while, to make sure the upgrade “didn’t break anything”. Now imagine they have to do this for every affected instance of Log4j across the entire organization…
There are also many cases where you just can’t upgrade! This is the case for embedded systems and third-party software. If the organization, for example, uses a large number of IoT devices from different vendors, and those IoT devices are Linux/Java-based with Log4j and potentially exposed to the web, the organization should wait for the manufacturer to release an update. IoT firmware update. (if only). Ditto if you purchased your software from a third party – even if your security scanner warns you that there is a vulnerable instance of Log4j in that software, you cannot fix it yourself and are dependent on your vendor. Worse still, in some cases these vendors are no longer in business, and what changes the software completely? Try to hack it? Use a WAF try to reduce as much as possible? What a headache!
Be careful. Stay alert.
So what’s our point? While we understand that Log4Shell isn’t “the big news” anymore, you can’t just ignore it. The risk will always be there (well, we can’t say for sure it will be forever, but we believe it will be).
Just like with COVID-19, you can assume there’s less risk than before, and there’s no need to wear a mask all day and self-isolate at home, but at the same time, you probably won’t be standing in front of someone coughing loudly in the face. So don’t oppose Log4Shell either. Keep looking for it, keep prioritizing it, and keep your hands on the pulse if you don’t want to risk a criminal organization taking control of your systems and sensitive data via remote code execution.
The post office Why the Log4Shell vulnerability will never become yesterday’s news appeared first on Invicti.
*** This is a syndicated blog from the Security Bloggers Network of Invicti written by Tomasz Andrzej Nidecki. Read the original post at: https://www.invicti.com/blog/web-security/why-log4shell-vulnerability-will-never-become-yesterdays-news/