Forum Discussion
Frequently Asked Questions about Spring4Shell Vulnerability
Frequently Asked Questions about Spring4Shell Vulnerability
On March 30, there were reports about Spring4Shell, a critical zero-day vulnerability in the Spring Core Framework, a programming and configuration model for Java-based enterprise applications. At the same time, news about a vulnerability in the Spring Cloud Function, identified as CVE-2022-22963, was also circulating. Unfortunately, these two flaws were conflated with one another, but they are not related.
The Tenable Security Response Team has published an FAQ blog post about Spring4Shell to consolidate some of the questions being asked about the flaw. At the time we published the blog and this community post, Spring4Shell did NOT have a CVE identifier associated with it nor are patches available.
For the most up-to-date information about Spring4Shell, including the availability of patches and Tenable product coverage, please visit our blog.
18 Replies
Any idea when a Plugin for this may be made available?
Hi Keith,
This morning updates were released by Spring and our teams are working on getting plugin content available as soon as possible. We will continue to update the blog with new information and links to the plugins as they become available.
Scott,
Should we expect the plugins to be purely version based checks (patched or not), or will they includes checks for the requirements?
- JDK 9 or higher
- Apache Tomcat as the Servlet container
- Packaged as WAR
- spring-webmvc
or
- spring-webflux
The difference obviously being version checks are simple but the requirements not so much :)
Are any of the Tenable products vulnerable to Spring4Shell? If so, what is the remediation plan? I understand that some of us operate air gapped systems and will need to download updates manually. Thank you.
Hi @Victor Wunschel,
We've updated the blog with a statement about this:
"Based on current information as of 4/1/2022 regarding CVE-2022-22965 and CVE-2022-22963, Tenable products are not affected."
Is there any plan for a scan policy to be developed similar to the log4shell polices? Or even a policy that combines the 2 since the required policy settings are similar for both log4shell and spring4shell? With paranoid and thorough setting requirement we find it difficult to use that in a policy with all plugins enabled as the number of false positives can be difficult to deal with.
Hi Bryan,
At the moment with only one Nessus plugin ID currently released there is not a scan template available. The team is working on and investigating additional checks at this time. As Paranoid and Thorough settings could impact a number of other plugins that may be enabled, we would recommend creating a scan policy using the Advanced Scan template, enabling both settings, and only enabling Plugin ID 159374. This would allow you to run a targeted scan with only this plugin and it's dependencies enabled.
Thank you for this information. Can I check something please - when I do as advised and create an advanced scan, disable all plugins and then just enable 159374, it does not automatically enable all dependant plugins. Is it supposed to? I've attempted to do it manually using the info on your website, but there are a lot and I lost track after 20 minutes of repeatedly clicking backwards and forwards.
Hello, thank you for this update. Do you know if the plugin requires credentials? Thank you.
For more information about the plugins/detections themselves, please refer to this community post in the Community Corner.
I am having the same issue...this is causing a great deal of issues with remediation plans and accurate reports.
Hi Aron and Christine,
To ensure that the team has all the information necessary to troubleshoot the issues with remediation scans, please open support cases with our support team. Thank you.
Hi @Satnam Narang , @Scott Caveza
We are getting lot of false positives based on Spring version, while the target host is not running JDK9+ or any other prerequisites are not qualified for being vulnerable but tenable is flagging it as vulnerable just based on the spring version which is misleading our investigation and remediation plan.
We can not rely on your product. Either you create reliable detection plugins or improve existing ones to include context for the exploit. Just checking the version and reporting it as vulnerable is not enough and justified. It's misleading.
I would suggest please review your plugins for Spring4Shell and do some context check as well if a host is genuinely vulnerable or not.
There is lot of extra fine tuning correction we are doing after getting tenable report, then what is the benefit of this tool. The version is simply can be detected by any other tool.
Hi Mohd,
We would recommend opening up a support case with our support team to ensure that the engineers working on the plugin development have the information necessary to troubleshoot this case. Additional plugin updates are to be expected as more information becomes available on conditions necessary to exploit this flaw.
