Enterprises are seeing 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 December 9, allows an attacker to take control of a server simply by sending a particular string of code through an affected application.

Since then, security researchers report a massive wave of attacks.

Check Point alone, for example, reported preventing 1.3 million attempts as of December 14, compared to 44% of all global networks.

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

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

According to Mellen, Java is used on more than 3 billion devices, and many of them use Log4j.

“This vulnerability will be used for months, if not years, to attack businesses,” she added.

“It wouldn’t be an exaggeration 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 of cybersecurity vendor Sonatype, the vulnerable version of Log4j has been downloaded 29 million times in the past four months and is also a component of nearly 7,000 other open source projects.

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

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

Cybersecurity vendor Wiz discovered that over 89% of all environments have vulnerable Log4j libraries.

“And in many of them, the development teams are sure they have no exposure – and are surprised to find that some third-party components are actually built using Java,” said the founder and technical director of Wiz, Ami Luttwak.

Wiz is the $6 billion cloud security startup that discovered the Microsoft Cosmos DB vulnerability earlier this year. The company said its usage just doubled thanks to Log4j.

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

Worse still, many applications that use this library are not actively maintained and patches may not be immediately available.

“There’s no good network mitigation to protect against this attack,” said Chris Wysopal, CTO and co-founder of CA Veracode, a cybersecurity vendor. “The way data is interpreted by Log4j is that it has a nested parser. You can embed items within items within items and nest strings. The only way to really fix this vulnerability is to update the library used by the application.”

Even if a particular application is not using Log4j, the surrounding infrastructure could, he said, including the application server, message queue server, database server, or network devices.

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

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

“Because logging is flexible by design, this vulnerability has an almost infinite number of potential avenues for exploitation,” he said.

Even cybersecurity applications can be sensitive – 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 from Cisco, IBM, VMware and many other enterprise technology vendors.

Vendors are all racing against time to correct or tone down their products.

“This vulnerability poses a serious risk,” Jen Easterly, director of the Cybersecurity and Infrastructure Security Agency, said in a statement released Saturday.

CISA recommends that enterprises identify all external devices on which Log4j is installed, ensure that the Security Operations Center acts on every alert received from these devices, and install a web application firewall with the appropriate rules.

The agency also released a vulnerability guide to help vendors and businesses respond to the threat.

It didn’t help that the vulnerability was publicly disclosed right after it was discovered. Normally, the vulnerability would be disclosed in advance to affected vendors, so they have the opportunity to patch critical systems before attackers learn about it. There is usually still a loophole where some companies are slow to fix and attackers take advantage of it. But this time around, the shortcomings are universal: every vendor is now scrambling to deploy a fix while attackers are having a blast.

Data Center Impact

“Data center managers should be aware that their servers are almost certainly under attack today,” said Jeff Williams, CTO and co-founder of Contrast Security. “Attackers target just about anything 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 of Randori, a cybersecurity company.

“Data center managers should be aware that Log4j is likely used in many of their business applications,” he told Data Center Knowledge.

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

“Limiting outbound connections can reduce the risk of a vulnerability like Log4j affecting your systems in the future,” he said. “Randori customers who took this action were not disproportionately affected by Log4j CVE despite the presence of vulnerable applications in their systems.”

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

“For example, a web server can be patched, but every system that handles user data from it will also need to be patched,” he told Data Center Knowledge. “Otherwise, the exploit could occur further down the workflow in a processing application.”

Donald E. Patel