Infosec experts say the critical Log4j vulnerability disclosed last week is one of the worst vulnerabilities seen in recent -- and perhaps distant -- memory for multiple reasons, including the ubiquity of Log4j and the ease of exploitation.
CVE-2021-44228 is a vulnerability impacting Log4j 2, the second version of a popular Java logging framework developed by the Apache Software Foundation and used in a large number of products, cloud services and applications across both large and small organizations. The flaw, commonly referred to as "Log4Shell," allows threat actors to remotely execute malicious code against organizations who have certain configurations enabled -- configurations that are standard in older Log4j 2 versions.
Apache had a new update (Log4j 2.15.0) available when the vulnerability was publicly disclosed that fixed the configuration issue, and the foundation released guidance for organizations who haven't updated to mitigate the issue.
Unfortunately, as is often the case, the problems don't stop when a patch is released. Large-scale exploitation was reported in the hours and days following the release of a proof-of-concept exploit that was dropped last Thursday. By the weekend, security vendors reported that the vulnerability was being exploited as early as Dec. 1 -- a full week before most knew about it.
Cloudflare CSO Joe Sullivan told SearchSecurity that the company was blocking "it seems like over a million attempted exploits an hour at this point." On Tuesday, Cloudflare CEO Matthew Prince tweeted that the company was seeing 400 confirmed exploit attempts per second.
"I think that this vulnerability is going to be looked back in the future as one of the most significant vulnerabilities we've ever had to deal with," Sullivan said.
Similarly, Jen Easterly, director of the Cybersecurity and Infrastructure Security Agency, said in a statement that the flaw poses a "severe risk."
Log4Shell has a CVSS score of 10, the highest possible. The reason it's so severe, according to experts, is multifold.
For one, the number of servers and devices utilizing Java in some capacity is comfortably in the billions. It's in video games like Minecraft, services like Apple iCloud and countless SaaS products. As such, it reaches across enterprises, SMBs and consumer devices.
"This vulnerability is so dangerous because of its massive scale; millions of applications use Log4j," Forrester security and risk analyst Allie Mellen told SearchSecurity. "Applications on the internet are a complex system of interconnectedness, which makes it difficult to know what applications might be affected, even your own. Even if your software doesn't use Log4j directly, you may use someone else's software that does, and you may not know it."
The second reason is, as Sullivan explained, that the flaw is not easy to patch.
"Not everybody knows where the vulnerability is running in their environment. It could be running in code that your team put together, and it could be running in in code from a vendor that you licensed their software," Sullivan said. "We've been recommending to our customers to try and block with a WAF, but you still have to go in and disable or patch the vulnerable software in every context. This software can be running in a lot of different contexts outside of just front-end websites. So there's a real challenge in terms of identifying all the places where the software is running, and a real challenge in terms of being able to patch it quickly."
He added that since Log4j 2 versions have been releasing since 2014, "the engineers who deployed it might not be at the company anymore."
While the largest enterprises will hopefully patch Log4Shell quickly, the capacity of organizations below that size to stay on top of patching can vary greatly. Moreover, some industries, like those dealing with industrial control systems (ICS) and operational technology (OT), can have further unique challenges.
"ICS and OT environments have significantly greater challenges when it comes to vulnerabilities, as their patch and update cycles can be measured in years instead of days or hours," Dragos vice president of threat intelligence Sergio Caltagirone told SearchSecurity. "Additionally, in many cases an ICS asset owner may not control their software but instead leave it to an external integrator to manage their operational software, which means they're reliant on another company to fix this problem, potentially leaving them vulnerable for longer, or able to accurately assess their risk and exposure."
The third reason, and perhaps the most dangerous, is that Log4Shell is easy to exploit. All a threat actor needs to do is add a string of malicious code into the log files of a vulnerable server to gain remote code execution capabilities.
As a Tuesday FAQ from Check Point Research about Log4Shell explained, "anyone can make a Log4Shell exploit."
"A six-year-old can craft one of these strings herself," the post read. "She can then submit it to a targeted server as part of a username, a password, a phone number, a TCP packet, any sort of input the server processes. If the Java on the victim end logs this input using a vulnerable instance of Log4j2, the attack succeeds."
Mellen said the current activity surrounding Log4Shell represents only "the tip of the iceberg."
"This vulnerability will be used for months, if not years, to attack enterprises, which is why security teams must strike while the iron is hot. So far, we have seen this vulnerability exploited by attackers looking to deploy cryptominers or set up botnets," she said. "This is just the tip of the iceberg, and you can be sure attackers are building more complex attack chains to exploit this vulnerability further with attacks like ransomware and information stealers."
Alexander Culafi is a writer, journalist and podcaster based in Boston.