In the week since the emergence of the Log4J security vulnerability, software vendors and end-user organisations have been scrambling to patch their systems, as attackers tested out exploits and launched hundreds and thousands of attacks. Here is what we’ve learned about how the Log4J vulnerability is being exploited, how the technology industry has responded, and how organisations must respond in the short and medium term.
Identifying and patching systems that incorporate Log4J will take weeks, if not months, experts warn. (Photo by nikkimeel/iStock)
How is the Log4J vulnerability being exploited?
Last Thursday, details emerged of a new vulnerability in Log4J, an open-source logging tool for the Java programming language. The news triggered alarm in the cybersecurity sector due to the ubiquity of Log4J and the ease with which the vulnerability can be exploited.
Even unsophisticated hackers can download tools to scan the internet for unpatched servers and use commands copied from online code repositories to exploit them, says David Warshavski, VP for enterprise security at Sygnia. “The latest tool that can scan the entire IP range of the internet and identify potentially vulnerable [servers] in less than a day.”
Exploits spread quickly. The first attempt to exploit the vulnerability was recorded nine minutes after it was publicised. After 12 hours, it had been used in 40,000 attempted cyberattacks, according to security software vendor CheckPoint. After 72 hours, there had been 830,000 attempted attacks.
Soon after the vulnerability was publicised, criminals were exchanging 'proof of concept' exploits on dark web message boards, says Chris Morgan, senior cyber threat intelligence analyst at Digital Shadows. Posters were "congratulating each other on what a great opportunity this will be for the foreseeable future," Morgan says.
Initial exploits were unsophisticated, Warshavski says, but were soon followed by cryptominers – malware that uses compromised servers to mine cryptocurrencies. Ironically, he says, this may have been beneficial, allowing companies to spot that they have been compromised without loss of data.
More malicious exploits have since emerged. Many of these exploit the Log4J vulnerability to extract information that can be used in future, more penetrating attacks. "The vast majority of payloads that we observe out there have to do with exfiltration of application configuration data," explains Warshavski.
Digital Shadows has seen evidence of initial access brokers, which compromise target organisations then sell access to cybercriminals to use in ransomware attacks, "jumping on" the Log4J vulnerability, Morgan says.
Security researchers have also observed state-backed attackers, who are typically more sophisticated than their criminal counterparts, exploiting the vulnerability. CheckPoint, for example, reported that an Iranian APT group known as 'Charming Kitten' had tried to use it to compromise targets in Israel.
On Tuesday, CDN provider Cloudflare reported that it had detected evidence of the exploit being tested eight days before it was publicly disclosed. "Since a very similar vector was identified in 2016, and the vulnerability has existed since 2013," Warshavski says, "it makes sense that more sophisticated, nation-state groups have been using this, maybe for years."
How the tech industry responded to the Log4J vulnerability
The Apache Foundation, which supports the Log4J open source project, issued the first patch for the vulnerability – named Log4J 2.15.0 – on the day it was publicised. On Tuesday, security researchers reported that the patch itself had a security vulnerability; Apache issued a new patch, version 2.16.0.
Organisations are urged to patch any instance of Log4J in their infrastructure as soon as possible. But the tool is so ubiquitous that it's difficult for organisations to know which systems incorporate it, says Warshavski.
This means they are largely dependent on software vendors to warn their customers about the need to patch their products, he adds, but the industry's response so far has been mixed. The list of software vendors with unpatched products includes IBM, VMware and Cisco, according to a report by Reuters.
Log4J: What happens next?
For large organisations, patching all instances of Log4J is likely to take weeks, if not months, due its ubiquity and the difficulty of identifying where it is used. "Companies are in it for the long haul," says Warshavski.
The most urgent task is to identify and patch external-facing systems, as these are at greatest risk of compromise. But internal systems will need to be patched too, Warshavski says, as they can be exploited by hackers that have infiltrated an organisation.
Morgan warns tech leaders against 'burning out' their security teams in the rush to patch Log4J. "This is going to be a marathon, not a sprint," he says. But, he adds, "these next few weeks will be critical in making sure you close those doors before they're opened."
Longer term, the Log4J vulnerability underscores the need for up-to-date approaches to cybersecurity risk management. These include keeping a registry of software assets so that a company's exposure to vulnerabilities can be quickly assessed, and Zero Trust security architectures, says Morgan.
Is open source software secure?
The Log4J vulnerability has reopened the debate over the security of open source software. Proponents argue that the transparency of open source projects means that vulnerabilities are more likely to be identified. "That's completely false," says Warshavski.
Projects such as Log4J, which are ubiquitous but maintained by a handful of unpaid volunteers, cannot possibly eliminate all vulnerabilities from their codebase, Warshavski argues. Furthermore, he claims, sophisticated hackers have been known to identify developers who write insecure code for open source projects and track down all their contributions to identify new vulnerabilities.
What's needed, Warshavski argues, is for organisations that use open source software to be held accountable for its security. "You want organisations to be able to audit the software they use and not rely on third parties," he says. "But that's not happening."
