Three years after its discovery, Log4Shell remains one of the software flaws that are most used by threat actors, a new report released by Cato Networks has found. The report exposed a 61% quarter one to quarter two increase in the attempted use of the vulnerability in inbound network traffic and a 79% increase in use in WAN-bound traffic during the same period.
Log4Shell is a type of vulnerability that adversaries favor because it enables them to perform remote code execution (RCE) in Log4j. That open-source logging library for applications written in Java, which is one of the most widely used programming languages in the world, attracts attackers because of its expansiveness, said Cato's chief security strategist, Etay Maor.
"Log4j continues to be a favored vulnerability for attackers to exploit due to its widespread presence in numerous global systems."
—Etay Maor
Here's what you need to understand about why Log4j remains a threat — and how to protect your organization.
[ See RL's new Essential Guide: Software Supply Chain Security for Dummies ]
Why Log4j remains a target for threat actors
Log4j allows attackers to establish a foothold to mount larger attacks — and run almost any code they want in a system with the vulnerability. Jason Soroko, vice president of product at Sectigo, said Log4j’s deep integration in Java-based systems also provides attackers with extensive reach.
"The ease of exploitation means even less-sophisticated threat actors can leverage it effectively."
—Jason Soroko
MJ Kaufmann, an author and instructor with O'Reilly Media, said that there is no reason to invest in a novel new attack when you have a working, easily accessible one.
"Most cybercriminals like to grab low-hanging fruit."
—MJ Kaufmann
Many organizations are not aware of how much open-source security risk they are exposed to and how to mitigate it. Chris Eng, chief research officer at Veracode, said his team's analysis of Log4j found that more than one-third of applications currently run vulnerable versions and 79% of the time developers never go back to update third-party libraries after including them in a codebase.
“This helps explain why such a large percentage of applications are running ancient versions of Log4j, leaving them open to attack by threat actors.”
—Chris Eng
ReversingLabs evangelist Josh Knox said that since Java has been around a long time, there are a lot of apps with Log4j that people keep using despite the flaw.
“They don't even know that their applications are using it. It could be several dependencies deep. They look at their application's code and don't see Log4j there. And it's not, but the app is using a library that uses Log4j that never got updated. So it just seems to keep rearing its ugly head.”
—Josh Knox
SBOMs to the rescue?
One reason the Log4Shell vulnerability continues to exist is that many organizations still lack formalized processes for creating software bills of materials (SBOMs), said Michael Skelton, vice president of operations and hacker success at Bugcrowd.
“That makes it difficult to track Log4j within complex software dependencies. Due to this, even where code reviews have taken place, the use of an external but vulnerable dependency can impact upstream applications, leading to a continued prevalence of Log4j.”
—Michael Skelton
Log4j is embedded in so many applications and systems that completely eradicating it is extremely difficult, said Cato’s Maor.
“The root of the issue lies in identifying all instances of Log4j, especially when it is nested in legacy systems or third-party applications. It’s like trying to find a needle in a haystack.”
—Etay Maor
Even if an organization has the ability to find all the instances of Log4j, they may have thousands of instances of it across the entirety of their application portfolio, said Joe Nicastro, field CTO for Legit Security.
“That means a lot of them have triaged and only fixed this issue in the most critical applications that have this vulnerability, leaving lots of instances untouched because of lack of resources to fix all the instances.”
—Joe Nicastro
However, the issue goes beyond Log4j, Maor said. Log4j simply exposes the underlying complexity of today’s security infrastructure. "There are too many point solutions, which can leave organizations exposed if not properly integrated," he said.
ReversingLabs' Knox wrote recently that the security issues surrounding software supply chain security are broad, but most revolve around three issues: misplaced trust in third-party components, the double-edged sword of automated updates, and challenges in visibility across complex software supply chains.
The best way to protect your organization against these types of potential threats is by changing your mindset about software supply chain security — and upgrading your application security approach, Knox wrote, adding:
"Ask yourself: What am I running in my environment? What am I allowing for updates? Is there something that has low-level control over my systems that could blow up at any moment? What are people or processes putting into my systems, who’s responsible for those updates, and do those entities perform adequate testing before issuing an update?"
How to prevent a Log4j fail in your organization
While the fight to mitigate Log4j appears to be a desperate battle, some promising efforts have developed to address similar problems in the future. For example, virtual patching provides a temporary fix for a vulnerability or weakness in a system or application without actually modifying the underlying code, Maor said.
“The reality is that vulnerabilities will always exist — both now and in the future. You may not be able to identify all of them immediately, but with virtual patching, you can ensure that they can't be exploited while you work on eradicating the root cause. It’s about safeguarding the system first and then dealing with the underlying issue once you know you're protected.”
—Etay Maor
Organizations are starting to put secure frameworks in place to help developers write more secure code, Veracode's Eng said. “Many organizations are investing in paved-road security, which involves developing shared tools, libraries, and processes to ensure developers write safe code by default."
And AI has transformed vulnerability discovery and remediation, Eng added. The task of finding and fixing vulnerabilities used to be repetitive, expensive, and time-consuming for developers, but AI now plays a pivotal role in automating security flaw fixes by leveraging advanced machine-learning algorithms to analyze and understand code patterns. "The toil of correcting insecurities will decrease over time as developers increasingly integrate AI-powered remediation tools that enable them to scan earlier in development, as well as analyze open source code,” Eng said.
Software supply chain security is the comprehensive fix
Legit Security's Nicastro said software compensation providers are taking new approaches that give them a deeper understanding of how open-source packages are being used within applications. That, he said, could provide hope for preventing another Log4j, and it should at least help organizations to more quickly triage and remediate new vulnerabilities found in open-source packages.
"More organizations are adopting tools that allow them to have a more accurate [SBOM] so they can have an accurate inventory of what open-source packages are being used and where, so when there is another attack like Log4j, they can easily determine where the vulnerable package is for faster remediation.”
—Joe Nicastro
O'Reilly's Kaufmann added that since Log4Shell, organizations have become more aware of problems in their software supply chain, including the libraries they use. “Vulnerability scanning tools and processes have improved significantly, with organizations pushing them onto the CI/CD pipeline, catching issues earlier in the dev process,” she said. “As future Log4j-style problems are detected, they can be located and addressed faster than before.”
Many organizations today are still struggling to modernize their security tooling to match the scale and pace of DevSecOps software delivery, as well as the modern threat landscape. As important as it is to test early, doing it often and doing again at the end of the build is equally important for holistic visibility and management of application security (AppSec) risks.
Saša Zdjelar, chief trust officer for ReversingLabs, said that as organizations shift right by adding a final exam for any software in use in before deployment, they lose some visibility — but gain context as people add first-party and third-party commercial and open source code.
"What I think is missing in the SDLC of these producers, as well as on the consumer side, is the very, very last check of whether you are shipping a safe product when everything is built."
—Saša Zdjelar
Zdjelar said that a modern approach includes up-to-date tooling such as complex binary analysis and reproducible builds to expose tampering and other flaws that traditional AppSec tools miss. The Enduring Security Framework's most current recommendations specifically call out the need for using binary analysis as a sort of final exam before a completely assembled piece of software goes live.
