Is there a risk of a worm exploiting the Log4j flaw?

In the opinion of VMware’s head of cybersecurity strategy Tom Kellermann, the possibility of exploiting the Log4j vulnerability using a worm is the worst-case scenario for cybersecurity this early in the year. “One of the most important [worms] of the early 2000s was Code Red,” Kellermann told ZDNet . “We haven’t seen a widespread global impact like that since then.”

The possibility of a worm has generated significant conversation in the cybersecurity community.  In the opinion of cybersecurity expert Marcus Hutchins such fears are exaggerated because “a worm would need a new exploitation technique to get any real value out of the vulnerability. Firstly, mass exploitation already exists (you can spread the entire Internet from one server). Secondly, worms take time and skill to develop, but most attackers are racing against the clock (patching and other attackers),” Hutchins wrote on Twitter. 

BreachQuest CTO Jake Williams, meanwhile, believes that while someone could create a worm that exploits Log4Shell, it is unlikely to be like WannaCry, NotPetya, or previous worms that exploit system-level processes.

Attacks based on the Log4j flaw continue, and cybersecurity experts warn there is no end in sight. Recent evidence suggests that attackers are trying to exploit the vulnerability to expose the keys used by Amazon Web Service accounts. There are also signs of attackers trying to exploit the vulnerability to install remote access tools on victims’ networks, possibly Cobalt Strike, a key tool in many ransomware attacks.

There are hundreds of software and networking products that remain vulnerable, and not all of them have patches or workarounds yet. “We have not seen a significant reduction in exploit attempts since the peak on December 1, and these probes and exploits are coming from a globally distributed infrastructure,” said Sophos’ Sean Gallagher. On Tuesday, December 21, the company revealed that most attacks have been coming from China and Russia. Just one domain, associated with a Russian cryptocurrency mining organization, was responsible for 11% of the attacks recorded so far. There is still an extraordinarily large attack surface available and experts worry about how long it will take organizations to respond to the biggest cybersecurity problem in years.

DevSecOps professionals wonder if this is finally the long-awaited watershed moment in cybersecurity. Maybe. After all, this whole cyber security panic is close to becoming an annual tradition. Last December, reports began to emerge about another massive security crisis with the SolarWinds breach, which remains an attack vector. Before that, in January 2018, another far-reaching cybersecurity problem grabbed the headlines with the Meltdown and Spectre vulnerabilities.

But so far, what we have seen is companies struggling to understand the urgency of DevSecOps.

To make matters worse, some companies – including some large IT software vendors – are still investigating whether the vulnerable version of the library exists in their products. A movie we’ve seen before. A detailed post-mortem report on the Equifax data breach in 2017 pointed to a similar scenario to now, where the credit bureau’s IT teams searched their systems for another Java vulnerability and failed to find it before the attackers did.

And it’s not just IT products and service providers that need to worry. The FDA has warned there is “widespread and active exploitation” of the Log4j vulnerability across multiple industries but said it is not aware of any confirmed adverse events affecting medical devices. “Manufacturers should assess whether they are affected by the vulnerability, assess the risk, and develop remediation actions,” the FDA said. “As this is an ongoing and evolving problem, we also recommend ongoing surveillance and response to ensure that medical devices are adequately protected.” The challenge now is for hospitals and device manufacturers struggling to assess the impact of the Log4j vulnerability on their respective device inventories. 

To assist vendor and user security teams, the US Cybersecurity and Infrastructure Agency has released an open-source scanning tool to help companies and agencies find Log4j instances on their systems. And the Apache Software Foundation has been relentless in its search for solutions. The Log4j 2.17.0 update is the third since Log4Shell was leaked and mass exploitation began. Versions 2.15.0 and 2.16.0 fixed remote code execution bugs. It fixes a new vulnerability reported last week that allows denial-of-service attacks against vulnerable instances of the Java logging framework.

The best answer is perfectly clear: fix or mitigate your own systems now.