Security experts have warned that the Log4j vulnerability could still enable threat actors to launch attacks years from now, if security teams don’t up their game.
Forrester analyst, Allie Mellen, claimed the sheer scale and potential persistence of the threat was extremely worrying, and urged security teams to act now while awareness of the issue is high.
“Log4Shell will be exploited for years because of its ubiquity. There are over three billion devices running Java, many of which are using Log4j. Getting every single one of these systems patched is no small feat, and requires a massive awareness campaign and guidance to developers on how to address this vulnerability,” she told Infosecurity.
“As we’ve seen with many vulnerabilities like Heartbleed and Shellshock, some systems and applications just fail to get updated, leaving a hole that attackers can exploit far after the public frenzy has died down.”
A patch for the Apache logging product has been released, but although the vulnerability has a CVSS score of 10, many organizations might struggle to find instances running in their environment.
That’s in part because of the multiple layers of dependencies that exist in enterprise Java environments, in the form of Java archive (JAR) files. Any one of these may be hiding Log4j to help them log data.
BH Consulting founder and Infosecurity Europe Hall of Fame inductee, Brian Honan, agreed that the vulnerability “is likely to be with us for a long time.” He warned organizations to be prepared for a “long drawn-out process” of identifying vulnerable products, waiting for and applying patches, and putting mitigations in place.
“The issue is that many vendors may not know to what extent they are using Log4j, what version of it they are using, or indeed if it is included with their product, as the library may have been included as part of an overall addition and the vendor may not have intended to feature it. In addition, developers may have slightly altered the code in the Log4j library to suit their applications' particular requirements,” he told Infosecurity.
“All of the above makes it more difficult to determine if a product is vulnerable, as vendors will now have to review their code to determine how exposed they may be. If their products are exposed they will then have to develop a patch and ensure that is issued and applied by their customers.”
Current tooling may not be up to the task, warned Tanium area vice president, Chris Vaughan.
“One mistake that I’ve seen organizations make when going through this process of fixing the issue is that they are leaning too heavily on traditional vulnerability management tools,” he argued.
“These tools scan installed applications for any problems, but if a framework like Log4j has been renamed or installed in a non-default path then it’s likely that vulnerability management tools will miss them. For this reason, using a solution that analyses configuration strings within files is preferable.”
The US Cybersecurity and Infrastructure Security Agency (CISA) has published a new web page for vulnerability guidance and a community-sourced GitHub repository of publicly available information and vendor-supplied advisories about the incident. Both will be regularly updated, it said.
CISA director, Jen Easterly described the bug, also known as Log4Shell, as an “urgent challenge” and a “severe risk” for organizations. Federal agencies are mandated to patch or remediate it immediately and all enterprises are urged to do the same.