Numerous vulnerabilities have been found this week in Spring, a popular Java Web app development framework from VMware. Detectify Surface Monitoring and Application Scanning customers are already scanning payload-based modules for CVE-2022-22965: Spring4Shell RCE and CVE-2022-22963: Spring Cloud Function RCE.
Our security researchers, engineers, and our Crowdsource community are actively working on understanding the vulnerabilities and developing tests. We have received a dozen POCs already and anticipate more over the coming days. While the situation is rapidly developing, here is what we know so far.
The Spring Cloud Function vulnerability (CVE-2022-22963) was disclosed and patched earlier this week. Detectify released testing for this vulnerability on Wednesday, March 30th for our Surface Monitoring customers and on April 1st for Application Scanning customers.
The Spring Framework RCE via Data Binding on JDK 9+ – aka Spring4Shell – (CVE-2022-22965) is a 0-day vulnerability. It was disclosed on March 31st and modules were released for scanning on Detectify’s Surface Monitoring on the same day. Tests for this vulnerability on Application Scanning were released on April 1st.
How does Spring4Shell compare to Log4Shell (CVE-2021-44228)?
In the last week, four CVEs have been disclosed by Spring. The two that Detectify is already scanning for are both critical vulnerabilities, while the other two are classified as medium severity vulnerabilities. There are media reports that the threats are already being exploited in the wild.
The impact of the Spring RCE and Spring Cloud Function vulnerabilities could be as bad as that of Log4Shell, as it allows an attacker to execute arbitrary code on the server hosting the Spring application. It is possible to detect vulnerable servers remotely over the Internet, but to get the best coverage we would recommend both assessing the source code and doing a black box analysis using Detectify.
Spring documentation for RCE DataBinder said: “[T]here are potential security implications in failing to set an array of allowed fields. In the case of HTTP form POST data for example, malicious clients can attempt to subvert an application by supplying values for fields or properties that do not exist on the form. In some cases, this could lead to illegal data being set on command objects or their nested objects. For this reason, it is highly recommended to specify the allowed fields property on the DataBinder.”
How do we test for vulnerabilities?
Detectify Surface Monitoring sends payloads to request headers and URLs (in some cases, query parameters too). When we send a payload and observe something trying to resolve on a domain, we produce a vulnerability finding.
In Application Scanning, customers have access to all of the above and more. Detectify scanning engines crawl customer applications followed by extensive fuzzing of all parameters, such as cookies, and query parameters. We also send payloads in certain events, such as an error. If we receive a DNS pingback, a vulnerability finding is triggered.
We will continue to release new modules as soon as they are ready. Customers can always find updates in the “What’s New” area of the platform. Any questions can be directed to Customer Success representatives or Support.
If you’re a Detectify customer, we highly recommend scanning all critical assets as soon as you can. If you’re not already a customer, click here to sign up for a free trial and immediately start scanning. Go hack yourself!