Hi,
You might have heard about SPring4shell ‘0-day’ vulnerability. Currently there no related CV’s are updated in Insight VM.
Could you check how soon will it get updated and also can you make sure that we will be notified on any signature update in Insigh VM?
We need to identify vulnerable systems (if any) to avoid any mishap.
The 0-day now has a CVE number assigned as well, which should be added to the above list.
CVE-2022-22965: Spring Framework RCE via Data Binding on JDK 9+ | Security | VMware Tanzu
While we are waiting for some sort of vulnerability detection for InsightVM has anyone been able to confirm is configuring file search to look for .WAR files will work? Maybe not the best stop gap measure but at least it could provide some idea of systems that could be impacted.
This CVE is still not updated in R7, When it will get added?
My customer asked for this CVE like you.
I need Rapid7 take control it.
For up to date information, please check out the Rapid7 blog on the topic here https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/
This blog is getting regular updates, including information on checks. The next blog update will be at 11AM EDT.
Looks like all other VM solutions has already published plugin id/QID etc for the same vulnerability. Can someone suggest , how we can find the .WAR file into InsightVM until the CVE gets updated on InsightVM.
Is there anyway to configure at least the file search function in the scan template to detect .WAR file types on Window systems so we can at least get some idea of what systems may be impacted? This is a big issues at my organization this morning, particularly the lack of our ability to get a vulnerability scan for this item.
What I learned from log4j, Rapid7 cannot scan nested jar/war/zip files yet
We are doing a search of our environment using other tools to look for files that are spring*.jar and it seems that Rapid7 Nexpose uses Spring at least based on the file names we are seeing. Is there any confirmation if Nexpose itself is vulnerable to this Spring4Shell vulnerability? Any updates planned for the Nexpose application itself?
The files all appear to be in the C:\Program Files\rapid7\nexpose\shared\lib\managed or C:\Program Files\rapid7\nexpose.install4j\user directories
C:\Program Files\rapid7\nexpose.install4j\user
spring-security-core.jar
spring-security-extension.jar
C:\Program Files\rapid7\nexpose\shared\lib\managed
spring-aop-4.2.4.RELEASE.jar
spring-beans-4.2.4.RELEASE.jar
spring-context-4.2.4.RELEASE.jar
spring-context-support-4.2.4.RELEASE.jar
spring-core-4.2.4.RELEASE.jar
spring-data-commons-1.10.2.RELEASE.jar
spring-data-jpa-1.8.2.RELEASE.jar
spring-data-rest-core-2.3.2.RELEASE.jar
spring-data-rest-webmvc-2.3.2.RELEASE.jar
spring-expression-4.2.4.RELEASE.jar
spring-hateoas-0.18.0.RELEASE.jar
spring-hateoas-extension-2.2.0.1.jar
spring-integration-core-4.2.4.RELEASE.jar
spring-integration-jdbc-4.2.4.RELEASE.jar
spring-jdbc-4.2.4.RELEASE.jar
spring-jdbc-extension-2.2.0.1.jar
spring-messaging-4.2.4.RELEASE.jar
spring-mvc-extension-2.2.0.1.jar
spring-orm-4.2.4.RELEASE.jar
spring-oxm-4.2.4.RELEASE.jar
spring-plugin-core-1.2.0.RELEASE.jar
spring-plugin-metadata-1.2.0.RELEASE.jar
spring-rest-extension-2.2.0.1.jar
spring-retry-1.1.2.RELEASE.jar
spring-security-config-3.2.9.RELEASE.jar
spring-security-core-3.2.9.RELEASE.jar
spring-security-extension-2.2.0.1.jar
spring-security-saml2-core-1.0.3.RELEASE.jar
spring-security-web-3.2.9.RELEASE.jar
spring-tx-4.2.4.RELEASE.jar
spring-validation-extension-2.2.0.1.jar
spring-web-4.2.4.RELEASE.jar
spring-webmvc-4.2.4.RELEASE.jar
spring-xml-2.1.3.RELEASE.jar
Our teams are currently working on both remote and authenticated checks for InsightVM. We’re planning to push out the authenticated check in a content-only release this evening (April 1).
This is something we’re currently looking into, so we’ll be sure to share more info if there are any updates required for Nexpose/InsightVM. We’ve also been monitoring our own environment and have not detected any successful Spring4Shell exploit attempts.
One more thing to highlight from the blog post - If you use Container Security, then you should be able to assess containers that have been built with a vulnerable version of Spring. We currently can’t identify vulnerable JAR files embedded with WAR files, however.
How accurate is the remote check that was released? We have a number of Windows assets that nexpose is reporting as vulnerable but I can’t find any evidence that they are actually meet the criteria for being vulnerable and they aren’t being flagged by the authenticated check.
Because of the nature of this vulnerability and some detection limitations, the remote check is operating on a little more of a probability basis, rather than a 100% definitive yes or no. We send a payload to Spring-based web application paths in an attempt to trigger that HTTP 500 response, which can indicate a higher chance of exploitability, and so that will get reported as vulnerable.
The checks we’ve released for this vulnerability are also intended to be more conservative in nature. As the situation evolves and we learn more about it, we expect to uncover new weaknesses and new versions of the Spring Framework that are vulnerable. Right now, our checks may flag versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, as well as older 4.x versions.
The authenticated check that we’ve released is intended for use with Unix-like systems, and will report on vulnerable versions found in WAR files. We’re currently working on an authenticated check for Windows, along with improvements to the existing checks that were released with the content update on April 1.
And if anyone is looking for a step-by-step walkthrough on how to detect Spring4Shell, you can check out this guide here:
Holly,
Is it possible to just have a file check on Windows systems look for .WAR files in general? I’m thinking if I could at least get an idea of what systems have .WAR files on them it would at least give us systems to start investigating while waiting for an authenticated Windows check to become available?
I’m a tad confused by some of the results showing in the “proof” column. There are a lot of HTTP response code was 200(or 404) but expected 500, yet it still is showing vulnerable only because it is running HTTPS?
Edit: found 1 response out of the handful of other responses at the very bottom. Why list all the others?
I was confused by that too. Does that mean we just have to shut down that service? usually it gives a port on it. Is that the workaround?
I know in my case, a few Cisco ISE servers were flagged for a 500 response…so “likely” vulnerable. But when I go to the Cisco advisory page for ISE, it says confirmed to be not vulnerable. So false positives are entirely likely here on the first go round of checks (but still do our due diligence to double check it). I’m sure it will get better with each release.
Hi Holly,
What is the difference between using our default scan template and making the ones that you all suggest in the spring4shell (authenticated vs. non-authenticated) or is the difference that it only targets that one CVE for Spring4shell 2022-22965?
The team doesn’t currently have any recommendations around the use of WAR file checks in relation to this vulnerability, so I can’t guarantee that it’ll give you what you’re looking for. That said, file searches are a configurable option in scan templates, if you do want to go that route. If you go to the “File Searching” tab when configuring a scan template, you can see the option there to add custom file searches with a string that you input. We have more info on those custom searches here:
https://docs.rapid7.com/insightvm/configuring-file-searches-on-target-systems/
The template that we suggest on our Spring4Shell page targets CVE-2022-22965 so you can quickly detect that specific vuln across your environment. If you’d like to include it in your existing templates as part of a routine scan, that’s fine too. It just may take longer depending on your template and the other checks that you’re running.
We also have another update that I wanted to share 
A product release of InsightVM (version 6.6.135) is scheduled for today, April 6. This release will allow us to ship authenticated Windows fingerprinting support, which is the prerequisite for a vulnerability check. We then plan to release the new Windows check later in the week (ETA still pending on that one).
We’ve also noted the false positives that you’ve been seeing for the remote check and are planning on shipping some improvements to it in a content-only release today.
Another update here We had a content release on April 7 that included a new Windows authenticated check for Spring Framework. The previously mentioned product update (version 6.6.135) is required for this check, and you’ll have to set the “Enable Windows File System Search” option in the scan template to ensure it works properly.
We’re also looking to release an update to the Insight agent next week that will add support for the authenticated check for Linux and macOS. An update to support the Windows check will follow that.