Log4Shell Vulnerabilities Still Plague Organizations
Almost exactly one year after Log4Shell sent security teams scrambling to patch, more than seven in 10 (72%) of organizations are still vulnerable to the flaw.
These were among the results of a Tenable telemetry study examining the scope and impact of the critical Log4j vulnerability, known as Log4Shell, in the months following its initial disclosure.
Organizations are struggling to meet legacy vulnerability remediation challenges, and just 28% of organizations worldwide have fully remediated Log4Shell as of October 1, 2022, although this represents a 14-point improvement over May 2022.
However, the majority (53%) of organizations remained vulnerable to Log4j during the period of the study.
Log4j Persistence
This finding underscores the pervasive nature of Log4j and the necessary ongoing efforts to remediate even if full remediation was previously achieved, said Bob Huber, chief security officer for Tenable, who added there are a multitude of reasons why organizations remain vulnerable.
“The vulnerability is difficult to patch for whatever reason; it’s so pervasive that remediation takes a long time, and reintroduction is the most challenging aspect of remediation,” he said.
Even if an organization has fully remediated Log4Shell, Huber says they could inadvertently reintroduce the Log4Shell vulnerability anytime they add new systems or assets to their environments.
An April survey of 200 cloud security leaders published by Valtix found more than three-quarters of respondents were still working toward patching all the instances of Log4j for Java applications that were deployed.
Huber warned that if organizations didn’t address the issue on the left side – in the build pipeline – they would continue to deploy vulnerable code.
“As it stands, many organizations address the issue on the right side–in their runtime environment–only to be replaced with another insecure build,” he adds. “Identifying every instance of insecure code in use is nontrivial for most organizations, including third parties.”
He says all organizations, regardless of remediation status, can make immediate improvements by taking inventory of where the Log4j Java library exists in their environment and then assessing those assets for the Log4Shell vulnerability.
“Having an inventory not only streamlines the remediation process but gives security teams a list of assets to routinely check for reintroduction of Log4Shell and other vulnerabilities and weaknesses,” he explained.
The report also found some industries are in better shape than others, with engineering (45%), legal services (38%) and financial services (35%), leading the pack with the most organizations fully remediated, followed by non-profits and government agencies.
North American organizations lead the pack in having fully remediated Log4j (28%), followed by Europe, Middle East and Africa (27%), Asia-Pacific (25%) and Latin America (21%).
Huber explained some industries are better staffed than others, having a team dedicated to cybersecurity alone rather than an IT team who has many responsibilities, including cybersecurity.
Improving Overall Security Posture
“Security is a journey we are all on with a goal to improve our posture,” he said. “Many organizations still wrangle with foundational security controls.”
In addition, he points out that free/open source/third party-software monitoring and/or DevpSecOps is usually not one of the first areas to be addressed and is the sign of a more mature and better-resourced organization.
Concerningly, the report also revealed that as of October 2022, 29% of vulnerable assets saw the reintroduction of Log4Shell after full remediation was achieved.
“In my view, the most concerning issue is if Log4j remains largely unaddressed as one of the most significant vulnerabilities of my career, how do you think folks are managing the other critical vulnerabilities that come out every day?” Huber asked. “It’s not a good indicator.”
Matt Psencik, director, endpoint security at Tanium, said this vulnerability brought to light the age-old issue of “you can’t protect what you don’t know you have” seen more commonly in asset inventory and patching compliance.
“Log4J was an evolution to this issue and shined a spotlight on the harsh reality that it is not good enough to just know what operating system or applications are installed,” he said. “Instead, we need to understand the building blocks of shared libraries that comprise our applications and operating systems to find and remediate certain vulnerabilities.”
Psencik added that Log4J is not alone in the grand scheme of shared library exploits, but that it was catapulted to the headlines because of its ability to perform what’s called a remote code execution (RCE) vulnerability.
RCE allows for code to be executed remotely; possibly without needing to authenticate with an application.
“Log4J illustrated how finding a vulnerability in open source software can provide footholds in not just one application but often a large majority of the applications used by some of the largest corporations today,” he said. “I expect shared library and software exploits like this will only become more common.”
Rather than calling out or punishing responsible security researchers for finding additional exploits like Log4J in open source software, Psencik said security pros should encourage research and support the groups that make these shared libraries as they commonly work for free and are fueled by a passion for making great software.
“Funding an open source software developer allows them to devote more time and resources to developing stronger and more secure libraries which benefits the larger community,” he says.
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 and made it clear that the vulnerabilities are not going away anytime soon.
