Why the Log4Shell vulnerability will never become yesterday’s news

Significant vulnerabilities bear a striking resemblance to viruses like COVID-19. Is COVID-19 over now? Absolutely not. Is everyone writing and talking about it? Not many. Is it ever going away? Not likely. Well, you can now apply precisely the same statements to the Log4Shell vulnerability.

The Log4j/Log4Shell vulnerability half a year later

On July 11, 2022, half a year after the December 2021 events, the Cyber Safety Review Board (CSRB) published a report on the Log4j/Log4Shell vulnerabilities. Page 18 of this report contains the following recommendation for the future:

Organizations should be prepared to address Log4j vulnerabilities for years to come.

CSRB makes it clear that Log4j/Log4Shell vulnerabilities are not going away anytime soon. It even makes it clear that organizations should be wary of regressions – situations where the current software version is secure, but a vulnerable version is reintroduced in its place because of an uncontrolled process!

Why is the Log4j security vulnerability still alive and kicking?

You may ask yourself – why is this Log4j security vulnerability still significant if it’s no longer zero-day and organizations have had half a year to address it? After all, the ongoing concern is only one of the few resemblances between Log4Shell and COVID-19 – other than that, the situation is very different. The vulnerability does not spread by itself, and it seems very easy to fix – all you need to do is update one piece of software!

Well, Log4Shell is not the first such threat that has lingered on 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 the BEAST attack (originally discovered in 2011, 30% of servers were found to be still vulnerable in 2020) as well as ones using SSL 3.0 and vulnerable to the POODLE attack (originally discovered in 2014, 4% of servers were found to be still vulnerable in 2020). There are even quite a few web servers still vulnerable to the Heartbleed bug (originally discovered in 2014, but 5 years ago, 200,000 servers were still vulnerable).

The following factors are the reasons why such cases still exist and why we can expect precisely the same situation with vulnerable versions of the Log4j library:

Reason 1. Too many bugs, too little time

Almost every organization is struggling with fixing all the bugs in their software before releasing it, and, for that reason, almost every organization accepts the fact that some bugs are going to make it through. It simply does not pay to have limited programming resources devoted primarily to fixing bugs and vulnerabilities while developers could be working on new features instead. It’s a calculated risk.

Organizations need to find a point at which it still pays to have vulnerable products out as long as they have features needed by the customers. For that reason, some organizations accept the risk coming from major vulnerabilities like Log4Shell, and instead of spending a lot of time on remediating all the instances of Log4j, they accept their existence to save resources. Doesn’t sound fun, but that’s life!

Reason 2. Using inadequate software

Before you fix 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 out on scanning many assets.

Let’s be honest, while Log4Shell was a nightmare to most, it was an opportunity of a lifetime for security software makers. While we felt the responsibility to safeguard our customers, some wanted to monetize on the panic and delivered limited-functionality software along with false promises that it would solve all the Log4j problems. And, yeah, many organizations assumed that it would be enough, got those “free scanners,” and ended up only scratching the surface of the problem.

Detecting and fixing Log4shell depends greatly on the actual environment, and while we make it clear that we can help with web-facing software and its dependencies, we also provide a mechanism (web asset discovery) that lets you actually find all your web-facing software so you know what you have to check. Not everyone does that.

Reason 3. Too difficult to upgrade

It may seem that all it takes to fix Log4Shell is to upgrade all your instances of Log4j. Unless you’re an administrator, you rarely have an idea how difficult and time-consuming such upgrades may be. This is because new versions of any kind of software often introduce changes that may cause a breakdown of your entire environment.

Imagine that you have a Log4j version on your server that you need to upgrade. The administrator won’t just issue an upgrade command. First, they have to set up a staging environment that fully mirrors the production one. Then, they have to move all the data and all the software (not just the affected server) to the staging area. Finally, they have to set up a bunch of tests (automatic and manual) to check whether everything is working as intended and run these tests on the staging machine. Then, they can attempt to upgrade Log4j and run these tests, often for some time, to ascertain that the upgrade “did not break anything.” Now, imagine they have to do that for every affected instance of Log4j in the entire organization…

There are also quite a lot of cases where you simply cannot upgrade at all! This is the case with embedded systems and third-party software. If the organization, for example, uses a lot of IoT devices from different vendors and these IoT devices are based on Linux/Java with Log4j and potentially exposed to the web, the organization must wait for the manufacturer to issue an update to the IoT firmware (if any). Same if you purchased your software from a third party – even if your security scanner alerts you that there’s a vulnerable instance of Log4j in that software, you can’t fix it yourself, and you’re dependent on your vendor. Worse off, in some cases, these vendors are no longer in business, and what then, change the software entirely? Try to hack it? Use a WAF to try to mitigate as much as possible? What a headache!

Stay safe. Stay vigilant.

So what’s our point? While we understand that Log4Shell is no longer “the big news,” you can’t just dismiss it. The risk is always going to be there (well, we can’t say for sure that it’s going to be forever, but we feel it will).

Just like with COVID-19, you can assume that there is less risk than before, and there’s no need to wear a mask all day long and isolate yourself at home, but at the same time, you probably won’t be standing in front of someone coughing loudly in your face. So don’t stand in the face of Log4Shell either. Continue scanning for it, continue prioritizing it, and keep your hand on the pulse if you don’t want to risk a criminal organization taking over your sensitive systems and data via remote code execution.