Spring4Shell Vulnerability: Should You Patch?

We’re excited to bring Transform 2022 back in person on July 19 and virtually July 20 – August 3. Join AI and data leaders for insightful conversations and exciting networking opportunities. Learn more about Transform 2022

The remote code execution (RCE) vulnerability in Spring Core, known as Spring4Shell, is not an “everything is on fire” issue, according to Dallas Kaman, one of the security engineers who first posted confirmation of the vulnerability after it was released. was leaked this week. † But patching will still be the wisest course of action for many organizations, said Kaman, chief security engineer at Praetorian, as much is still unknown about the potential risks of the open source vulnerability.

In particular, there’s a good chance that attackers will find new ways to exploit the vulnerability, says Praetorian CTO Richard Ford. This suggests that anyone using Spring, a popular framework for developing Java applications, should consider deploying the patch — not just those who know they’re vulnerable, Ford said.

Free Wortley, founder and CEO of LunaSec, which also published an analysis on Spring4Shell, reiterated that this issue is a major concern regarding the vulnerability.

“Several companies have approached me asking if their particular configuration is vulnerable, and my advice is to patch anyway,” Wortley said in an email to VentureBeat. †[It’s] not the same priority as Log4Shell – but they still need patching as attackers will find new ways to activate it. Spring is just too ubiquitous to ignore.”

A number of security experts have pointed out the differences between Spring4Shell and Log4Shell – a much more critical but eponymous RCE vulnerability – indicating that this new RCE vulnerability is not the “next Log4Shell” as some had initially feared.

At the same time, according to reports from Kasada, Spring4Shell is in fact actively targeting attacks. GreyNoise Intelligence and Bad packages† And researchers suspect that real-world applications are likely to be vulnerable (although no reports confirming this are yet to emerge).

Other exploits possible

On Thursday, Spring published a blog post detailing patches, exploit requirements, and suggested fixes for Spring4Shell (CVE-2022-22965). The RCE vulnerability affects JDK 9 or later, and it is currently known that there are several additional requirements in order for it to be exploitable, according to the Spring blog post.

The initial exploit requires the application to run on Apache Tomcat as a WAR implementation, which is not the standard way to deploy applications – somewhat limiting the magnitude of the vulnerability’s impact. The default, on the other hand, is not vulnerable to Spring4Shell’s initial exploit.

“However, the nature of the vulnerability is more general and there could be other ways to exploit it,” Spring said in his blog post.

New versions of Apache Tomcat were released Friday that address the attack vector involved in the vulnerability.

At this early stage, much is still unknown about the potential exploitability of Spring4Shell. For example, in addition to Tomcat, there are other servlet containers that development teams use with Spring Core, such as Jetty.

And while Tomcat offers certain features that are used as part of exploiting the vulnerability, and is the most widely used Java servlet container, alternatives to Tomcat may provide features for this, the Praetorian researchers said.

“I can imagine people looking at the other servlet containers over the next few weeks to see if there are any components out there that make this kind of thing possible,” Kaman said.

In layman’s terms, to take advantage of the vulnerability in Spring Core, “you need a hammer, a nail and 2×4. Tomcat provides the hammer, nail and 2×4,” said Ford. “For other systems [besides Tomcat], people will say, ‘Well, maybe I don’t need a hammer — can I get away with a screwdriver?’ It’s essentially using those gadgets that are in the environment to do your job.”

In other words, because Spring4Shell is a “more general vulnerability” — as Spring points out in his blog — the best advice is “you should patch,” Ford said. “Because there may be more common exploits available.”

Who should patch?

That advice applies to anyone using vulnerable versions of Spring, he said. — not just those using the configuration known to be vulnerable (Spring with Tomcat).

“If you’re using Tomcat and a vulnerable version of Spring, you pretty much have a problem and should patch now,” Ford said. “But the underlying vulnerability is in Spring Core, whether Tomcat is there or not. And so the recommendation is that if you’re using Spring Core, you should look into patching to the latest version.”

LunaSec recommends the same approach to organizations because the reality is that when it comes to Spring4Shell, “this is still very new,” Wortley said.

“We haven’t had time to analyze the different ways this can be triggered and turned into an RCE exploit,” Wortley said.

However, from past lessons with other Java vulnerabilities — such as Log4Shell, which affected Apache Log4j logging software — the security community knows that “demonstrating a single bypass usually means there are more,” he said.

“There are a lot of very smart, highly motivated attackers right now trying to find other ways to trigger this exploit,” Wortley said. “The ways this exploit can be exploited are very broad and not something that can be fully understood in a short amount of time.”

In addition, code and infrastructure aren’t static, he noted — meaning that just because an organization doesn’t consider itself vulnerable today doesn’t mean it will stay that way.

So if an organization assesses Spring4Shell’s risk and concludes that “‘we don’t use X, so we’re good'” — that “could be a dangerous mindset,” Wortley said.

Patch now or wait?

If you’re not using a vulnerable configuration and have to wait a few weeks to patch, that’s probably fine, he noted.

“But the longer you wait, the more likely you are to forget this — and either an attacker comes up with a new bypass, or one of the parts of your infrastructure changes and now you’re vulnerable,” Wortley said. †

Ultimately, attackers prey on the fact that many companies are unable to patch quickly and will therefore be vulnerable for a long time to come, he said.

The Apache Struts RCE (CVE-2017-5638) that led to the Equifax breach in 2017 was the result of waiting for a patch from the financial services firm, Wortley said. In that case, it took about two months for the exploit to be weaponized and used on them, he said.

That example reminds us “how important it is to patch juicy vulnerabilities like Spring4Shell faster than other, smaller vulnerabilities,” Wortley said.

Whatever happens with future exploits of Spring4Shell, however, researchers see no chance of the vulnerability turning into a replication of Log4Shell.

Even with the worst-case scenario for Spring4Shell, it’s “very unlikely we’ll end up in a similar situation” like Log4Shell, Ford said. But at the same time, “it’s a big deal for affected customers,” he said.

VentureBeat’s mission is to be a digital city square for tech decision makers to learn about transformative business technology and transactions. Learn more about membership.

This post Spring4Shell Vulnerability: Should You Patch?

was original published at “https://venturebeat.com/2022/04/01/spring4shell-vulnerability-should-you-patch/”