In the world of software development, ensuring the security of applications is of paramount importance. However, vulnerabilities can still arise, and it is crucial to promptly address them to prevent potential exploits. In this blog post, we will dive into the details of Spring4Shell CVE-2022-22965, a critical vulnerability that was discovered in the Spring Framework and explore the implications it poses for developers and organizations.

CVE Details

In 2022, a critical remote code execution vulnerability (CVE-2022-22965) was discovered in the Spring Framework, a popular Java framework for building web applications. The vulnerability, dubbed "Spring4Shell," allows an attacker to execute arbitrary code on a vulnerable server by sending a specially crafted HTTP request.

The vulnerability is caused by a flaw in the Spring Framework's data binding functionality. Data binding is a process of converting data from one format to another. In the Spring Framework, data binding is used to convert HTTP requests into Java objects.

The vulnerability exists in the getCachedIntrospectionResults() method, which is used to cache the results of data binding operations. The getCachedIntrospectionResults() method is vulnerable to a remote code execution attack because it does not properly validate the input data.

An attacker can exploit the Spring4Shell vulnerability by sending a specially crafted HTTP request that contains malicious code. The malicious code will then be executed on the vulnerable server.

The Spring4Shell vulnerability is a critical threat to organizations that use the Spring Framework. Organizations should immediately update their Spring Framework to a patched version to protect themselves from this vulnerability.

Most of the vulnerable setups were configured to the following dependencies:

• Spring Framework versions 5.3.0 to 5.3.17 and 5.2.0 to 5.2.19 and below
• JDK version 9+
• Apache Tomcat for serving the application
• Spring-webmvc or spring-webflux dependency
• Using Spring parameter binding that is configured to use a non-basic parameter type, such as Plain Old Java Objects (POJOs)
• Deployable, packaged as a web application archive (WAR)
• Writable file system such as web apps or ROOT

How to detect a Spring4Shell in a manuall pentesting process

There are a few ways to manually detect Spring4Shell in ethical hacking engagements. One way is to use a scanner, such as Nessus or Nexpose. These scanners can be configured to look for the specific signatures of the Spring4Shell vulnerability. Another way to detect Spring4Shell is to manually fuzz the application. This can be done by sending a variety of malicious requests to the application and seeing if any of them trigger an error. Finally, you can also manually inspect the application's source code for any references to the Spring4Shell vulnerability.

Here are the steps on how to manually detect Spring4Shell in ethical hacking engagements:

1. Identify the target application.
2. Determine the version of the Spring Framework that the application is using.
3. Research the Spring4Shell vulnerability to understand the specific signatures that you need to look for.
4. Use a scanner or manually fuzz the application to look for the signatures of the Spring4Shell vulnerability.
5. If you find any evidence of the Spring4Shell vulnerability, report it to the application owner.

Here are some additional tips for manually detecting Spring4Shell:

• Look for the following strings in the application's logs:

• "pipeline.first.pattern"
• "getRuntime"
• "exec"

• Look for the following files in the application's directory structure:

• "classes/org/springframework/core/io/support/SpringIoPropertySourceFactory.class"
• "classes/org/springframework/core/io/support/SpringIoResource.class"

• Look for the following Java methods in the application's source code:

• "getRuntime()"
• "exec()"
• "new ClassPathResource()"

If you find any evidence of the Spring4Shell vulnerability, it is important to report it to the application owner as soon as possible. The application owner can then take steps to patch the vulnerability and protect their users.

Exploitation

To successfully inject a web shell into the target system, it is necessary to manipulate the ClassLoader. Exploiting this vulnerability can be approached differently depending on the application running on the Spring Framework.

Currently, the focus seems to be on Apache Tomcat servers, with several proof-of-concept (PoC) releases. Therefore, we will now describe how our colleague, Iulian, developed an exploit module specifically targeting Apache Tomcat web servers to assist with vulnerability validation.

The concept involves utilizing the ClassLoader to modify crucial properties within the logging functionality. By doing so, the logger will create a web shell instead of a standard log file.

The properties involved are:

1. class.module.classLoader.resources.context.parent.pipeline.first.pattern: This property determines the content of the log file, where you can insert your web shell code.
2. class.module.classLoader.resources.context.parent.pipeline.first.prefix: The prefix refers to the name of the log file, allowing you to specify the name of your web shell file.
3. class.module.classLoader.resources.context.parent.pipeline.first.suffix: The suffix represents the file extension of the log file, which must be set as ".jsp" to create the web shell.
4. class.module.classLoader.resources.context.parent.pipeline.first.directory: This property defines the location of the log file. If the root directory is remotely accessible, setting the value as "webapps/ROOT" allows you to interact with your web shell by accessing "/.jsp".
5. class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat: This property is optional and provides a convenience for the attacker. Leaving it blank removes timestamps from the output, improving usability.

By understanding and manipulating these properties, you can exploit the vulnerability and inject a web shell into the targeted Apache Tomcat web server.

We can also make use of the following tool in exploiting the CVE-2022-22965 https://github.com/p1ckzi/CVE-2022-22965/blob/main/README.md

Mitigation

There are a few mitigation strategies that organizations can use to protect themselves from the Spring4Shell vulnerability (CVE-2022-22965):

• Update to a patched version of the Spring Framework. The Spring Framework has released patched versions for all affected versions. Organizations should immediately update their Spring Framework to a patched version.
• Disable data binding. If it is not possible to update to a patched version of the Spring Framework, organizations can disable data binding. To disable data binding, set the spring.mvc.annotation-driven.enabled property to false.
• Use a web application firewall (WAF). A WAF can help to protect against the Spring4Shell vulnerability by blocking malicious HTTP requests.
• Monitor your applications for signs of exploitation. Organizations should monitor their applications for signs of exploitation, such as unusual traffic patterns or changes in application behavior.

Reference

• Google Bard
• https://securelist.com/spring4shell-cve-2022-22965/106239/
• https://pentest-tools.com/blog/detect-exploit-spring4shell-cve-2022-22965

‍