As security practitioners turn their attention to the Log4j vulnerability, researchers warn remediation will be a marathon, not a sprint.

"Even though this vulnerability, and a lot of others, now may seem obvious, for a single developer that worked on that code it is usually quite difficult to spot a vulnerability," said Bojan Zdrnja, certified instructor at SANS Institute and chief technical officer of INFIGO IS. 

Exploitation of Log4j is relatively limited to cryptominers, CISA said, which suggests attacks thus far have been made by opportunistic hackers as opposed to sophisticated ones. However, the rub for Log4j is its expansiveness: Anyone who wants the chance to exploit devices has the ability to do so a million times over. 

"On one hand, Log4j is the most common logging facility for any Java application out there," Yaniv Balmas, VP of security research at Salt Security, said in an email. But exploitation of Log4j does not require a user to have technical knowledge, and those two factors combined is why "it's a super-explosive issue." 

This is why Log4j will be an ongoing threat. Industry is still investigating the full extent of the vulnerability, which limits the actions security teams can immediately take. Because companies need to locate where the vulnerability is in their networks first, it will slow patch deployment.

With different Java applications in one server, with copies of Log4j in another, a company could be susceptible to full remote code execution. "Any organization that doesn't know if they're impacted is already behind the bell curve," said Davis McCarthy, principal security researcher at Valtix. 

Remediating the Log4j vulnerability is dependent on several factors, according to Chris Morgan, senior cyberthreat intelligence analyst at Digital Shadows, including: 

• How mission-critical an application is to a business, complicating the patching process
• The availability of a backup while updates are processing
• The efficiency of a security teams responsible for vulnerability management

Vulnerability rundown

Log4j is just the latest vulnerability to cause mass concern, and it is not only an issue for internet-facing servers. Any time a patch requires taking down a server will cause delays, prolonging the time the vulnerability remains exploitable, said Sergio Caltagirone, VP of threat intelligence at Dragos. 

The vulnerable versions of Log4j are 2.0 to 2.14 . Version 1 is not vulnerable (though it does feature another vulnerability which is likely less critical), and the author of the library confirmed "that they treat strings as strings," preventing Java from "executing any objects there," Zdrnja said during a SANS Institute webcast Monday. "This actually saved a lot of applications."  

Companies that issued the patch 2.15.0, which was released Dec. 9, will likely need to update again using 2.16.0. 

"It's big, bad and ugly, you'll need to check all your servers and your computers across your whole network, all operating systems or processes," said Paul Ducklin, principal research engineer at Sophos, during a webcast Wednesday.

Open source code is embedded in applications and services across vendor-provided products or ones made in house. Mapping services can be a weeks-long task, according to Balmas, and then patching can begin. For external services, companies are at the mercy of their vendor providing an update. 

"It's not as simple as doing a search for all files named 'Log4j.' Most organizations are looking at source code, but that's not foolproof," said McCarthy. For vendor applications, or legacy products, "there may not be source code to even look through." 

Theoretically, a business is only vulnerable if it is definitely deploying an application with Log4j in its network. However, to make that assumption is like asking, "did I fire six shots or only five?" said Ducklin. 

If there is no Log4j in a business' network, the vulnerability is not a threat — but that requires a high level of confidence and asset management.  

In the interim, companies with mature security programs will likely stand up controls to block known indicators of compromise, or automate exploitation attempts, according to McCarthy. Caltagirone agreed, "regardless of which vulnerabilities are used by an adversary, a defender should be able to see them after the exploit moves through their environment." 

Major vulnerabilities, a history

Log4j isn't the first vulnerability to cause immediate remediation efforts, and security professionals each have a different sense of which vulnerabilities live on past the date of their available patches.

Shellshock, for example, "theoretically existed for almost 25 years before it was published," said Zdrnja. And a 2008 vulnerability, MS08-067, caused issues for more than a decade, according to Caltagirone. 

Patching for Heartbleed, found in OpenSSL, depended on the vendor. "The 'oh crap' moment is realizing you have to depend on someone else for your security," McCarthy said. 

Balmas and McCarthy referenced the EternalBlue vulnerability, which led to the worldwide WannaCry ransomware attack. "I'm afraid that the magnitude of Log4Shell-related exploits is much bigger than EternalBlue. If WannaCry was something that caught the entire industry by surprise, it’s hard to imagine what’s waiting for us with Log4Shell," said Balmas. 

In 2017, the Apache Struts RCE vulnerability was exploited just as quickly upon its disclosure, which later was used in the Equifax breach, said Morgan. The breach infamously took place months after a patch became available, though Log4j is considered a more severe vulnerability considering the number of devices at risk. 

"This is what we're most concerned about — the pace of these 'world breaking' vulnerabilities is increasing," and critical industries with underfunding are the most susceptible to disruption, said Caltagirone.