A zero-day vulnerability found in the popular Java Web application development framework Spring likely puts a wide variety of Web apps at risk of remote attack, security researchers disclosed on March 30.
The vulnerability — dubbed Spring4Shell and SpringShell by some security firms — has caused a great deal of confusion over the past 24 hours as researchers struggled to determine if the issue was new, or related to older vulnerabilities. Researchers with cybersecurity services firm Praetorian and threat intelligence firm Flashpoint independently confirmed that the exploit attacks a new vulnerability, which could be exploited remotely if a Spring application is deployed to an Apache Tomcat server using a common configuration.
Spring4Shell, which has not yet been assigned a Common Vulnerabilities and Exposures (CVE) identifier, will likely require broad patching to make certain that installations are not vulnerable to remote compromise, says Richard Ford, chief technology officer for Praetorian.
“The impact is relatively broad in terms of what we know to be trivially exploitable at this point,” he says. “Even people who run [non-vulnerable configurations] will likely be recommended to patch, even though — today — we don’t have a working RCE [remote code execution] for it.”
The hands-on research by Praetorian and Flashpoint ended speculation by a variety of security professionals on social media that the proof-of-concept code actually exploited older, already patched vulnerabilities. The vulnerability targeted by the exploit is different from two previous vulnerabilities disclosed in the Spring framework this week — the Spring Cloud vulnerability (CVE-2022-22963) and the Spring Expression DoS vulnerability (CVE-2022-22950), according to researchers studying the issues.
The Retail and Hospitality ISAC also issued a statement that its researchers had confirmed the vulnerability.
Spring, which is now owned and managed by VMware, is currently working on an update, according to Praetorian. At this point, threat actors are not yet communicating about the vulnerability, Flashpoint stated in a blog post.
“As of this publishing, Flashpoint analysts have yet to observe exploitation attempts, or threat actor communications, regarding the SpringShell vulnerability,” Flashpoint wrote in its initial analysis, adding: “[C]urrent information suggests in order to exploit the vulnerability, attackers will have to locate and identify web app instances that actually use the DeserializationUtils, something already known by developers to be dangerous. If proven true, SpringShell’s impact has the potential of being misconstrued as being more impactful or widespread as it may be.”
A Deleted Twitter Post
Cybersecurity professionals first learned of the vulnerability when a Chinese security researcher published a screenshot of the proof-of-concept attack. The hackers soon after took down the screenshot, possibly because sharing vulnerability information publicly without government approval is a crime in China. VX-Underground, a hub for offensive cyber techniques and malware, tweeted about the leak midday on March 30.
“A Java Springcore [sic] RCE 0day exploit has been leaked,” the tweet stated. “It was leaked by a Chinese security researcher who, since sharing and/or leaking it, has deleted their Twitter account.”
Once researchers gained access to the screenshots, the exploit only took a few hours to reverse engineer and get the attack working, says Anthony Weems, principal security engineer at the research labs of Praetorian.
The attack currently works for Spring applications deployed to Tomcat, but Spring applications that use Spring Boot and embedded Tomcat, a common mechanism of deployment, are not exploitable. While Weems would not relate the attack to the Log4Shell exploit discovered in December, some similarities do exist.
“Like Log4j, it is something that your framework is doing that you wouldn’t expect it to do,” he says, adding that the similarity ends there, as a many Spring framework configurations are not vulnerable. “You have to have chosen Spring as your application framework, and be using Tomcat, but not SpringBoot with embedded Tomcat. That is a common configuration that is safe.”
Log4Shell “Much Worse”
Yet the Spring framework vulnerability does not seem nearly as critical as the issues found in Log4j, says Praetorian’s Ford. The attackers need to know the address, including the application’s endpoint, to exploit the vulnerability. Moreover, applications not exposed to the Internet are safe, unlike some cases with Log4j.
“Log4Shell was much worse, because the exploit could hit systems that were not directly connected to the Internet,” he says. “In this case, you are going to be needed to be hitting the machine.”
