On 9 December 2021 the world learned of a remote code execution vulnerability in Apache’s Log4J solution, a Java-based logging system. Soon after, security pundits began predicting that the Log4Shell flaw, as it was dubbed, was possibly the worst security nightmare of all time.

The Log4Shell flaws are serious and easy to exploit. The US Cyber security & Infrastructure Security Agency (CISA) quickly issued an alert and directed all federal agencies to mitigate the vulnerabilities in short order. It has since maintained a frequently updated guide to mitigations.

Meanwhile, threat actors were not slow to take advantage. We’ve seen the flaws exploited in everything from nation-state campaigns to VMware Horizon servers being hijacked for crypto-mining and botnets.

Better than expected
But overall, did it live up to the hype?

“The attacks were not on the predicted scale,” says Brian Honan, CEO of BH Consulting. “Several factors accounted for this, the first being that many organisations reacted quickly to identify affected systems and apply the patches where appropriate.”

That speed was critical, explains Mark Guntrip, senior director of cyber security strategy at Menlo Security.

“The first attempt to exploit the vulnerability was detected nine minutes after it was publicised. Within 12 hours, 40,000 attempts were made – a figure that climbed to 830,000 in the next three days by the time a patch was released to the public,” Guntrip adds. “More concerning is that a proof of concept of an attack using the Log4J vulnerability was detected eight days earlier – evidence that the vulnerability was known and exploited well before it was made public.”

Another factor was the simplicity of both exploits and remediations. Other vulnerabilities that have had doomsayers predicting disaster – such as Meltdown, Spectre, or Poodle – have involved some tricky fixes. That wasn’t the case here.

“There was no need to change a protocol, it didn’t require thousands of endpoints to be patched, and while it’s a common logging library that is widely used, it concerned a very specific application,” explains Alon Schwartz, a cyber security researcher at LogPoint. “It was a simple fix.”

Much ado about nothing?
This raises questions about the validity – and usefulness – of the apocalyptic warnings. We’ve seen a few of these now, so is there a danger that they become seen as hyperbolic over-reactions by a self-interested security industry?

“There is risk that the constant ‘sky is falling’ messaging, particularly by security vendors who see it as an opportunity to sell more products or services, could result in people viewing those of us in the cyber security industry as the boy who cried wolf,” says Honan.

He believes that the industry needs to find better ways of communicating the true nature of the risks and what organisations need to do to tackle them.

“I don’t believe having heavily hyped vulnerabilities are a way to get through the inertia and lack of awareness that too many people and businesses have regarding cyber security,” he adds. To an extent, this has been achieved with ransomware, he says, because it’s easier to relate to business risk. “New vulnerabilities are much more theoretical.”

Teaching moment
What can we take away from the Log4Shell story? According to Schwartz, “it is a great example of how we as an industry can respond when we need to. The advisory information, communication and execution were so well orchestrated.” But, he warns: “The industry was lucky this time around. But Log4j is just one of many open source widely used libraries which are typically maintained by a handful of unpaid developers.”

Open source libraries are a particular problem because comparatively few organisations have good visibility into which ones they are using.

“This problem also extends to many vendors who incorporate third-party libraries and software into their products within properly tracking what those third party items are and how to ensure they are properly secured,” says Honan. “During Log4Shell, we witnessed many vendors scramble to review their products to determine if they did use Log4J in their software, if so what versions, and how to effectively patch their software as a result.”

Still a threat
The danger hasn’t gone away, either. Many organisations are still vulnerable.

“It’s clear that malicious actors have already compromised enterprise servers using the Log4J vulnerability and are laying low, probing the network, and waiting for an opportunity to spread to more high-value targets,” says Guntrip. “The industry will see a steady rise of breaches over the next several months. It’s just a matter of time before a high-profile breach takes place.”

Organisations need to take a good look at how they are readying themselves for the next onslaught. And the best way, says Schwartz, “is going to be through the use of a zero-trust approach and sound cyber hygiene. The complexity of open source software is significant, so organisations need to have a very high degree of resilience and assume they have been breached.”