If the Log4Shell exploit wasn’t enough, a new zero-day has been recently identified, Spring4Shell, a.k.a. CVE-2022-22965. Similar to Log4Shell, this new exploit can gain control of a victim’s computer within seconds, using simple HTTP requests.
Exploits like this are a perfect opportunity to demonstrate how deception technology, such as Fidelis Deception®, can serve not only as an early warning system for detecting zero-day threats but can also provide valuable insights to network defenders into attacker activity.
For this blog, we created a decoy targeting the Spring4Shell vulnerability so we can gain intelligence about the attacker’s methods and learn how to stop attacks like these once and for all. We’ll show a step-by-step scenario of what these attacks look like and how easily they can take control and collect valuable information from the victim machine.
For all these attack attempts, our victim machine will be a Container-based Decoy. This new feature of Fidelis Deception version 9.5 allows users to spin up customized decoys quickly and easily with rich data in a container environment. All attacker activity is of course constantly monitored and analyzed, which enables network defenders to monitor the attack and collect the attacker’s tools and techniques.
Spring4Shell background
This vulnerability in Tomcat allows the attacker to use Java / spring flexible configurations to gain access to the application using a web-based shell. In these vulnerable applications, the spring framework allows the attacker to set the values of specific class properties using HTTP requests.
As an example, the following request will change the value of the property ‘name’ of the main application class to ‘XXX’.
- GET /?name=XXX
Similarly, the following request enables the value of a different property in a different class to be changed
- GET /?class.<ANY CLASS>.<ANY PROPERTY>=<ANY VALUE>
What this attack does is to manipulate the properties of the tomcat Access logs to generate a new log file, which will be an executable web-based shell.
The infection payload includes three HTTP requests that make a set of changes to create a new URL with an interactive shell. This URL can now be used to run commands on the victim machine.
Attack steps
In this blog, we will show the following attack steps:
- Reconnaissance – Identifying the victim is vulnerable
- Infection – performing the Spring4Shell attack
- Controlling the machine and fetching data
Reconnaissance – Identifying whether the intended victim is vulnerable
During reconnaissance, the attacker will scan the network to find potentially vulnerable applications. The goal is to find vulnerable applications using HTTP.
The first step is to run a scan using nmap to reveal open ports related to the Spring4Shell vulnerability.
This detailed nmap scan returns the open ports and their respective protocols. In cases where the scan does not return the protocol that is used for each port, the adversary will try to directly access the port using a web browser. In this example, we use Chrome network tools to identify the HTTP headers.
To identify the Tomcat version, an adversary will then try to connect to the server using telnet. This triggers a server error that reveals the Tomcat version.
Infection – performing the Spring4Shell attack
Several organizations published Proof of Concepts (PoCs) for this vulnerability. For our research, we used the following PoC to infect our test host-
2022-03-30-spring-core-rce.mdx
The goal of the infection is to create a new file on the web application “shell.jsp”. This will be an interactive JSP page that accepts a command from the user, executes it, and sends the output back to the user.
For our research, the JSP file below, was written to accept a ‘cmd’ parameter sent to it, execute the ‘cmd’ parameter, and return the input to the user in an HTTP response.
The infection includes three HTTP requests. The first request enables the creation of a new log file, the second request prepares the fake log file with the content an attacker wants, and the third request writes the file, wrapping it with “<%” and “%>” so it can later be executed.
Note that the second request includes the path to the file (/webapps/ROOT/, the name of the file (shell) and the suffix (.jsp).
Controlling the Machine and Fetching Data
Now that the “shell.jsp” file has been planted, the attacker can use it to run commands on the victim.
It can be used to run some interesting commands. For each step, the command to execute will be the parameter that is passed to the shell.
- Verifying the machine was infected
First, the attacker would run a simple echo command to verify the machine was properly infected.
Command: echo “Hacked!”
URL path: /shell.jsp?cmd=echo%20”Hacked!”
- Checking the privileges that the application (and the attacker) has
The next command will be to check which user account was compromised and the associated privileges that were obtained on this victim machine.
Command: id
URL path: /shell.jsp?cmd=id
- Browsing the file system
There are two command types for browsing the file system – one to look for hidden files in the /etc/ directory, and the second will use the find command to look for documents throughout the file system.
Looking for hidden files in the /etc/ folder.
Command: ls -a /etc
URL: /shell.jsp?cmd=ls%20-a%20/etc
Finding documents throughout the file system.
Command: find / -name “*.doc”
URL: /shell.jsp?cmd=find%20/%20-name%20*.doc
- Gain access to AWS credentials
Finally, fetch the content of one of the interesting files that were found. In this case, the content of the AWS credentials files. When using AWS CLI, this file will include the AWS credentials in clear text.
Command: cat /root/.aws/credentials
URL: /shell.jsp?cmd=cat%20/root/.aws/credentials
The Decoy
The victim machine used here is a container-based decoy.
To build this specific Spring4Shell decoy, we used the dockerized vulnerable application created by LunaSec.
Upload the docker image to the Deception system to use it as a Decoy container. In Fidelis Deception® version 9.5 you can create such a decoy in minutes.
Let’s look at the alerts triggered by the decoy when the machine was infected, and the alerts triggered while the data was fetched.
Deception Alerts
Any access to a decoy is considered an actionable alert that should be prioritized and addressed immediately. That is because no one should interact with decoy assets for legitimate business reasons.
All alerts are grouped into a single conclusion that aggregates all activity from the attacker to the decoy. For the above attack scenarios, security teams will see alerts on the decoy across all attack phases – the reconnaissance, the infection, and the data fetching – when drilling down to the details.
The alerts on the reconnaissance and the infection phases are actionable to catch the attacker and quickly identify that an attack has occurred. The alerts on the data fetching phase will show valuable information on the attackers’ actions and intent once the system has been breached.
Alerts Associated with Infection Phase
Alerts Associated with Fetching Information
Be prepared for Attacks – Deploy Deception
As we have shown here, Fidelis Deception technologies are quite effective at quickly detecting zero-day threats and keeping cyber adversaries away from your data and assets. Deception technology from Fidelis Security makes protecting your environment easy. Deploy out-of-the-box decoys on-premises, in the cloud or on containers. Simply create your own golden image decoy on a RealOS decoy or as part of a container image.
It’s just that easy to shift to proactive cyber defense.
