Critical Vulnerabilities in Spring and Spring Cloud Function That Will Probably Make This Weekend Less Fun - Analysis and Overview

During the period from March 29th to 31st multiple vulnerabilities related to Spring, a popular Java MVC framework that supports inversion of control and fast building of applications emerged.

The vulnerabilities that were found caused a lot of turmoil in the information security community due to a similar bug in the Java library Log4J (CVE-2021-44228). CVE-2021-44228 was found in December 2021 and has affected a lot of critical systems. The new vulnerabilities are serious and high impact due to their capabilities, ease of use and usage of the Spring framework in bigger enterprises. The vulnerabilities in question are the following:

CVE-2022-22965 Spring4Shell
CVE-2022-22963 Spring Cloud Function
Unconfirmed RCE via deserialization (Spring Core <=5.3.17)

Spring4Shell (CVE-2022-22965)

Official link: https://tanzu.vmware.com/security/cve-2022-22965 (31st March 2022)

Timeline

On March 29th, 2022, the member @80vul. from security research team KnownSec posted and later removed a screenshot in a tweet that showed a possible remote code execution vulnerability (RCE) against Spring Core. The researcher didn’t provide any proof-of-concept (POC) details[1]. The next day VX underground published a POC related to the vulnerability[2]. The situation complicated because multiple vulnerabilities were found at the same time and for the Spring4Shell vulnerability there was no CVE number at that moment[3]. More details were provided by @th3_protoCOL but are not removed from Twitter.

VMware, the vendor of Spring Framework, published an initial vulnerability report. Where it was confirmed that Spring MVC or Spring WebFlux applications based on Spring Framework 5.3 (5.3.17 and older or 5.2.19 and older) and that use JDK versions 9 or higher are vulnerable. The vulnerable Spring application should use a WAR deployment on Apache Tomcat, that acts as Servlet container[4]. Later, on Spring blog was published an early announcement, that describes the vulnerability and contains the new version of Spring (5.3.18 and 5.2.20) that addressed the vulnerability.

The RCE in this case works very similar to CVE-2010-1622, that at the time enabled attackers to execute arbitrary code via HTTP requests[5]. When a Spring application is deployed to Apache Tomcat, Tomcat’s WebAppClassLoader is accessible, which allows an attacker to call getters and setters to ultimately write a malicious JSP file to disk.

To exploit the vulnerability a crafted HTTP request has to be sent to the vulnerable system. To exploit Spring applications different configurations will require the attacker to do additional research to find payloads that will be effective. It is necessary to find an endpoint with DataBinder enabled, so that it is possible to send a payload that is automatically decoded. Most POCs use a payload that is decoded by the DataBinder to access the directory service interface DirContext via the WebAppClassLoader.

Example:

class.module.classLoader.resources.context.parent.pipeline.first.pattern=
%{c2}i if("j".equals(request.getParameter("pwd"))){ java.io.InputStream in
 = %{c1}i.getRuntime().exec(request.getParameter("cmd")).getInputStream();
int a = -1; byte[] b = new byte[2048]; while((a=in.read(b))!=-1){
out.println(new String(b)); } } %{suffix}i&
class.module.classLoader.resources.context.parent.pipeline.first.suffix=
.jsp&class.module.classLoader.resources.context.parent.pipeline.first.directory=
webapps/ROOT&class.module.classLoader.resources.context.parent.pipeline.first.prefix=
tomcatwar&class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=

Sources: [6] and [7]

Such a payload is specific to the Tomcat Servlet container and injects a JSP file (here tomcatwar.jsp) to the Tomcat root directory. In this example after injecting the JSP file it is possible to execute arbitrary commands by sending HTTP GET requests with URLs like http://localhost:8080/tomcatwar.jsp?pwd=j&cmd=whoami where the cmd request parameter can be any command to be executed[8].

Mitigation

By now there have been updated versions Spring Framework 5.3.18 and 5.2.20 released that address the vulnerability. Spring Boot applications should be upgraded to Spring Boot 2.5.12 and Spring Boot 2.6.6, which is announced to be available soon.

If an upgrade is not possible, it is possible to set disallowedFields that prevents the WebDataBinder from interpreting the HTTP request payloads and thus the RCE. In the Spring announcement, an example is shown (https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement):

@ControllerAdvice 
@Order(Ordered.LOWEST_PRECEDENCE) 
public class BinderControllerAdvice { 
  

    @InitBinder 
    public void setAllowedFields(WebDataBinder dataBinder) { 
         String[] denylist = new String[]{"class.*", "Class.*", "*.class.*", "*.Class.*"}; 
         dataBinder.setDisallowedFields(denylist); 
    } 
} 

This mitigation must be applied carefully as it only works if other controller classes don’t set local disallowedFields which would override the globally set denylist.

Spring Cloud Function (CVE-2022-22963)

Official link: https://tanzu.vmware.com/security/cve-2022-22963

The Spring Cloud Function framework allows developers to write cloud-agnostic functions (lambdas) using Spring Boot features. The vulnerability found enables to perform a RCE attack with Spring Cloud Function, and affects versions 3.1.6 and 3.2.2, as well as older, unsupported versions. The vulnerability is serious and has a CVSS score of 9.8 and High severity.

The vulnerability was caused by an official test case in Spring Cloud Function that has exposed a problem of handling Spring Expression Language (SPEL), which can be used to trigger the remote command execution by using specially crafted SPEL expressions that are in the HTTP request header parameter spring.cloud.function.routing-expression[9][10].

Example:

curl -i -s -k -X $’POST’ -H $’Host: 192.168.1.2:8080′ \
-H $’spring.cloud.function.routing-expression:T(java.lang.Runtime) \ 
.getRuntime().exec(\”touch /tmp/test”)’ \ 
–data-binary $’exploit_poc’ $’http://192.168.1.2:8080/functionRouter’ 

On 28th March 2022 around 22:46GMT on our honeypots that we are developing and running in the scope of the project Pet-HMR, we have caught requests that tried to enumerate this vulnerability. The scans had been performed from the ASN of SELECTEL from Russia. The attacker tried to enumerate multiple popular vulnerabilities from the previous years (CVE-2021-42013, CVE-2021-41773, CVE-2018-1000861, CVE-2021-3129, CVE-2021-44832, CVE-2021-2109 and more), besides the above-mentioned vulnerability found in Spring Cloud Function.

Mitigation

You should upgrade your services that use Spring Cloud Function to 3.1.7+ or 3.2.3+ to mitigate this vulnerability.

Conclusion

We are almost used to similar vulnerabilities in Java libraries that don’t handle or sanitize the input in a proper manner. This vulnerability probably will not be the last one with this type of impact. One of the possible long-term solutions is to regularly and thoroughly review libraries for security problems and bad security practices. These checks should be performed for high impact and widely used libraries and frameworks. A lot of effort in this field has been done previously but efforts have also intensified after the infamous Log4J vulnerability (CVE-2021-44228) found in December 2021. Various initiatives related to open-source project are putting a lot of effort to solve this problem by cross-functional collaboration between organizations (like OSTIF https://ostif.org/ and OpenSSF https://openssf.org).

From a defender’s perspective it is critical to follow new vulnerabilities for your infrastructure and meticulously update all software regularly. We know that this approach is not always easy to implement and it does not offer a complete protection from targeted attacks, but it can reduce the risk of compromise from opportunistic attackers. In a next step, every defender is advised to not stop at patching known vulnerabilities. Instead we advise to proactively review the technology stack that is in use and to implement mitigations based on assumed vulnerabilities of a similar nature. We will closely follow new vulnerabilities of this type and Internet activities related to exploitation probes and activities.

About X41 D-SEC GmbH

X41 D-SEC GmbH offers premium services in the field of network and application security. These services are provided by a team of specialized IT security experts, operating and skilled to the highest level. X41 employees regularly publish research results and conference papers that attract international attention. Therefore, it is not surprising that X41 count some of the largest companies in the world as its customers, including many outside Europe.

X41 focuses on the execution of penetration tests and code audits, especially of networks, web, and mobile applications, as well as all kinds of new products, protocols, and concepts.

NEWS

Critical Vulnerabilities in Spring and Spring Cloud Function That Will Probably Make This Weekend Less Fun - Analysis and Overview

Spring4Shell (CVE-2022-22965)

Timeline

Mitigation

Spring Cloud Function (CVE-2022-22963)

Mitigation

Conclusion

About X41 D-SEC GmbH

References