Resources
    Lab Walkthrough - Exploit ...
    25 August 22

    Lab Walkthrough - Exploiting Spring4Shell (CVE-2022–22965)

    Posted byINE
    facebooktwitterlinkedin
    news-featured
    preview_image.png

    Logo by Daniel Christensen

    In our lab walkthrough series, we go through selected lab exercises on our INE Platform. Subscribe or sign up for a 7-day, risk-free trial with INE and access this lab and a robust library covering the latest in Cyber Security, Networking, Cloud, and Data Science!

    What is Spring4Shell?

    In late March 2022, a severe vulnerability was uncovered in Spring applications running Java 9. It resulted due to a change was committed to Java 9. The vulnerability has been dubbed Spring4Shell and assigned a CVE identifier CVE-2022–22965.

    The issue happened due to exposure of a method on the Class object, from Java 9 onwards. This exposure of a new public method to the Class interface added a new way to dynamically trigger the class loader of the JVM. This opens the possibility of performing RCE on the affected Spring applications!

    Many public off-the-shelf exploits are available for this vulnerability, adding to the severity of this vulnerability.

    In this lab writeup, we will learn how an affected version of Tomcat (using JDK version 9) leads to remote code execution on the remote server, with all but a simple Python-based script.

    Read more: National Vulnerability Database, MITRE

    Challenge Details

    Lab Environment

    In this lab environment, the user is going to get access to a Kali GUI instance. A vulnerable app is deployed on http://demo.ine.local. The web app is running Tomcat utilizing the JDK version 9, which is vulnerable to Spring4Shell vulnerability.

    Mission

    Exploit the Spring4Shell vulnerability to get code execution on the remote server and retrieve the flag!

    Technical Difficulty: Proficient

    Challenge Link: https://my.ine.com/CyberSecurity/courses/ebd09929/cyber-security-vulnerabilities-training-library/lab/7896c1a8-aae9-40f3-86db-200c617c92ce

    Acknowledgements

    The base setup code, and the detection and exploitation scripts are taken from the following sources:

    Tools

    The best tools for this lab are:

    • dirb

    • Nmap

    • Python

    • A web browser

    Solution

    Step 1: Open the lab link to access the Kali GUI instance.

    spring4shell_1.png

    Step 2: Check if the provided machine/domain is reachable.

    Command:

    ping -c3 demo.ine.local
    spring4shell_2.png

    The provided machine is reachable.

    Step 3: Check open ports on the provided machine.

    Command:

    nmap -sS -sV demo.ine.local
    spring4shell_3.png

    spring4shell_3_1.png

    Port 80 is open. A website is served on this port (as highlighted in the above image).

    Step 4: Locate interesting endpoints/pages in the provided website.

    We will be using dirb to look for any interesting pages on the provided website:

    Command:

    dirb http://demo.ine.local
    spring4shell_4.png

    dirb was able to find two pages:

    Note: This step is not that relevant after all, but we have added it to show you a methodology of a pentester, that is, performing recon on the target and gaining valuable insights before jumping onto it and running random exploits against it.

    Step 5: Explore the identified web pages.

    We know that there is some website being served over port 80. We also discovered two more endpoints using dirb. Let’s see what these pages contain.

    Open the following URL in the browser:

    URL: http://demo.ine.local/

    spring4shell_5.png

    A web page is being served over it.

    Visit /login endpoint:

    URL: http://demo.ine.local/login

    spring4shell_5_1.png

    The same web page is being served over /login.

    Visit /error endpoint:

    URL: http://demo.ine.local/error

    spring4shell_5_2.png

    An error page is being served here. It must be shown after an invalid login.

    Step 6: Visit an endpoint to trigger a backend error.

    Visit the following URL (/%2f endpoint):

    URL: http://demo.ine.local/%2f

    spring4shell_6.png

    Notice that an error was triggered, and we got back a 400 — Bad Request page from the Apache Tomcat server.

    The version of Apache Tomcat is indicated on the error page: Apache Tomcat/9.0.59

    Step 7: Identify the Java version used by Apache Tomcat version 9.0.59.

    For this, we can send the following search request (outside the lab browser, since there is no internet access to the Kali GUI instance):

    Search Query:

    tomcat/9.0.59 java version

    spring4shell_7.png

    The response indicates that Java version 8 or later must be used by the target server.

    Step 8: Detect the presence of Spring4Shell vulnerability.

    Spring4Shell vulnerability is applicable for the deployments using JDK version 9 and newer.

    The provided target server might be vulnerable, provided that it is running JDK version 9 or newer. To test for that, we will use the following Python script:

    Reference: https://cybersecurityworks.com/blog/vulnerabilities/spring4shell-the-next-log4j.html

    Save the above script as detect.py.

    Check the help message for the script:

    Command:

    python3 detect.py --help
    spring4shell_8.png

    We will use the — url flag to pass the target URL:

    Command:

    python3 detect.py --url http://demo.ine.local
    Untitled.png

    The detection script identified the target server deployment to be vulnerable to Spring4Shell.

    Step 9: Exploit the Spring4Shell vulnerability.

    Now that we have detected the vulnerability, we can exploit it using the following Python script:

    Reference: https://github.com/reznok/Spring4Shell-POC/blob/master/exploit.py

    Save the above script as exploit.py.

    Check the help message for the script:

    Command:

    python3 exploit.py --help
    Untitled (1).png

    We will use the — url flag to pass the target URL:

    Command:

    python3 exploit.py --url http://demo.ine.local
    Untitled (2).png

    Exploitation was successful, and a JSP webshell was uploaded to the target server.

    Step 10: Leverage the uploaded webshell to run OS commands on the target server.

    Open the following URL (reported by the exploit.py script):

    URL: http://demo.ine.local/shell.jsp?cmd=id

    Note: The above URL would run the id command. To run any other command, change the string passed in the cmd parameter.

    Untitled (3).png

    Notice that the output for the id command is returned.

    The target application was running as root, and therefore, the webshell is also running as root (uid = 0)!

    We can perform enumeration on the target server and inspect the processes. Change the cmd parameter value and send the following command:

    Command:

    ps aux
    Untitled (4).png

    The command was executed successfully!

    The output is not well-formed as the newlines are not rendered on the web page. But we can inspect the page source (press CTRL+U) and see the returned output:

    Untitled (5).png

    Check the current working directory:

    Command:

    pwd
    Untitled (6).png

    The current working directory is /usr/local/tomcat/.

    Step 11: Retrieve the flag.

    Use the following command to locate the flag:

    Command:

    find / -iname flag*
    Untitled (7).png

    The flag is present in the file: /root/FLAG.

    Retrieve the flag:

    Command:

    cat /root/FLAG
    Untitled (8).png

    FLAG: 085a0ee954aa4562916fd8416fd2f3f8

    With that, we conclude the exploitation of the target server vulnerable to Spring4Shell.

    Technical Details

    If you are more curious about vulnerability and how it works, let’s break it down and understand it fully.

    How is this vulnerability created?

    Spring applications that run on Java 9 and above are susceptible to Spring4Shell. In contrast to the Java 8 (and below) versions, in Java 9, the developers committed a change in the Class object and exposed a method called getModule().

    This exposure of a new public method to the Class interface added a new way to dynamically trigger the class loader of the JVM. Prior to Java 9, Spring Framework included proper limitations for triggering the class loader.

    One common condition is when a request parameter is bound to a POJO (Plain Old Java Object), and the POJO is not decorated with the @RequestBody annotation. The class variable contains a reference to the POJO object that the HTTP parameters are mapped to. Attackers can specify the class variable in their requests, which enables them to directly access that object. Attackers can also access all child properties of the object through the class variable. And so, by following chains of properties, attackers can access all sorts of other valuable objects on the system.

    Why did this issue not happen with old Spring Core installations?

    The Spring Core code contains the following logic to prevent accessing child properties of the class variable. This logic is not foolproof:

    Snippet:

    if (Class.class == beanClass &&
       ("classLoader".equals(pd.getName()) || "protectionDomain".equals(pd.getName()))) {
           continue;
    }

    The code checks for “class.classLoader” and “class.protectionDomain”, but the logic can be bypassed with the following selector: “class.module.classLoader”

    How is the Spring4Shell vulnerability exploited?

    The ability to access the class variable and all of its sub-properties opens a big door for attackers to change the behavior of the web application (such as remote code execution).

    In Apache Tomcat, an attacker could access an AccessLogValve object from the class variable, by following the class.module.classLoader.resources.context.parent.pipeline.first path. A common way to weaponize this access is to redirect the access log to write a web shell into the webroot by manipulating different properties of the AccessLogValve object, including pattern, suffix, directory, and prefix.

    Affected applications

    • The app runs on Java 9 and above.

    • The app based on the Spring framework.

    • The app uses “Spring Parameter Binding” and has been configured to use a non-basic parameter type, such as POJOs (Plain Old Java Object).

    References

    Conclusion

    In this article, we saw how an adversary can leverage an application vulnerable to Spring4Shell to gain code execution on the target server. If the application is running as root, like it was in our lab, the attacker would gain elevated privileges on the server to perform further actions like adding a persistence mechanism or scanning other machines in the local network.

    Besides the exploitation, we went down the rabbit hole and learnt about the root cause and the technical details on this vulnerability — how it came into existence and how to identify if an application is affected by Spring4Shell.

    References

    Try this lab for yourself! Subscribe or sign up for a 7-day, risk-free trial with INE to access this lab and a robust library covering the latest in Cyber Security, Networking, Cloud, and Data Science!

    © 2024 INE. All Rights Reserved. All logos, trademarks and registered trademarks are the property of their respective owners.
    instagram Logofacebook Logotwitter Logolinkedin Logoyoutube Logo