Published March 31, 2022
Prepared by Deepwatch Threat Intel Team
Key Points:
- Spring confirmed that a remote code execution vulnerability, dubbed Spring4Shell, exists in the Spring framework and impacts Spring MVC and Spring WebFlux applications running on JDK 9+.
- Shortly after the vulnerability was disclosed proof of concept exploit code was publicly available then removed, but not before security researchers were able to copy it and confirmed that it works.
- Deepwatch has created and deployed numerous detections to observe suspicious activity associated with possible exploitation of this vulnerability and those similar in nature.
- Deepwatch Threat Intel Team assesses with high confidence that threat actors will begin to conduct widespread exploit attempts via HTTP requests similar to the Log4j exploitation that was observed back in December. Organizations are encouraged to update their Spring Framework to 5.3.18 or 5.2.20. For those that are unable to update at this time Deepwatch Threat Intel Team recommends organizations apply the workarounds as set out by Spring in their advisory.
Overview:
Initial reports of a remote code execution (RCE) vulnerability existing in the Spring framework started coming in through Twitter and eventually being reported by the cybersecurity news outlet, Cyber Kendra, on March 30.
Shortly after the vulnerability was disclosed a proof-of-concept exploit code was published then removed, but not before researchers, and likely threat actors as well were able to copy the exploit code.
What Is Spring:
According to Spring’s website, “Spring makes programming Java quicker, easier, and safer for everybody. Spring’s focus on speed, simplicity, and productivity has made it the world’s most popular Java framework.”
Vulnerability Details:
On March 31 Spring confirmed the vulnerability and stated in their advisory that the vulnerability at this time has not been assigned a CVE identifier and it was first reported to VMWare on March 29 by codeplutos, meizjm3i of AntGroup FG.
The advisory goes on to state that “the vulnerability impacts Spring MVC and Spring WebFlux applications running on JDK 9+. The specific exploit requires the application to be packaged as a WAR and deployed to Apache Tomcat. This does mean the exploit does not work for Spring Boot with embedded Tomcat. However, the nature of the vulnerability is more general, and there may be other ways to exploit it.”
Is This Related to CVE-2022-22963?
No. According to Spring’s advisory, these are unrelated vulnerabilities.
CVE-2022-22963 is an RCE in the Spring Cloud Function. This vulnerability affects versions 3.1.6, 3.2.2, and older, unsupported versions of the Spring Cloud Function. When an organization uses routing functionality it is possible for a threat actor to provide a specially crafted Spring Expression Language (SpEL) as a routing expression that may result in RCE and access to local resources.
Spring and VMWare recommend organizations update to 3.1.7 or 3.2.3.
Exploitation Details:
In a report published by the cybersecurity firm, Praetorian, they state that “In certain configurations, exploitation of this issue is straightforward, as it only requires an attacker to send a crafted HTTP 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.
This vulnerability allows an unauthenticated attacker to execute arbitrary code on the target system.”
According to Praetorian’s research “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. 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.
To add more complexity to exploiting the vulnerability, Will Dorman, a vulnerability analyst with CERT/CC stated in a Twitter post that the following are the prerequisites to exploitation:
- Uses Spring Beans
- Uses Spring Parameter Binding
- Spring Parameter Binding must be configured to use a non-basic parameter type, such as POJOs
Am I Vulnerable to Spring4Shell:
Spring states in their advisory that the following requirements are needed:
- JDK 9 or higher
- Apache Tomcat as the Servlet container
- Packaged as WAR
- spring-webmvc or spring-webflux dependency
However, the nature of the vulnerability is more general, and there may be other ways to exploit it that have not been reported yet.
What Do I Need to Do?
Spring recommends updating to versions 5.3.18 and 5.2.20 which address the vulnerability. They also provide the following commands:
To update with Maven:
<properties>
<spring-framework.version>5.3.18</spring-framework.version>
</properties>To update with Gradle:
ext['spring-framework.version'] = '5.3.18'For those organizations unable to update at this time Spring provides the following workaround:
Leaked reports recommend setting disallowedFieldson WebDataBinder through an @ControllerAdvice which Spring says “works generally, but as a centrally applied workaround fix, may leave some loopholes.” And recommends the following workaround as it is a more “fail-safe” way:
“Applications could extend RequestMappingHandlerAdapter to update the WebDataBinder at the end after all other initialization. In order to do that, a Spring Boot application can declare a WebMvcRegistrations bean (Spring MVC) or a WebFluxRegistrations bean (Spring WebFlux).
For Spring MVC without Spring Boot, an application can switch from @EnableWebMvc to extending DelegatingWebMvcConfiguration directly as described in Advanced Config section of the documentation, then overriding the createRequestMappingHandlerAdapter method.”
Spring provides the following as an example in Spring MVC (and similar in WebFlux):
package car.app;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.autoconfigure.web.servlet.WebMvcRegistrations;
import org.springframework.context.annotation.Bean;
import org.springframework.web.bind.ServletRequestDataBinder;
import org.springframework.web.context.request.NativeWebRequest;
import org.springframework.web.method.annotation.InitBinderDataBinderFactory;
import org.springframework.web.method.support.InvocableHandlerMethod;
import org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter;
import org.springframework.web.servlet.mvc.method.annotation.ServletRequestDataBinderFactory;
@SpringBootApplication
public class MyApp {
public static void main(String[] args) {
SpringApplication.run(CarApp.class, args);
}
@Bean
public WebMvcRegistrations mvcRegistrations() {
return new WebMvcRegistrations() {
@Override
public RequestMappingHandlerAdapter getRequestMappingHandlerAdapter() {
return new ExtendedRequestMappingHandlerAdapter();
}
};
}
private static class ExtendedRequestMappingHandlerAdapter extends RequestMappingHandlerAdapter {
@Override
protected InitBinderDataBinderFactory createDataBinderFactory(List<InvocableHandlerMethod> methods) {
return new ServletRequestDataBinderFactory(methods, getWebBindingInitializer()) {
@Override
protected ServletRequestDataBinder createBinderInstance(
Object target, String name, NativeWebRequest request) throws Exception {
ServletRequestDataBinder binder = super.createBinderInstance(target, name, request);
String[] fields = binder.getDisallowedFields();
List<String> fieldList = new ArrayList<>(fields != null ? Arrays.asList(fields) : Collections.emptyList());
fieldList.addAll(Arrays.asList("class.*", "Class.*", "*.class.*", "*.Class.*"));
binder.setDisallowedFields(fieldList.toArray(new String[] {}));
return binder;
}
};
}
}
}
Deepwatch’s Response:
Deepwatch has developed a detection, dwl_weba_00021: Spring4Shell Exploit Attempt, to observe possible exploitation of web servers for Spring4Shell and the recently disclosed CVE-2022-22963. As part of this custom detection, we are also working to run this across Deepwatch’s customer base to start identifying potential observables for use with our emerging threat detections.
Additionally, Deepwatch has out-of-the-box (OOTB) detections such as dwa_weba_00018: Web Command Injection Attempt and dwa_weba_00019: Web Shell Console Usage, which while not designed specifically for this exploit, are designed to observe activity associated with exploitation of similar vulnerabilities. Deepwatch also employs open-source and organic intelligence in our detections, such as inbound/outbound IP and domain matches, to observe tactics, techniques, and procedures in conjunction with observables to identify possible threat actor activity.
Deepwatch Threat Intelligence Outlook
Deepwatch Threat Intel Team assesses with high confidence that threat actors will begin to conduct wide-spread exploit attempts via HTTP requests similar to the Log4j exploitation that was observed back in December. For high-value targets actors may conduct further research to identify effective payloads. Organizations are encouraged to update their Spring Framework to 5.3.18 or 5.2.20. For those that are unable to update at this time Deepwatch Threat Intel Team recommends organizations apply the workarounds as set out by Spring in their advisory.
Sources:
- https://www.cyberkendra.com/2022/03/springshell-rce-0-day-vulnerability.html
- https://archive.ph/DIbrv
- https://spring.io/why-spring
- https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement
- https://www.praetorian.com/blog/spring-core-jdk9-rce/
- https://twitter.com/wdormann/status/1509280535071309827
- https://tanzu.vmware.com/security/cve-2022-22963
Author: Eric Ford and Deepwatch Threat Intel Team
↑
Share