Let’s All Calm Down About Spring4Shell

What Happened?

On March 30, 2022 rumors began to circulate that a remote code execution (RCE) vulnerability was discovered in Spring Core, the most widely-used lightweight open source Java framework. These rumors began because a Chinese researcher published what appeared to be proof-of-concept (POC) exploit code on GitHub, and then quickly deleted it.

Confirmed! https://t.co/olfK9dEr30

— Janggggg (@testanull) March 30, 2022

However, what we now know is that there is no actual broad threat to environments, and that the virality of the internet is perhaps too much for anyone at this point. This is a perfect example of potential blue team exhaustion and what can come from chasing unconfirmed potential threats. Information develops quickly and acting quickly is important at times, but having the full picture of risk is the most important first step.

The continuous stream of zero days and ongoing issues has pushed the information security community and its related media into a continuous feeding frenzy which a now-deleted researcher on Twitter took advantage of. There is currently no new risk to Spring Core and the only known vulnerability associated with the CVE is for Spring Cloud Functions.

Around the same time as the RCE rumor, Spring Core changed how they handled deserialization, but it was not to prevent an RCE. Rather, it was to clarify that using certain deserialization methods from untrusted sources is not secure. 

CVE-2022-22963 is for Spring Cloud Functions, the serverless function components. An adversary could potentially leverage this vulnerability to remotely execute code on an application that was developed using Spring and runs a vulnerable version of Java Development Kit (JDK), according to the write-up on Spring Cloud’s website.

The vulnerability affects version JDK9 of the Spring framework and above.

Update (3/31/22 at 11:30 AM ET): Shortly after this write-up went live, information about an RCE vulnerability in Spring Framework was published. According to VMware:

“The specific exploit requires the application to run on Tomcat as a WAR deployment. If the application is deployed as a Spring Boot executable jar, i.e. the default, it is not vulnerable to the exploit. However, the nature of the vulnerability is more general, and there may be other ways to exploit it.”

If you have the following setup, you may be vulnerable:

• JDK 9 or higher
• Apache Tomcat as the Servlet container
• Packaged as WAR
• spring-webmvc or spring-webflux dependency

This does not mean that Spring Framework will not be impacted in the future as information is developed, or that your custom usage of Spring Framework is not vulnerable. However at this point, all prerequisites required to be vulnerable to this RCE require a customization of Spring that utilizes the vulnerable data binding.

How Bad is This?

Remote code execution is always a fairly big deal because it allows an adversary to execute malicious code on vulnerable servers; however, this shouldn’t induce panic in the way that Log4j did.  

POCs have been published that enable attackers to exploit this vulnerability, but it is unclear whether an attacker could realistically execute them. While some were able to replicate the POC the amount of prerequisites required to allow the POC to function indicate that this may have been a contrived example which identified unsafe deserialization uses. This is not the same as a properly vulnerable environment that could be exploited easily, e.g., Log4j, ProxyShell, etc. 

How Does This Compare To Log4j?

At this point there is no relation in severity to Log4j, the name that was created for it “Spring4Shell” was done to trigger automatic relation, but the same type of threat does not exist. This is not to say that a vulnerability in Spring does not exist, but rather that this issue does not appear to be the threat it was purported to be. 

What Should I Do?

Probably nothing! 

If you use Spring Cloud Functions and are exposing them to the internet, you should consider updating the version used and reviewing how they are utilized. Versions 3.1.6, 3.2.2 and unsupported older versions are all impacted by CVE-2022-22963 and should be updated to 3.1.7 or 3.2.3.

While there may be a way to set up Spring in a way that an RCE is possible through unsafe deserialization of commands, it requires a large number of prerequisites to be a risk to the environment.

Try Blumira For Free

Blumira’s cloud SIEM detects and alerts you about suspicious behavior in your environment so that you can stop an incident early enough to prevent damage. Each finding we send is accompanied with a security playbook, giving you clear recommendations on how to remediate an attack. Our support team of security analysts is always available to answer questions on how to interpret a finding, or for other security help. 

You can try Blumira for free; setup takes a matter of minutes.