Keysight‘s Take on Spring4Shell

Spring4shell or SpringShell, the supposed Log4J equivalent for Spring that took the internet by storm after a couple of tweets were published by a Chinese Twitter account on March 29, 2022.

Now, as things have settled down, we know more details regarding the vulnerabilities. To start, there are two main CVEs that are related to the incident: CVE-2022-22963 and CVE-2022-22965.

Among these, the first one affects Spring Cloud Foundation/Functions and the other one affects Spring Core, which is the vulnerability dubbed as "SpringShell". Both of the vulnerabilities have publicly available Proof of Concept, which we will review.

If you are running the software in vulnerable conditions, an attacker might be able to leverage these exploits and run arbitrary code leading to system compromise.

ATI's honeypots have results that show CVE usage by attackers :

The graph shows the attack attempts that have been using the two vulnerabilities. We can see a surge in number just after the vulnerability was disclosed, which dropped by a lot once we got to know more details about them and how they are not as widespread as Log4J.

The following image shows the payloads used by the live attacks in JSON format  :

CVE-2022-22963: Are you affected?

This affects a niche part of Spring, which  is the Spring Cloud Functions (<=3.1.6 and <=3.2.2), a technology that allows the developers to focus on functionality rather than runtime environments.

Reason for Vulnerability

Spring uses Spring Expression Language (SpEL), a powerful expression language that supports querying and manipulating an object graph at runtime.

The vulnerable versions of Spring Cloud Function allow a user input of SpEL expressions though the spring.cloud.function.routing-expression HTTP header. Using this, an attacker can send crafted HTTP requests with SpEL expressions with OS commands injected.

Let's check out the public POC available to understand the attack. 

Configuring the Target

◆ Take  a Linux environment (Ubuntu in this case) and git clone the project: https://github.com/Kirill89/CVE-2022-22963-PoC

◆ Install maven and java using their respective install commands. These are required for running the POC.  

◆ Once  installed, go inside the git project folder and run - mvn spring-boot:run. This should set up our vulnerable application for exploitation. We will see a screen such as the following:

Attack in Action

◆ Run the following command from the attacker machine by using  a tool like curl. Curl is a simple utility to download files through CLI, normally over HTTP. 

◆ curl -X POST -H 'spring.cloud.function.routing-expression: T(java.lang.Runtime).getRuntime().exec("touch /tmp/PWNED")' -d xxx http://<VICTIM_IP>:8080/functionRouter

◆ On  running the command, we will get a 500 INTERNAL SERVER error, but if we look in our /tmp directory on the victim machine, we now have a file called PWNED. That indicates that we have got Remote Code Execution on the victim.

CVE-2022-22965: Are you affected?

Let's see the actual SpringShell vulnerability, which  is a flaw in the core Spring library. According to VMware, these are the versions affected : 5.3.0 to 5.3.17 and 5.2.0 to 5.2.19  and older unsupported versions. The vulnerability was named Spring4shell because it's widely used Java library like Log4J, but  unlike Log4J , it's not as straight forward to be exploited. There are a few conditions that need to be fulfilled:

◆ JAVA 9 or newer

◆ spring-webmvc or spring-webflux

◆ It needs to run using Apache Tomcat

◆ Built as Web Application Resources (WAR)  file, default deployment as Jar is not vulnerable.

All these conditions make Spring4Shell a lot less widespread compared to Log4J. 

Reason for Vulnerability

The vulnerability is because of  inadequate validation of parameters used for data binding, allowing for manipulation of the ClassLoader. Basically, what that allows us to do is access certain classes through HTTP requests. This lets the attacker overwrite the Tomcat logging configuration with which a JSP web shell can be uploaded, which  can be used to do achieve RCE.

Configuring the Target

◆ Git clone the GitHub project : https://github.com/lunasec-io/Spring4Shell-POC

◆ You  need to have docker installed to follow along. You can find the instructions to install the same at https://docs.docker.com/engine/install/ 

◆ Now  we need to go inside the project folder and simply run

◆ docker run -p 8080:8080 spring4shell

◆ Once  the vulnerable server is up, navigate to the project folder.

Attack in Action 

◆ We would need python to run the attack script. https://www.python.org/downloads/

◆ We then run: python3 exploit.py --url http://<VICTIM_IP>:8080/helloworld/greeting

◆ The logs show the attack was successful and we will be able to run commands using the given URL. Running the same in the browser, we can see that we have RCE.

Traffic Over the Wire

We used Open-Source Networking Monitoring tool Wireshark to view the messages exchanged while triggering the attacks for both the CVEs. Let's analyze those:

Not much to see here, except the header we passed with the commands to be run.

If we take the payload that's being sent, do a URL decode and split it by '&',  we can now read it clearly.

So, we see that the attack is trying to access the classes and trying to change the various logging attributes.

The first statement that changes the 'pattern' attribute uses JAVA getRuntime().exec that lets us run shell commands later. The rest of the statements change the path where the WebShell will be created (webaspps/ROOT) and the name of the same (shell.jsp). We can also see two variables, prefix and suffix which will be substituted by the next request.
 

We can see the values of the prefix and suffix here. <% and %> are JSP Scriptlets that are used to include Java statements in the JSP file.

Mitigation

Mitigation of these vulnerabilities would need upgrading the frameworks to the patched versions. For CVE-2022-22963, we need to upgrade Spring Cloud Functions to 3.1.7+ or 3.2.3+ and for CVE-2022-22965, we need to upgrade Spring Core to 5.3.18+ or 5.2.20+.

You can also use the KEYSIGHT test platforms with ATI subscription to safeguard your network against such attacks. Keysight Threat Simulator or BreakingPoint products can help you assess your network security controls and determine whether you can be protected before the patch. This kind of assessment is valuable as it can let you know if you have protection during the time before a change management window will open.

Leverage subscription service to stay ahead of attacks

Keysight's Application and Threat Intelligence (ATI) Subscription provides daily malware and bi-weekly updates of the latest application protocols and vulnerabilities for use with Keysight test platforms. The ATI Research Center continuously checks threats as they appear in the wild and has released a strike for both the CVEs as part of BreakingPoint System's recent update 2022-07 (CVE-2022-22963) and 2022-08 (CVE-2022-22965) with multiple variations of the attack to help keep your network secure. 

The following image shows screenshots of the CVEs as a strike in BreakingPoint System: