SpringShell Brings Hell to Java Developers – InApps 2022

Logj4Shell brought a lot of misery, the newly discovered SpringShell vulnerability, not to be confused with the totally different Spring Shell project, may bring as much or even more. Here’s why.

SpringShell is a new, “exciting” Java Development Kit’s (JDK) Spring Framework Remote Code Execution (RCE), aka CVE-2022-22965, security hole. Some people have given it a monstrous Common Vulnerability Scoring System (CVSS) score of 9.8. That means you should patch it before you even finish reading this article.

Impacts Many Versions of Spring

Essentially all versions of the Spring Framework, including 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older, unsupported versions are vulnerable. If you have any sense, you’ll upgrade from 5.3.x to 5.3.18+ and from 5.2.x to 5.2.20+. If you’re still using any older out-of-support versions of Spring Framework, stop already! Move to 5.3.18 or 5.2.20 as soon as possible.

Making matters worse, the Spring Framework is the world’s most popular Java framework. It’s used everywhere. Adding insult to injury the RCE vulnerability was leaked out ahead of CVE publication and the patch. The full details, and how to exploit it, were already loose and ready for hackers.

Can you say zero-day nightmare? I can.

The security company Rapid7 checked on the revealed exploit and found that it worked. With it, an attacker could drop a password-protected webshell in the Tomcat root directory called tomcatwar.jsp. The same method, however, Rapid7 remarked can deliver other malicious payloads. In short, “We’re certain that malicious class loading payloads will appear quickly.” They may already be out there. According to reports from BleepingComputer and GreyNoise it’s already being exploited.

Are You Vulnerable?

To be hit by this one, besides using an unprotected version of the Spring Framework you also must be using:

• JDK 9 or higher
• Apache Tomcat as the Servlet container.
• Packaged as a traditional WAR (in contrast to a Spring Boot executable jar).
• spring-webmvc or spring-webflux dependency.

But pay attention, even if you’re not doing any of the above you may still be vulnerable. The Spring community admits, “the nature of the vulnerability is more general, and there may be other ways to exploit it.”

There are other moves you can make to protect yourself. You can upgrade to Apache Tomcat 10.0.20, 9.0.62, or 8.5.78. That should block the Tomcat avenue of attack If the worse comes to worst and you can’t upgrade the Spring Framework or Tomcat, you can always downgrade to Java 8. It won’t be pretty, but it should work.

Larger than Log4j?

Making things even messier, there’s confusion that this has something to do with the commit to deprecate SerializationUtils or the recently released Spring Cloud Function CVE. Neither have anything to do with this major security kerfuffle.

So, where did the problem come from? According to secure developer software company Veracode, the actual cause is due to unforeseen access to Tomcat’s ClassLoader of a new Java 9 Module feature. The new Module object has a classLoader property and was therefore accessible through Spring’s property bindings when a Java object is bound to a request parameter. Combine access to the classLoader property with a well-known method for performing an arbitrary file write using the Tomcat AccessLogValve class, and ta-da! An attacker can write a malicious Java Server Pages (JSP) file accessible via the application server.

There may be more trouble ahead. The current exploit relies on a specific chain of accessible classes via Tomcat’s ClassLoader, but it’s possible that there are other exploitable classes accessible via the ClassLoader of other application servers. It’s not terribly likely, no alternative chains have been published in 12 years after all, but it’s still possible.

Other people are, shall we say, worried about this as well. David Lindner, CISO at Contrast Security, an application security company notes that Spring Framework is used “in 74% of Java applications.” Linder believes “it could have a larger impact than Log4j.”

I don’t know if it will be that bad, but let’s get real, this will be more than bad enough. Get patching folks. Good luck.

Featured image via Pixabay.