Enterprises See Exponential Growth in log4jshell Attacks

The Apache Log4j library is a Java-based logging tool that is ubiquitous in enterprise applications. The vulnerability known as Log4Shell, first reported on Dec. 9, allows an attacker to take over a server just by sending a particular code string via an affected application.

Since then, security researchers are reporting a massive wave of attacks.

Check Point alone, for example, reported that it prevented 1.3 million attempts as of Dec. 14, against 44% of all global networks.

And the number of attacks is climbing exponentially, as hackers rush to exploit the vulnerability to steal data, deploy ransomware, install back doors, create botnets, mine cryptocurrencies, and conduct other illegal activities.

“This vulnerability is so dangerous because of its massive scale," said Allie Mellen, analyst at Forrester Research.

According to Mellen, Java is used on over 3 billion devices, and a large number of those use Log4j.

"This vulnerability will be used for months -- if not years -- to attack enterprises," she added.

"It wouldn't be a stretch to say that every enterprise organization uses Java," said Dor Dali, director of information security at Vulcan Cyber. "And Log4j is one of the most popular logging platforms for Java. Connecting the dots, the impact of this vulnerability has the potential to be substantial."

According to Brian Fox, CTO at cybersecurity vendor Sonatype, the vulnerable version of Log4j was downloaded 29 million times in the last four months, and is also a component in almost 7,000 other open source projects.

"It’s even a building block in the Ingenuity helicopter aboard the Mars rover," he told Data Center Knowledge.

According to Sonatype data, the new, patched version of Log4j has been available as of this Monday — but 65% of all current downloads are still for the old, vulnerable version.

Cybersecurity vendor Wiz has found that more than 89% of all environments have vulnerable Log4j libraries.

"And in many of them, the dev teams are sure they have zero exposure — and are surprised to find out that some third-party component is actually built using Java," said Wiz fo-founder and CTO Ami Luttwak.

Wiz is the $6 billion cloud security startup that found the Microsoft Cosmos DB vulnerability earlier this year. The company said that its usage just doubled as a result of Log4j.

"The attack surface for threat actors is enormous," said Etay Maor, cybersecurity professor at Boston College and senior director of security strategy at Cato.

Worse yet, many of the applications that use this library are not actively maintained and patches might not be immediately available.

"There is no good network mitigation to protect against this attack," said Chris Wysopal, CTO and cofounder at CA Veracode, a cybersecurity vendor. "The way that the data is interpreted by Log4j is that it has a nested parser. You can embed elements within elements within elements and nest strings. The only way to truly fix this vulnerability is to update the library that the application uses."

Even if a particular application doesn't use Log4j, the surrounding infrastructure might, he said, including the application server, message queue server, database server, or network devices.

There's a good reason that Log4Shell, officially known as CVE-2021-44228, is rated 10 out 10 for severity.

The vulnerability allows attackers to execute malicious software by causing Log4j to write a specially-crafted log entry, explained Casey Ellis, CEO at Bugcrowd, a cybersecurity company.

"Because logging is flexible by design, this vulnerability has a nearly infinite number of potential paths to exploitation," he said.

Even cybersecurity applications may be susceptible -- vulnerable Log4j code has been found in products from CyberArk, ForgeRock, Okta, Ping Identity, Fortinet, SonicWall, and Sophos, among many others. The code has also been found in products form Cisco, IBM, VMware, and many other enterprise technology vendors.

The vendors are all racing against time to patch or mitigate their products.

"This vulnerability poses a severe risk," said Cybersecurity and Infrastructure Security Agency director Jen Easterly in a statement released Saturday.

CISA recommends that enterprises identify any external-facing devices that have Log4j installed, make sure the security operations center is acting on every alert received from those devices, and install a web application firewall with appropriate rules.

The agency also released a vulnerability guidance to help vendors and enterprises respond to the threat.

It didn't help that the vulnerability was disclosed publicly right after it was discovered. Normally, the vulnerability would be disclosed ahead of time to affected vendors, so they would have an opportunity to patch critical systems before attackers learn about it. There's usually still a gap where some enterprises are slow to patch and attackers take advantage. But this time, the gaps are universal -- every vendor is now scrambling to roll out a fix while attackers have a field day.

Data center impact

"Data center managers should know that their servers are almost certainly under attack today," said Jeff Williams, CTO and cofounder at Contrast Security. "Attackers are targeting just about everything with attempts to exploit this vulnerability."

Log4j is commonly used in VMware products, as well as Jamf Pro and many other applications, said David Wolpoff, CTO and co-founder at Randori, a cybersecurity company.

"Data center managers need to know that Log4j is likely used in many of their management applications," he told Data Center Knowledge.

He recommends that data centers enable default-deny on as many critical external-facing applications as possible.

"Limiting outbound connections can reduce the risk of a vulnerability like Log4j impacting your systems in the future," he said. "Randori customers who have taken this action were disproportionately unaffected by the Log4j CVE despite having vulnerable applications in their systems."

But it's not just applications on the perimeter that are potentially vulnerable, said Michael Clark, director of threat research at Sysdig.

"For example, a web server may be patched, but every system that handles user data from it will need to be patched as well," he told Data Center Knowledge. "Otherwise, the exploit could occur further down the workflow in a processing app."