Revisiting Spring4Shell: How Cloud Application Detection and Response (CADR) offers multi-layer protection

Protecting applications running in cloud-native environments is top of mind for many security practitioners. To keep up with the increasing number of threats targeting workloads in the cloud, delivering multi-layer protection by seamlessly integrating visibility, analytics, and response in one platform is key. Cloud Application Detection and Response (CADR) is thus emerging as a stronger approach to application security. CADR ensures a more holistic application security strategy, continuously monitoring for suspicious or unauthorized activities at any layer of an application, from code to container.

In this blog, we’ll use the example of the high-profile Spring4Shell vulnerability to demonstrate how Dynatrace can detect and prevent exploitation on multiple layers. This blog will illustrate a simplified view of the steps an attacker can take, from initial access through remote code execution to sending commands to a web shell and further exfiltrating cloud resources. For each step, we will demonstrate how different features in Dynatrace Application Security can be used to detect and prevent critical threats.

What is Spring4Shell?

Spring4Shell (CVE-2022-22965) is a critical remote code execution vulnerability in the Spring Framework, a popular Java platform for building web applications. The exploit specifically targets applications running on Java 9 or newer, often deployed with Apache Tomcat using specific packaging (such as WAR deployment). While Spring4Shell is not the most recent vulnerability, its high criticality, easiness of exploitation, and wide distribution make it still relevant today. According to Dynatrace analysis, 50% of Fortune 500 companies are still vulnerable to Spring4Shell.

When exploited, Spring4Shell allows an attacker to send specially crafted HTTP requests that manipulate class properties via Spring’s data-binding mechanism. In a vulnerable environment, the attacker can overwrite internal configuration fields, such as those belonging to ClassLoader or Tomcat’s file upload paths.

The exploit can be used to write a web shell or other malicious Java code (commonly as a .jsp file) into a directory served by the webserver (for example, Tomcat’s webapps/ROOT). Once the attacker writes a JSP web shell to the filesystem, they can send commands to it and gain remote control to execute commands, read or modify files, and escalate privileges.

One of the first public exploit PoCs of the Spring4Shell vulnerability was shown by the Github user Reznok in the repository Spring4Shell-POC. The repo provides a simple Java application based on a vulnerable version of the spring framework in a container.

To demonstrate how Dynatrace detects an exploit of Spring4Shell, we set up a small Kubernetes cluster and deployed the container with the vulnerable application.

CADR first layer of defense: Runtime Vulnerability Analytics

In the Kubernetes app, we can see the deployed container “spring4s-ti-app-no-sc” running the test application vulnerable to Spring4Shell.

Accessing the running application shows the expected output:

Looking in the Vulnerabilities App, we can see the container with the Spring4Shell vulnerability. The app shows the affected process groups in the container as well as the vulnerable functions related to Spring4Shell, which are currently in use.

Presenting the first layer of defense, the Vulnerabilities App shows exactly where a specific vulnerability is located and if it is currently in use by a specific process group, which is the case in our scenario. Upgrading the vulnerable packages to a non-vulnerable version would remediate this threat by closing the entry door for an attacker to further propagate through the system.

CADR second layer of defense: Security posture management

On the deployed container, we now run the exploit script provided in the repo and see the expected output:

~$ python3 exploit.py --url http://10.200.2.57:8080/helloworld/greeting

[*] Resetting Log Variables.

[*] Response code: 200

[*] Modifying Log Configurations

[*] Response code: 200

[*] Response Code: 200

[*] Resetting Log Variables.

[*] Response code: 200

[+] Exploit completed

[+] Check your target for a shell

[+] File: shell.jsp

[+] Shell should be at: http://10.200.2.57:8080/shell.jsp?cmd=id

As shown in the terminal output above and explained in detail in our earlier blog post about Spring4Shell, the exploit changes the log configuration and then writes a file containing malicious code to the vulnerable environment.

Now, we have a web-shell deployed that we can leverage to execute commands in the container:

A closer look at the deployed container “spring4s-ti-app-no-sc” in the Security Posture Management App shows that the deployed container fails certain checks defined in Kubernetes security benchmarks, such as the one from the Center of Internet Security (CIS). One specific check, as shown below, verifies the presence of a security context in the Kubernetes deployment .yaml file of our container, which is missing in our case.

We add the “SecurityContext” to the deployment .yaml file to ensure that the main process in the container is running as a non-root user (such as uid 1000). With this adjusted .yaml file we deploy the container again under the name “spring4s-ti-app-sc” on our Kubernetes cluster. As shown below, this deployment passes the security context check.

Executing the Spring4Shell exploit on the deployed “spring4s-ti-app-sc” container fails because the main container process is not running as root. We can verify this by checking the logs of the container, which state that creating the /usr/local/tomcat/webapps/ROOT directory failed and the shell.jsp file cannot be found, as shown below:

Attempts to access the web-shell do not work on the container with the enabled security context.

Security posture management is thus critical. In this scenario, simply changing specific configurations of a deployment—without touching the application or upgrading a vulnerable package—can prevent an exploit from being successful. Mapping checks of a compliance benchmark to attack techniques used during an exploit can significantly reduce the risk of a successful compromise.

CADR third layer of defense: Threats & Exploits

Identifying vulnerabilities such as Spring4Shell and adjusting configurations to prevent exploitation requires detailed knowledge about the vulnerability and exploit techniques against it. For cases where a vulnerability is not known yet (i.e. “zero-day” vulnerabilities), Dynatrace’s Threats & Exploits App provides the ability to automatically detect, monitor and block attacks that are based on specific techniques such as command or SQL injection.

The screenshot below shows the detection of command injection which are coming through the deployed web-shell on the “spring4s-ti-app-no-sc” container. The app shows the exploit in detail, such as the file name of the deployed web-shell, “shell.jsp”, and the submitted command, “cat /etc/passwd”.

The Threats & Exploits App not only enables the detection of a command injection attack but also can actively block it.

Sending a web-shell command to the vulnerable application does not work anymore, and the server returns an error code.

Dynatrace’s security offering enables protection against known, but also against unknown vulnerabilities and threats. 

CADR fourth layer of defense: Security Investigator

Investigating if a system was compromised and an exploit was successful is a top priority after a critical vulnerability is discovered. A first go to point is to find indicators of compromise in log files, which Dynatrace ingests and makes searchable through DQL (Dynatrace Query Language).

When it comes to detecting exploits of Spring4Shell, log files of the application or the tomcat server are not reliable sources, since the exploit is based on changing and overwriting the log configuration. Therefore, we leverage distributed trace records and investigate network requests to our deployed test applications. From the Vulnerabilities App, we know exactly which Kubernetes workloads are affected by the Spring4Shell vulnerability, namely “spring4s-ti-app-sc” and “spring4s-ti-app-no-sc” as shown in the screenshot from the Vulnerabilities App below.

Now, we use this information to run a query in the Security Investigator App as shown below to take a closer look at which successful (status code 200) requests were sent to our affected containers. The “spring4s-ti-app-no-sc” container where the exploit was successful had two web-shell files deployed (shell.jsp and tomcatwar.jsp) and received multiple shell commands which are shown in the url.query fields. Some of them, such as cmd=cat%20/etc/passwd, could be of malicious intent.

With the ability to combine the exact location of a vulnerability through the Vulnerabilities App and observing successful requests in the Security Investigator App, we can determine successful exploits of vulnerabilities such as Spring4Shell, independent of indicators that can easily be adjusted by attackers.

We couldn’t identify any successful web-shell requests in the “spring4s-ti-app-sc” container, which was expected since the exploit didn’t work there due to the applied security context as explained above.
In a real-world scenario, we might face a situation where thousands of requests are sent to a container. In such cases, it can be more difficult to identify attacker traffic going to a web-shell. Querying for a summary of files of recently received requests can help to narrow down the detection of suspicious files on a container. This strategy revealed another suspicious file, which could be an indicator of a web-shell.

Also summarizing new url.path endpoints (which have not been seen before) will help to identify suspicious endpoints. We can further leverage information in our queries from the Threats & Exploits App which provides information about blocked or monitored attack requests as we show in the previous section.

This shows only a scratch on the surface of Dynatrace’s abilities to detect and investigate critical exploits in detail. One of our recent blog post about threat detection in cloud native environments demonstrates such an investigation in greater detail.

Conclusion

Dynatrace offers multi-layer detection and defense approach against cloud-native applications. By combining Runtime Vulnerability Analytics, Security Posture Management, Threats & Exploit detection, and the Security Investigator, the Dynatrace platform approach to Cloud Application Detection and Response (CADR) helps detect and mitigate critical vulnerabilities such as Spring4Shell on multiple layers to keep your organization secure.