[BreachExchange] Zero-Day Vulnerability Discovered in Java Spring Framework

[Matthew Wheeler]

https://www.darkreading.com/application-security/zero-day-vulnerability-discovered-in-java-spring-framework


A proof-of-concept exploit allows remote compromises of Spring Web
applications.


Robert Lemos

Contributing Writer

March 30, 2022

Spring Framework



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."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20220331/51caa7e8/attachment.html>