- Mastering Azure management: A comparative analysis of leading cloud platforms
- Sweat the small stuff: Data protection in the age of AI
- GAO report says DHS, other agencies need to up their game in AI risk assessment
- This LG Bluetooth speaker impressed me with a design feature I've yet to see on competitors
- Amazon's AI Shopping Guides helps you research less and shop more. Here's how it works
Experts: Log4j Bug Could Be Exploited for “Years”
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.
“This vulnerability is so dangerous because of its massive scale. Java is used on over three billion devices, and a large number of those use Log4j, which is where the vulnerability lies,” she added.
“It will be used for months if not years to attack enterprises, which is why security teams must strike while the iron is hot.”
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.