Understanding the SpringShell Vulnerability in Spring Java Framework

June 30, 2022

WRITTEN BY THE KIUWAN TEAM
Experienced developers, cyber-security experts, ALM consultants, DevOps gurus and some other dangerous species.

Researchers recently announced the presence of a gaping security hole in Spring, a framework widely used by organizations developing Java applications. Designated CVE 2022 2965 and nicknamed Springshell, the substantial chink in the collective Java development community’s armor left many scrambling for a patch before hackers began exploiting the vulnerabilities.

Moreover, the announcement underscored the futility of security strategies that attempt to thwart attackers by individually denying all potentially dangerous functionalities. Instead, the incident pointed to the solution to the growing number of cyberattacks that exploit inherent security weaknesses lies in developing processes for building security into applications in the early software development stages.

Static application security testing (SAST) is a process that gives teams a comprehensive toolset for identifying code vulnerabilities in today’s complex and third-party software-reliant applications and libraries before deployment, during the development stage. Kiuwan is a high-performance SAST platform that gives developers confidence that their code will be free of preventable security vulnerabilities from the outset.

Springshell caught many security teams off guard, especially the majority that rely on open source libraries and the popular Java Spring development platform. Exploring how a vulnerability like this can appear overnight helps understand how steering away from the putting out fires paradigm in the direction of baked-in code security is the most viable way forward as an answer to help stem the growing epidemic of cyber attacks.

Springshell Overview and Fixes

What set the Springshell vulnerability apart was its potential impact on such a large segment of enterprise-level Java applications. To exploit the weakness, attackers must find a target running a combination of Spring, Java 9 or greater, and Tomcat.

Finding that configuration isn’t too difficult, considering Spring is the number one Java framework, and Java 9 has had time to broaden its reach in the five years since its release. In addition, Tomcat, the popular web browser for Java applications embedded into Spring Boot and Spring Bean,  increases the number of potential targets available to cybercriminals.

SPringShell Overview and Fixes

Mode of Attack

Spring relies on a deny list to limit access to ClassLoader. However, beginning with Java 9, developers added modules that offered alternative ways to access ClassLoader, which gives users the potential ability to write data to internal objects.

Investigators conducting PoC testing discovered that this vulnerability in Spring allows remote code execution (RCE) to configure setters and attributes using ClassLoader access. The method involves finding a POST endpoint in Spring and reconfiguring Tomcat to write a JSP or other executable file type containing malicious code to the Tomcat server .

Springshell Vulnerability Patch

The fix for Springshell is straightforward action that organizations should have immediately implemented upon the release of the vulnerability: upgrade to Spring framework versions 5.3.18 and 5.2.20.

It is safe to assume that a large majority of Spring Web projects running Java 9 and greater were affected by Springshell, as were many other users of the popular Spring framework. Investigators caution that Tomcat is merely a gadget that hackers can use to initiate the exploitation. Malevolent actors could implement other means beyond Tomcat to infiltrate security holes in Spring.

As often occurs, the known vulnerability only opens the door for many possible variations. Resourceful hackers can exploit a known security hole to try out a litany of attacks based on a common weakness. 

Once researchers or attackers open Pandora’s box by revealing a security weakness, it is too late to mitigate these risks. The way to minimize the exponentially increasing attacks that will likely occur is to take a different approach to security: DevSecOps. Development Security Operations promotes code security to prominence in the software supply chain.

This shift in mindset is necessary to combat the growing cybersecurity problem. The only workable system starts at the inception of the application and continues as part of the process until the end of the software’s Lifetime Development Cycle.

Risks of Exploitation

The potential ability to write an executable file with user-provided data is hazardous for organizations charged with safeguarding financial transactions and customer data security. It is impossible to fathom all of the imaginable exploitations this access affords to cybercriminals, and merely applying the patch will, in all likelihood, be inadequate protection. 

Data Crime

Data crime is the interception and theft of private or confidential data, including identity theft. With many financial, banking, and other privacy-centric institutions relying on the Spring framework for their Java application development, the opportunity for criminals is abundant. Simply put, when thieves can access restricted areas and write cloaked executable files, it will invariably lead to sensitive data breaches.

SpringShell-Risks

Bot Recruitment

A lesser-known exploit for Springshell is the recruitment of bot armies. Hackers can access servers and enslave them as participants in their ill-intended activities like crypto mining and DDoS attack hordes.

SAST for Sealing Data Security Holes Early

Vulnerabilities in security are a continually lurking nightmare for many institutions. In addition, the drive for faster production and continuous improvement and lifecycle put pressure on code development teams to rely heavily on open source and third party software libraries and functions. 

Manually checking up to millions of lines of code for adverse interactions of software and known security issues is logistically impossible. However, treating code security as an afterthought to the software supply chain is a mistake many organizations are no longer willing to make.

SAST helps development teams identify security issues before they become an inherent part of the code.

SAST for Sealing Data Security Holes Early

Kiuwan: Rock Solid Security Solution

KNW rock solid

Kiuwan SAST provides a rigorous approach to detecting software vulnerabilities with multiple language support. As a result, DevOps teams using Kiuwan enjoy the ability to seamlessly manage security within their code as they are writing it. This ability to continually scan and revise code reduces the weak spots for cybercriminals to target and results in more robust security at every application level.

Kiuwan is a global company providing a 360° application security platform to help guide code development teams in producing the highest quality, most secure applications possible. With today’s threat landscape, it becomes increasingly difficult to argue that working within the old system of patching and putting out fires is tenable.

Schedule an expert demo today with Kiuwan and discover how SAST can benefit the application development process, mitigate problems, and ultimately lead to a smoother development time, resulting in a more secure application.

Would you like to know more about implementing secure application development solution in your company? Get in touch with our Kiuwan team! We love to talk about security.