Spring4Shell – it is not a big deal, but...
On March 30th, 2022, the leader of the KnownSec 404 team has announced, via Twitter, that his team found a Remote Code Execution (RCE) in the Spring Core framework. In the wild, there are a few similar RCEs in Spring, but we will focus only on CVE-2022-22965
As of writing this, there are a few requirements that have to happen for hackers to be able to exploit the vulnerability:
- Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older packaged as a traditional WAR and deployed in a standalone Tomcat instance
- JDK 9 or higher version
- Apache Tomcat
- Non-default form binding (name=value pairs) configuration in Spring
When Spring gets a web request it will translate headers from the HTTP protocol into domain objects. In the process of creating and preparing those objects for a developer context, its protection mechanisms should take care of mitigating the ability that an attacker could control these objects. Since Java 9 has brought changes related to objects, protection mechanisms utilized by Spring were not sufficient.
Graphical representation of CVE-2022-22965:
It goes like this
Let us take one step back and explain the attack flow as simple as possible:
- The adversary alters logging facility configuration in a web server to create a new .JSP file
- Now, the adversary writes arbitrary code into the .JSP file, Web Shell creation
- The adversary executes commands, invokes Web Shell
For this trivial exercise, we have downloaded the pcap file from Didier Stevens' blog
just because of its simplicity.
The first two steps of the attack flow are shown at a packet level analysis:
We can see the HTTP Post request with a specifically crafted payload in the body of the HTTP protocol because the Content type is "application/x-www-form-urlencoded"; in HTTP logs we will see one giant query string
which means if we correctly parse the URI field, then we have a detection opportunity.
Do not confuse this exploit with Log4Shell exploit, because Log4Shell can leverage almost any field in HTTP protocol for exploitation purposes; on the other hand, Spring4Shell does not use explicitly any field, the URI value here is just a result of using mentioned Content Type.
If the server returns "200 OK", it probably means that our server is vulnerable and a web shell is dropped:
Be aware that other Status Codes like "400" and "302" might also mean that the web shell is successfully dropped.
The third step is all about using Web Shell, we can see the (in)famous "whoami" as the invoked command:
Next, we have a response from the server, returning the value of "whoami" command:
Except traditional, and let's say boring suggestions about system patching (please read the official Spring Blog
for more details), we want to emphasize some other prevention and detection opportunities.
On the prevention side we should:
- Put our web servers behind a Web Application Firewall (WAF) and enforce regularly updated IPS signatures against web traffic
- On the perimeter firewall, we can easily turn on Inbound SSL decryption and then enforce regularly updated IPS signatures against web traffic
If we have some sort of centralized logging, we could:
- Look for strings in HTTP POST request from packet level analysis such as "*InputStream*,*getParameter*,*getRuntime*,*.class*,*.Class*" but be aware that if we create a SIEM rule based only on that, we will get some false positives, since it’s not high fidelity rule. Anyway, if we combine this rule with some sort of file monitoring mechanism, specifically if we are able to detect mentioned strings followed by a new .JSP file creation, we will get some good results. And they can be even better if we further combine this with duration and amount of communication to a single IP, then we have a high-fidelity rule. Think about web shell behavior when designing a rule logic
- From packet level analysis where "whoami" has been invoked, we can see that server sent a lot more bytes in response compared with the GET request; maybe there is a chance to pull these statistics for a longer time periods to see if there are some anomalies that will lead us to web shells
- Investigate events from IPS-like devices (perimeter boxes)
As always enforcing good security practices, in general, is a way to go.
By: Mato Vlajčić
, Senior SOC analyst @ Infigo IS
Additional info:Help Net Security
Spring4Shell security analysis