A new zero-day vulnerability in the Spring Core Java framework called ‘Spring4Shell’ has been publicly disclosed, allowing unauthenticated remote code execution on applications.
Spring is a very popular application framework that allows software developers to quickly and easily develop Java applications with enterprise-level features. These applications can then be deployed on servers, such as Apache Tomcat, as stand-alone packages with all the required dependencies.
Yesterday, a new Spring Cloud Function vulnerability tracked as CVE-2022-22963 was disclosed, with Proof-of-Concept exploits soon to follow.
However, information about a more critical Spring Core remote code execution vulnerability was later circulating on the QQ chat service and a Chinese cybersecurity site.
Today, an exploit for this zero-day vulnerability was briefly leaked and then removed but not before cybersecurity researchers could download the code.
Since then, numerous cybersecurity researchers and security firms have confirmed that the vulnerability is valid and of significant concern.
This new Spring RCE vulnerability, now dubbed Spring4Shell, is caused by unsafe deserialization of passed arguments.
While it was initially thought to affect all Spring apps running on Java 9 or greater, it was later determined that there are specific requirements that must be met for a Spring app to be vulnerable.
Will Dormann, a vulnerability analyst at CERT/CC, said that an app must also use “Spring Beans”, use “Spring Parameter Binding”, and a “Spring Parameter Binding must be configured to use a non-basic parameter type, such as POJOs.”
Cybersecurity firm Praetorian also confirmed the bug relies on specific configurations to exploit properly.
“Exploitation requires an endpoint with DataBinder enabled (e.g. a POST request that decodes data from the request body automatically) and depends heavily on the servlet container for the application,” Praetorian explained in a blog post.
“For example, when Spring is deployed to Apache Tomcat, the WebAppClassLoader is accessible, which allows an attacker to call getters and setters to ultimately write a malicious JSP file to disk.”
“However, if Spring is deployed using the Embedded Tomcat Servlet Container the classloader is a LaunchedURLClassLoader which has limited access.”
“In certain configurations, exploitation of this issue is straightforward, as it only requires an attacker to send a crafted POST request to a vulnerable system. However, exploitation of different configurations will require the attacker to do additional research to find payloads that will be effective.”
While the requirements may limit the target size, BleepingComputer has been told by multiple sources that the Spring4Shell vulnerability is being actively exploited in attacks.
Praetorian’s blog post describes a way to partially mitigate Spring4Shell attacks by disallowing specific ‘patterns’ to be passed to the Spring Core DataBinder functionality.
As this vulnerability does not currently have a patch, it is strongly advised that admins using Spring applications deploy these mitigations as soon as possible.
Is this the new Log4Shell?
Spring is a very popular application framework for Java applications, raising significant concerns that this may lead to widespread attacks as threat actors scan for vulnerable apps.
As exploitation requires a simple HTTP POST to a vulnerable app, threat actors will be able to create scripts that scan the Internet and automatically exploit vulnerable servers.
Threat actors can use these exploits to execute commands on the server, which will allow full remote access to the device.
This attack scenario is reminiscent of what we saw in December with the mass exploitation of Log4j servers using the Log4Shell exploits to install malware and conduct ransomware attacks.
Due to the requirements to exploit this bug, it is too soon to tell how many applications are vulnerable.
To ultimately prevent this scenario from coming true, it is strongly advised that admin apply mitigations provided by Praetorian as soon as possible if they believe their apps are vulnerable.
Update 3/30/22 4:45 PM EST: Multiple sources state the vulnerability is actively exploited in attacks.
Update 3/30/22 09:21 PM EST: Added requirements possibly needed for the exploit to work.
Source: www.bleepingcomputer.com
