.shock - stock.adobe.com
The so-called Log4Shell vulnerability in the Apache Log4j2 Java-based logging library has been described variously as “probably the most critical vulnerability we have seen this year” by Qualys’s Bharat Jogi, “a design failure of catastrophic proportions” by F-Secure’s Erka Koivunen and “a flashbulb memory in the timeline of significant vulnerabilities” by Sonatype’s Brian Fox.
In fact, as the implications of this newly disclosed vulnerability begin to become clear, you’d be hard pressed to find a security expert who wasn’t extremely worried by it. And to follow on social media over the weekend of 11 and 12 December 2021, as the security community wrestled with the implications of Log4Shell, you could be forgiven for thinking that the sky had fallen in already.
So what do defenders need to know? Unfortunately, in this instance melodrama is something of an understatement; the community’s reaction is to some extent entirely justified.
The zero-day, which is tracked as CVE-2021-44228, was made public at the end of last week, although it now appears that it was being exploited for some time prior. First discovered in Minecraft, it is a remote code execution (RCE) vulnerability that if left unmitigated, enables a malicious actor to execute arbitrary Java code to take control of a target server. It is considered almost laughably easy to exploit.
The fact Log4Shell is so uniquely dangerous is ultimately a function of how ubiquitous the Log4j2 tool is; essentially it is pretty much everywhere, and this means it puts multiple services, including those of tech giants such as Apple, Amazon, Cisco, Microsoft, VMware and a long list of others at risk of compromise, along with essentially any services using Apache Struts2, Apache Solr, Apache Druid or Apache Flink in some capacity.
Indeed, said F-Secure’s Jason Sattler: “Finding an app that doesn’t use Log4J library may be harder than finding one that does.”
“This is a worst-case scenario,” said Bugcrowd chief technology officer Casey Ellis. “The combination of Log4j’s ubiquitous use in software and platforms, the many, many paths available to exploit the vulnerability, the dependencies that will make patching this vulnerability without breaking other things difficult, and the fact that the exploit itself fits into a tweet... It was a long weekend for a lot of people.”
Scanning under way, more to follow
As with any newly disclosed zero-day, the vast majority of activity around Log4Shell to date has been scanning for vulnerable systems, according to Microsoft’s Threat Intelligence Center (MSTIC) team, which was among those putting in overtime at the weekend.
However, they added, they are also now observing full exploitation and post-exploitation activity, and based on the nature of the vulnerability, this activity can take a multitude of forms, from the deployment of simple illicit cryptominers, to the use of everyone’s favourite Cobalt Strike to enable credential theft and lateral movement, and data exfiltration. It goes without saying that ransomware attacks will follow.
As a matter of course, security teams must immediately apply the software update already released by Apache in Log4j2. But beyond that, Log4Shell presents a substantially different kind of challenge for security teams, according to Sophos senior threat researcher Sean Gallagher. “Many software vulnerabilities are limited to a specific product or platform, such as the ProxyLogon and ProxyShell vulnerabilities in Microsoft Exchange,” he said. “Once defenders know what software is vulnerable, they can check for and patch it.
“However, Log4Shell is a library that is used by many products. It can therefore be present in the darkest corners of an organisation’s infrastructure, for example, any software developed in-house. Finding all systems that are vulnerable because of Log4Shell should be a priority for IT security.
“Sophos expects the speed with which attackers are harnessing and using the vulnerability will only intensify and diversify over the coming days and weeks,” he said.
“Once an attacker has secured access to a network, any infection can follow. IT security teams need to do a thorough review of activity on the network to spot and remove any traces of intruders, even if it just looks like nuisance commodity malware.”
Defenders with systems that cannot be updated immediately can also apply a newly released fix developed by Cybereason, which can be downloaded from GitHub and requires only basic Java skills to implement.
Ellis at Bugcrowd said the Cybereason vaccine was a great option of last resort. “Many organisations are currently struggling to inventory where Log4j2 exists in their environment and updating a component like this necessitates a dependency analysis in order to avoid breaking a system in the pursuit of fixing a vulnerability.
“All of this adds up to a lot of work, and having a ‘fire and forget’ tool to clean up anything that may have been missed at the end of it all seems like a scenario that many organisations will find themselves in in the coming weeks.
“Another scenario in which it could be useful is rapid emergency prevention, such as if a self-propagating piece of malware like WannaCry appears before patching is completed,” he added.