Critical Alert: Spring Core(SpringShell) Remote Code Execution Vulnerability Exploited In The Wild

The Spring Framework is an application framework and inversion of the control container for the Java platform developed by VMware. Detected vulnerability with CVE-2022-22965 affects Spring Core and allows an attacker to send a specially crafted HTTP request to bypass protections in the library’s HTTP request parser, leading to remote code execution. Active exploitation is underway, using multiple published proof of concepts (POCs). People commonly refer to the vulnerability as “Spring4Shell” ,“SpringShell” or CVE-2022-22965 Spring4Shell which can be detected using a vulnerability management tool.

The developers of Spring have stated that successful exploitation requires meeting the following conditions:

1. Spring MVC and Spring WebFlux applications running on Java version JDK9+
2. The applications are running on Tomcat as a WAR deployment

The exploit’s scope extends beyond the above two conditions, which are still necessary. This implies that there is a chance for other exploit vectors to be present along with CVE-2022-22965 Spring4Shell. To prevent this exploitation, a good patch management software can be helpful.

The CVE-2022-22965 Spring4Shell is caused by the getCachedIntrospectionResults the Spring framework method wrongly exposes the class object when binding the parameters. The default Spring data binding mechanism allows developers to bind HTTP request details to application-specific objects. Back in 2010, CVE-2010-1622 was discovered and it allowed the class loader to modify the search path of the system’s class loader. The developers patched this by introducing a blocklist to exclude two methods. But later on, with a new feature in JDK version 9, this blocklist could be bypassed, leading to an exploit.

Send the following properties via HTTP POST in the actively exploited POC to construct the filename on the local filesystem:

class.module.classLoader.resources.context.parent.pipeline.first.directoryclass.module.classLoader.resources.context.parent.pipeline.first.prefixclass.module.classLoader.resources.context.parent.pipeline.first.suffixclass.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat

Then the class.module.classLoader.resources.context.parent.pipeline.first.pattern property is used to specify what template name can be passed in the next step to specify the Object that will be written to the file and executed.

The next step of the attack is for the attacker to send the template name as an HTTP Header that includes the Java code to execute.

Details regarding the below URL Encoded String:

1. request.getParameter(%22cmd%22) – The web shell uses the URL parameter to get commands from the attacker machine and execute it.
2. To enable the execution of web shell contents in the tomcat environment, we utilize suffix and c2(some POCs use prefix) headers.
3. first.prefix=tomcatwar -The deployment will involve using the web shell with this name.
4. first.suffix=.jsp – File extension for the web shell. The Tomcat environment executes JSP files, making them suitable for this purpose.
5. directory=webapps/ROOT – Write the web shell under the tomcat directory in a newly created directory.

NOTE: Treat the URL encoded string and the headers differently, as they have distinct prefixes and suffixes.

Once the class loads into the server, you can pass the ‘cmd’ parameter to execute remote commands.

http://localhost:8080/tomcatwar.jsp?pwd=j&cmd=id

Spring Framework versions 5.3.0 to 5.3.17 and versions 5.2.0 to 5.2.19

A malicious user could exploit this CVE-2022-22965 Spring4Shell vulnerability to gain unauthorized access to the server, steal user data, and cause undesirable side effects on the vulnerable machine.

The Spring Developers have released the patch for this vulnerability in versions 5.2.20+ and 5.3.18+. We recommend that all users upgrade to the latest applicable patched versions ASAP to avoid CVE-2022-22965 Spring4Shell. Users who cannot upgrade their Spring framework, the developers have suggested the following workarounds:

• Upgrading Tomcat – Provides adequate protection, but is only a temporary fix until users upgrade their Spring Frameworks.

• Downgrading to Java 8 – Internal research has shown that this mitigation provides no guaranteed results. If users choose this option, we suggest performing vulnerability checks on Java 8 is up and running.

• Set disallowed Fields – Set disallowedFields on WebDataBinder globally. This works generally, but as a centrally applied workaround fix, may leave some loopholes, in particular, if a controller sets disallowedFields locally through its own @InitBinder method, which overrides the global setting.

This was the summary of CVE-2022-22965 Spring4Shell vulnerability.