April begins strong with the discovery of a 9.8 RCE (Remote Code Execution) new vulnerability without any prior authentication in the Java Spring opensource framework.
Context of the Spring4Shell attack
After the Java Log4j library, a Zero-Day vulnerability in the Java Spring framework was identified and fixed on 31 March. But it appears that it is already being actively exploited, and the code enabling it is also publicly available.
This framework is widely used for web application development and its inclusion in a large number of software packages portends the same nightmare as Log4shell for the developer community.
Vulnerability technical details
The vulnerability is present in the getCachedIntrospectionResults function which exposes the whole class of the object when associating the parameters. The mechanism for associating HTTP requests to objects in the application is therefore impacted. This means that the user can forge an HTTP request (via the URL) in order to get the details of the object class in return.
This type of exposure can be used to load malicious code in return that will dynamically modify the class or even execute code. Typically, in the observed case it is about loading a webshell that will give the remote user the total control of the machine, with the execution rights of the Java machine (often root).
In order to understand the origin of the vulnerability, we have to go back to the comment around a potentially dangerous function exposed by the Spring framework warning the developer of a security risk.
Figure 1: ticket gh-28075 comments
This is the triggering event of several vulnerability searches conducted on this mechanism of the Spring framework that quickly led to the discovery of the CVE that interests us here, Spring4Shell.
However, Spring4Shell is only a workaround of an old vulnerability, the CVE-2010-1622, impacting the constructor of the CachedIntrospectionResults class which has already been patched.
Figure 2: 2 july 2010 CVE-2010-1622 patch of framework Spring v2.5
Figure 3: 31 march CVE-2022-22965 patch of framework Spring v5.3
Impacted software and versions
Proofs of concept have been observed on the following software and SDKs:
- JDK 9 and higher,
- Apache Tomcat Servlet as a container,
- Spring-webmvc and spring-webflux dependencies,
- The Spring framework in versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions,
- Any Java application using the Spring Beans package.
IoCs
We have found the following IPs trying to exploit the vulnerability:
- 37.120.203.76
- 38.83.79.203
- 45.155.204.146
- 89.248.165.72
- 100.26.40.121
- 103.27.108.196
- 103.214.146.5
- 112.5.154.7
- 116.204.211.22
- 120.36.97.210
- 149.28.147.15
- 154.6.19.197
- 158.247.202.6
- 172.93.189.42
Stormshield products protections
Stormshield Network Security
An IPS signature has been published on SNS, allowing to detect and block attempts to manipulate the "classLoader" class from an HTTP POST request. This works by analyzing the HTTP traffic, which must be in clear text when inspected. If the flow is encrypted, the SSL proxy must be activated (outgoing flow), or else decryption must be done on another upstream device (incoming flow). This signature is:
http:client:data.163 → Spring4Shell RCE attempt on HTTP POST request (CVE-2022-22925)
All IoC’s listed in this article have been added to our IP Reputation.
Stormshield protection confidence index |
Stormshield confidence index of no false positives |
Stormshield Endpoint Security
The different versions of SES (7.2 and Evolution) being desktop and server protection solutions, they will not block the exploitation of this vulnerability directly. However, they will be able to prevent the payload from executing correctly and thus avoid any impact. The blocking will depend on the payload used.
Whatever your version of SES (7.2 or Evolution), it is nevertheless possible to add an audit rule for the creation of *.jsp files in the folders of the server that may be vulnerable to Spring4Shell. This will allow you to be alerted very quickly if an attacker would drop a file containing Java code via this attack.
Recommendation
We recommend to update Spring Framework to version 5.2.20 or 5.3.18.
