Two RCEs exist and three vectors are being discussed online (one of which is not known to be remotely exploitable):
Spring4Shell is a bypass of an old code injection vulnerability in the Spring Core Framework. (CVE-2010-1622).
A Spring MVC or Spring WebFlux application running on JDK 9+ may be vulnerable to remote code execution (RCE) via data binding. The specific exploit requires the application to run on Tomcat as a WAR deployment. If the application is deployed as a Spring Boot executable jar, i.e. the default, it is not vulnerable to the exploit. However, the nature of the vulnerability is more general, and there may be other ways to exploit it.
These are the requirements for the exploit:
However, the nature of the vulnerability is more general, and there may be other ways to exploit it that have not been reported yet.
Given the broad use of Apache Tomcat by developers, this remote code execution vulnerability has a huge potential impact.
In certain configurations, exploitation of this issue is straightforward, as it only requires an attacker to send a crafted HTTP request to a vulnerable system. However, exploitation of different configurations will require the attacker to do additional research to find payloads that will be effective,” the Praetorian researchers noted.”
“Exploitation requires an endpoint with DataBinder enabled (e.g. a POST request that decodes data from the request body automatically) and depends heavily on the servlet container for the application. For example, when Spring is deployed to Apache Tomcat, the WebAppClassLoader is accessible, which allows an attacker to call getters and setters to ultimately write a malicious JSP file to disk. However, if Spring is deployed using the Embedded Tomcat Servlet Container the classloader is a LaunchedURLClassLoader which has limited access.
The vulnerability, dubbed SpringShell or Spring4Shell by cyber security analysts, has drawn inevitable comparisons with Log4Shell, a zero-day vulnerability in the popular Log4J java tool which caused widespread problems when it was discovered in December. Experts however do say that Spring4Shell is more difficult to exploit, but still has the potential to cause widespread damage.
Software developers online have started to call the vulnerability Spring4Shell, after Log4Shell. This is because of the popularity of the Spring Core Framework. However, there are some differences as Log4J is bundled up and included as a part of an application whereas the Spring Framework is a commercial product.
We have already released the detection script for identifying the Spring framework installed on Linux machines, keep in mind that authenticated scan is required for it.
In addition, we're are currently working on the vulnerability test which is currently on schedule to be released today. You can therefore expect that within the next 24Hrs all our scanner appliances and external scanning nodes will be updated to support this.
At the same time, we have already prepared a lab with the vulnerable Spring4Shell application running and are currently researching exploitation methods that will be able to be used for active vulnerability tests.
We will keep you updated as additional information becomes available.
Update 2022-04-01 16:46 Detection script and Vulnerability tests for Spring4Shell have been pushed out and will be available for scans tomorrow (2nd of April).
Detection scripts for Spring Framework (SSH and HTTP based) and a vulnerability test covering CVE-2022-22965.
HID-2-1-347323 VMware Spring Framework Detection (HTTP)
HID-2-1-347321 VMware Spring Framework (Core) Detection (Linux/Unix SSH Login)
HID-2-1-347320 VMware Spring Framework (Core) Detection Consolidation
HID-2-1-347322 VMware Spring Framework (Core) RCE Vulnerability (Spring4Shell, SpringShell) - Version Check