Arad Inbar is a security researcher at Fidelis Cybersecurity, specializing in Deception. He has been analyzing network traffic & malware for over 5 years.
... Read More
April 27, 2022
Spring Ahead of Adversaries
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 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 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 easy 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.
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’.
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.
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.
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.
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
Finding documents throughout the file system.
Command: find / -name “*.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
The victim machine used here is a container-based decoy.
Let’s look at the alerts triggered by the decoy when the machine was infected, and the alerts triggered while the data was fetched.
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:
Alert 1 – Infection phase – first HTTP Request
Alert 2 – Infection phase – second HTTP Request
Alert 3 – Infection phase – third HTTP Request
Alerts Associated with Fetching Information:
Alert 4 – Data fetching – sending the echo command using an HTTP request
Alert 5 – Data fetching – dumping the credentials file text using an HTTP request
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 Cybersecurity 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.
See Fidelis platforms in action. Learn how our fast, scalable Fidelis Elevate and Fidelis CloudPassage Halo platforms provide deep insights into the SOC to help security teams worldwide protect, detect, respond, and neutralize even the most advanced cyber adversaries.