Should Log4Shell Still Keep CISOs Up at Night?

In December 2021, the Apache Software Foundation disclosed that the popular Log4j framework contained a critical vulnerability that allowed remote code execution (RCE). It caused a security earthquake, keeping many CISOs up at night. The aftershocks are still felt.

The vulnerability, known as Log4Shell, was extremely easy to exploit. Put simply, it allowed any malicious attacker to remotely inject Java classes into a vulnerable process, allowing the attacker to do anything they wanted.

In response to the news, nearly every software vendor provided patches or tools to detect Log4j vulnerabilities. Now, months since the initial Log4j threat, CISOs wonder if they should still be worried about Log4j’s impact.

Is Log4Shell still an issue for organizations?

Invicti found that weekly detection rates are now less than 1% of what they were at the peak shortly after the Apache Software Foundation disclosed the vulnerability. Over 82% of Log4Shell vulnerabilities were confirmed to be fixed in subsequent dynamic scans of vulnerable applications.

As an industry, this is excellent news; it suggests that automated scanning of applications has helped detect and fix thousands of instances of vulnerabilities. However, something you think is secure today may not be tomorrow or even an hour from now, and organizations must check for security vulnerabilities continuously.

How can CISOs assess if Log4j is still in their environment?

It is best to fix vulnerabilities left in the development process while also implementing application security testing on the right (i.e., staging and production). As a start, security leaders can build software composition analysis (SCA) into the software development life cycle (SDLC) to ensure that software is scanned whenever it is changed as part of a CI/CD pipeline.

But the real danger with Log4Shell is older applications, and CISOs must be aware of this potential threat. These applications may be deployed without a modern CI/CD pipeline or may even be running on the network without active maintenance or development.

Older apps often live in dusty layers of application infrastructure, only invoked occasionally outside the typical execution flow. However, tools like asset discovery and dynamic application security testing (DAST) can scan applications with web and API interfaces to detect vulnerabilities.

It’s also important to work with a security tools vendor you trust to release timely updates when there are new exploits, like Log4Shell.

Why do new applications and pieces of software still contain Log4Shell months after disclosure?

Since modern software tends to be a patchwork of many disparate components, fixing Log4Shell vulnerabilities isn’t that simple. Sometimes these dependencies are transitive – a software developer adds an open-source package that depends on a package that then depends on Log4j. Because of this, the developer has no idea they introduced a vulnerable component into their code.

Other times, a newer customer-facing microservice calls into a legacy system that’s not directly exposed to the internet but is used in a new way, perhaps with more modern usage of an API. This more recent way of calling an API could result in data being passed differently, which causes the legacy system to issue a non-fatal warning log. But if that backend system isn’t patched, that log can contain an injection payload that ultimately exposes remote code execution (RCE). Because software systems aren’t simple, it isn’t enough to say: my software is secure enough. Your applications depend on plenty of other software, and those dependencies could be exposed in new ways, further allowing your application software to become exploited.

It’s been six months since Log4Shell, and while the threat landscape isn’t zero, knowing your organization’s entire attack surface is a critical first step to avoiding any future Log4j-related threats. In addition, adopting a continuous modern application security testing solution that allows for integrations, automation, and accuracy will help organizations stay ahead of future exposures.

So as a CISO, should you be up late at night worrying about Log4j? At this point, probably not if you have the right tools and plan in place. As the data suggests, regular security scanning will lead to the peace of mind you need to sleep more soundly.