May 16, 2022
Infosec Writeups

Exploitation of Spring4shell in the Wild

Spring4Shell is a vulnerability of critical severity affecting Java’s most popular framework, Spring. Many cyber security firms have disclosed that they have observed the attempts to target the exploitation of CVE-2022-22965, trying to upload the webshells in order to execute the commands on the compromised systems. The attacks targeting the first Spring4Shell exploitation was first identified on March 30, 2022. According to a source, it was informed that one of Chinese security researchers leaked the details of the zero-day exploit by tweeting about it before the Spring developers could release the security patch for it. Later, the tweet was removed as well as his account was deleted from Twitter. The vulnerability affects the applications of Spring WebFlux and Spring MVC that are running on JDK 9+. Spring4Shell was first responsibly reported to VMWare by codeplutos, meizjm3i of the AntGroup FG Security Lab. It was then confirmed by researchers from Praetorian that it is a new remote code execution vulnerability. Spring4Shell is a remote code execution vulnerability that was introduced in the Spring Framework, making use of data binding functionality to bind the data stored within an HTTP request to certain parameters or objects being used by an application.

CVE ID : CVE-2022-22965 (Spring Core)
Severity Level - CRITICAL
CVSS v3 Score - 9.8
CVSS Vector - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

WHERE IS THE VULNERABILITY PRESENT?

This bug is present in the code level wherever the “getCachedIntrospectionResults” method is being used, eventually it can be misused to gain unauthorized access to such objects by passing their class names via an HTTP request. This vulnerability leads to remote code execution in Spring Core applications.

WHICH APPLICATIONS ARE VULNERABLE TO THIS?

Any running instance/application vulnerable to Spring4Shell, might have the following configurations mentioned below: -

  1. Running on JDK 9 or higher
  2. Apache Tomcat running as the Servlet container or WAR file
  3. Packaged as a WAR file format and deployed in a standalone Tomcat instance. Typical deployments on Spring Boot technology using an embedded Servlet container is not impacted.
  4. Having dependency on spring-webflux or spring-webmvc with parameter binding (enabled by default).
  5. Spring Framework versions of 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions.
  6. Lack of whitelisting of registered HTTP fields or explicitly blacklist the fields that could cause malicious intent.

VULNERABLE APP AND EXPLOITATION

  1. 2 stager RCE- It involves two requests to perform the RCE in Springshell (CVE-2022-22965) which are as shown below: -

    Reference- https://github.com/BobTheShoplifter/Spring4Shell-POC

    The following exploitation steps demonstrate how we can set the contents to be a JSP web shell and it is inserted inside the path of the Tomcat’s web application ROOT directory, which eventually allows us to upload a reverse shell inside Tomcat.

    HTTP request to upload the shell (“tomcatwar.jsp”)

    Exhibit: HTTP request to upload the shell (“tomcatwar.jsp”)

    HTTP request to use the shell code for running the commands remotely

    Exhibit: HTTP request to use the shell code for running the commands remotely

  2. Single request exploitation- This form of exploitation consists of only one HTTP request. It can be reproduced as follows: -

    Reference- https://github.com/reznok/Spring4Shell-POC

    Nuclei command execution to intercept the request using BurpSuite

    Exhibit: Nuclei command execution to intercept the request using BurpSuite

    Intercept the request, replace the payload in the URL by the Burp Collaborator URL and forward the request

    Exhibit: Intercept the request, replace the payload in the URL by the Burp Collaborator URL and forward the request

    Spring4Shell

    Exhibit: A callback is received at the Burp Collaborator and if you check the request headers and find User-Agent as Java, this indicates that the application is vulnerable to Spring4Shell

Impact

In order to define the impact of Spring4Shell vulnerability, we need to understand what the Spring Core Framework actually does. Spring Core basically performs the simplification of requests executing the parameter extraction on a server (Apache Tomcat server). It affects all the Java applications that are using Spring Core with non-default configuration. This type of bug has a high impact on Confidentiality, Integrity and Availability. The ways to exploit this vulnerability is easily available publicly as well as considering the fact that it does not require any authentication. This makes the CVSSv3 score as high as 9.8 which is known to be critical.

Listed are some of the Companies along with their products affected by Spring4Shell: -

VENDORPRODUCTTYPE
CiscoAMP, Secure Email, Secure Firewall, Malware Analytics, Secure Web ApplianceWAF, IPS, Malware Analysis, Mail Protection
AkamaiKSDWAF
MicrosoftAzure Firewall Premium, Defender / SentinelIPS
CitrixWAFWAF
CloudflareWAFWAF
FortinetFortiGate, FortiSASE, FortiADC, FortiProxy, FortiAnalyzerIPS
F5Big-IPWAF
SymantecMultiple productsIPS
HAProxyHAProxyWAF
PaloAltoNetworksNext-Generation Firewall, Prisma CloudIPS
Rapid7tCellWAF
TrendMicroCloud One, Deep Discovery InspectorIDS/IPS

DETECTION OF THIS VULNERABILITY

It can be detected whether the application is vulnerable to this CVE by checking the below: -

  1. Determine if the Spring Core Framework is used in your network.
  2. Ensure that deployments of the Spring Core Framework are running a version equal to or greater than 5.3.18 or 5.2.20.

MITIGATION TECHNIQUES

Some of the techniques to remediate this bug are as follows:

  1. Upgrade to the latest patched Spring Framework versions - 5.3.18 and 5.2.20
  2. In case, you cannot upgrade to the latest version of Spring Framework, you can follow the workarounds mentioned as below-
    1. Upgrade the version of Apache Tomcat to 10.0.20, 9.0.62 or 8.5.78 in order to get appropriate protection.
    2. Downgrading to Java 8 is also a considerable workaround.
    3. Adapt the configuration of a Web Application Firewall (WAF), if such is in place, to filter out requests containing “class.*“, “Class.*“, “*.class.*“, “*.Class.*“
    4. Disable the binding to specific parameters. You can do this by configuring “disallowedFields” on WebDataBinder globally. This can be performed by making use of the below code, which may work in most cases: -

REFERENCES

  1. https://nvd.nist.gov/vuln/detail/CVE-2022-22965
  2. https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
  3. https://www.trendmicro.com/en_us/research/22/d/cve-2022-22965-analyzing-the-exploitation-of-spring4shell-vulner.html
  4. https://github.com/NCSC-NL/spring4shell
  5. https://securelist.com/spring4shell-cve-2022-22965/106239/
  6. https://www.kaspersky.co.in/blog/spring4shell-critical-vulnerability-in-spring-java-framework/24004/
  7. https://www.datadoghq.com/blog/spring4shell-vulnerability-overview-and-remediation/
  8. https://portswigger.net/daily-swig/spring4shell-microsoft-cisa-warn-of-limited-in-the-wild-exploitation
  9. https://blogs.vmware.com/security/2022/04/how-to-hunt-for-spring4shell-and-java-spring-vulnerabilities.html
  10. https://www.upguard.com/blog/what-is-spring4shell