SPring4shell (CVE-2022-22963 & CVE-2022-22950) '0-day' vulnerability signatures not updated

[fabian_wuest]

@gabe_verrault

Is there any confirmation if Nexpose itself is vulnerable to this Spring4Shell vulnerability? Any updates planned for the Nexpose application itself?

@holly_wilsey

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.

Any update on this. I wonder if Nexpose itself is vulnerable?

Thanks!
Fabian

[naveen_c]

Hi Gabe, Holly & all,

Scan performed using “Spring4Shell CVE-2022-22965” check type, There were 54 vulnerable assets were identified. We were about to share the record with mitigation owner but recent scan did not identified any assets as vulnerable. i have performed the scan on all the servers but still its 0 vulnerable assets. Is something wrong with template. I have also enabled the “Enable Windows File System Search” option too. Need your assistance.

[holly_wilsey]

@fabian_wuest

Any update on this. I wonder if Nexpose itself is vulnerable?

We currently don’t have any updates on this, but since our teams are still actively working to respond to Spring4Shell, I can share here if there’s any updates or additional product guidance.

@naveen_c

Scan performed using “Spring4Shell CVE-2022-22965” check type, There were 54 vulnerable assets were identified. We were about to share the record with mitigation owner but recent scan did not identified any assets as vulnerable. i have performed the scan on all the servers but still its 0 vulnerable assets. Is something wrong with template. I have also enabled the “Enable Windows File System Search” option too. Need your assistance.

Were the 54 assets originally identified as vulerable with the authenticated check, or the remote check? We were seeing some false positives with the remote check, and so we released some updates to address those that could result in assets no longer being identified as vulnerable.

If you’ve used the authenticated check each time and are seeing differing results, I would recommend opening a Support case. That’ll allow our team to delve into your environment and examine these assets and scans more closely to see why that would occur.

You can open a case here: https://r7support.force.com/

[ChromeShavings (hpoff)]

@holly_wilsey , We’ve had a few printers that remote flagged as having this vulnerability last week, but they recently fell off this week… I’m assuming due to the vuln check being more polished?

Below is an example of a vuln proof based on an HP printer in our environment. Is your team aware that some printers will get flagged as having this vuln, even though they don’t have the Spring framework? Or maybe this has been corrected in a recent update?

• Running HTTP service
  HTTP GET request to http://PRINTERIP/?class.module.classLoader.URLs[-1]=0 (http://PRINTERIP/?class.module.classLoader.URLs[-1]=0)HTTP response code was an expected 500

[kevin_mccabe]

The logic of the remote check was updated to improve accuracy and reduce false positives. What you have seen is a direct result of the improved check.