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 aka Spring4Shell.
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:
Source: Twitter https://twitter.com/ankit_anubhav/status/1509383534456172546/photo/1

Source: Twitter

It goes like this


Let us take one step back and explain the attack flow as simple as possible:

  1. The adversary alters logging facility configuration in a web server to create a new .JSP file
  2. Now, the adversary writes arbitrary code into the .JSP file, Web Shell creation
  3. 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:


Countermeasures


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.
Happy Hunting…

By: Mato Vlajčić, Senior SOC analyst @ Infigo IS

Additional info:
Help Net Security on Spring4Shell
LunaSec Spring4Shell security analysis
< Back to insights