Researchers on Tuesday reported some eye-popping numbers on the Log4j remote code execution vulnerability that was first reported late last week.
Check Point Software Technologies found that 24 hours after the initial outbreak, its sensors recorded almost 200,000 attempted attacks across the globe. As of early this morning, when it posted its blog, some 72 hours after the initial outbreak, the number hit more than 800,000 attacks.
Staggering as this is, Matthew Prince, co-founder and CEO of Cloudflare, tweeted this in response to the Check Point numbers:
“Way more. We’re seeing >1,000 attempted exploits per second. And payloads getting scarier. Ransomware payloads started in force in last 24 hours.”
Other researchers are seeing a massive amount of activity in the dark web forums.
“There are exploits being passed around like crazy,” said Vinny Troia, chief executive officer of Night Lion Security. “The Check Point numbers don’t surprise me. This vulnerability has been a hot topic since the weekend and people have been writing scripts non-stop to scan and exploit servers on-the-fly.”
Troia added that he expects more ransomware cases throughout the holiday season. He said patching something as critical as this vulnerability won’t be easy, because it potentially requires a major update to a different version of Java, which means that an organization could have to spend a significant amount of money to re-write their own custom code to be compatible with this new version.
“It’s more likely that organizations will try to Band-Aid the problem by attempting to put firewalls and other blocking solutions in place,” Troia said. “This may be effective for a while, but the problem with that is priorities change. I suspect we will be seeing this bug being exploited for many years to come.”
John Hammond, senior security researcher at Huntress, added that because of its versatility and widespread usage, companies use Log4j in their own unique pieces of software. Hammond said that means an across-the-board patch isn’t likely. He explained that developers bundle Log4j in their own products, which means that each company has to rely on its vendors to come up with patches that will fully remedy the situation—and wait for them to push these updates downstream.
“This is an enormous issue — almost too big to comprehend or even chip away at a solution,” Hammond said. “Ultimately, everyone is affected by this in some way or another. There’s an extremely high chance, almost certain, that every person interacts with some software or technology that has this vulnerability tucked away somewhere. We have seen evidence of the vulnerability in Amazon, Tesla, Steam, even Twitter and LinkedIn. While developers might know that this Log4j package is used within their applications, end users do not, and it needs to be transparently explained what packages are used where and how.”
Jake Williams, co-founder and CTO at BreachQuest, said that at least immediately, security teams should not worry about new ransomware cases. Williams said most ransomware operations today involve lateral movement and privilege escalation to maximize impact.
“The Log4shell vulnerability is unlikely to provide a threat actor privileged access to any server they exploit, limiting the immediate impact,” Williams said. “However, access brokers are likely to deploy remote access tools to compromised servers that will be sold to ransomware threat actors later. While the activity we’re seeing now is high volume, it’s the tip of the iceberg when it comes to impact.”
During the initial phases of this vulnerability, it's important for security teams to focus on what they “do” know and “can” fix first, said Casey Ellis, founder and CTO at Bugcrowd. But larger organizations especially should operate on the assumption that they have unknown vulnerable Log4j in their environment and make plans to mitigate the risks.
“The two controls which can help reduce the risk posed by shadow Log4j are blocking known malicious Log4Shell attempts using WAFs and other similar filtering technology, and egress filtering of outbound connections at the firewall and internal DNS,” Ellis said. “Inbound filtering will deal with the noise and limit the ability of a casual attacker to land an exploit on an unknown Log4j instance, and egress filtering will limit the impact of data exfiltration (or retrieval of a second-stage payload) should an attacker succeed against a vulnerable instance.”
Andrew Howard, CEO at Kudleski Security, said the Log4j vulnerability highlights a tendency for developers to blindly use libraries without carefully considering all available options. He said a security-conscious developer would probably have disabled the JDNI query when reading the documentation if the software does not use this feature, thus reducing the attack surface.
"I recommend that organizations maintain a repository of libraries that are deemed secure as part of a secure DevOps process and as part of the fundamental security strategy of the company," Howard said. "The standard for all development processes then includes programmers continuously checking all libraries used in a software development project for acceptability against this repository."
