Credit: Dreamstime
When a significant vulnerability like Spring4Shell is discovered, how do customers determine if they are at risk? Insurance or verification services might require users to run external tests on web properties.
These reports often show spurious exposures that may or may not lead to more issues on a website. Users must research false-positive reports and inform management whether the item found is acceptable risk.
I’ve seen false positives on external scans due to an open port and associating that port with a known issue even if the service is not run on that port. Whenever users have a pen test or vulnerability scan, know that they can disagree with the findings and explain to the researcher how the item in question is not making them insecure.
However, these processes take time away from other security duties, and sometimes we agree with the findings and find workarounds and mitigations as that may be faster than arguing with the auditor.
Is Spring4Shell a real risk?
Case in point: Spring4Shell appeared to initially be of grave concern, but I’ve not seen much on it having a significant impact. Microsoft has included additional protection to its Azure web application firewall for Spring4Shell exploits CVE-2022-22963, CVE-2022-22965 and CVE-2022-22947.
When I want to assess the impact of a vulnerability, I either reach out to others I trust to make security decisions or review the information that is reported on the issue. In this case the headlines appear to be more hype than actual risk.
Here’s what Microsoft said about Spring4Shell:
“On March 31, 2022, vulnerabilities in the Spring Framework for Java were publicly disclosed. Microsoft is currently assessing the impact associated with these vulnerabilities. This blog is for customers looking for protection against exploitation and ways to detect vulnerable installations on their network of the critical remote code execution (RCE) vulnerability CVE-2022-22965 (also known as SpringShell or Spring4Shell).
… “The Spring Framework is the most widely used lightweight open-source framework for Java. In Java Development Kit (JDK) version 9.0 or later, a remote attacker can obtain an AccessLogValve object through the framework’s parameter binding feature and use malicious field values to trigger the pipeline mechanism and write to a file in an arbitrary path, if certain conditions are met.”
Therein lies the problem: These certain conditions appear to be so unusual that I’m not seeing many actual exploits. Statements from researchers such as Will Dormann suggest this may not be as big of a deal as the headlines make it out to be.
As he notes, a few affected applications on the web are by default impacted, including Red Hat JBoss Fuse 7. While it does have the vulnerable Spring library, the public exploit code out on the web does not work on it.
Trend Micro has reported that Spring4Shell has been used in targeted attacks in Singapore to allow attackers to then use the Mirai botnet malware on systems. It’s unclear if there is code unique to these web servers in Singapore or if this is merely a test for a wider attack.
Best overall response to new vulnerabilities
What’s a security team to do? Panic and patch without testing? Rip out the potentially impacted software? First, customers must always review what resources they have to put something between them and the internet. Even for web-facing assets, every device or resource should have something that filters or looks for patterns.
A web application firewall (WAF) in front of their assets, for example, will look for unusual patterns or strings. Most web application vendors can quickly add rulesets to WAFs to detect potential attacks or probes looking for vulnerable software.
Best response to the Spring4Shell risk
In the case of Spring4Shell, maintain a disallow or blocklist in the WAF to block strings that contain values such as "class.*", "Class.*", "*.class.*", and "*.Class.*"
Next, users can review if they have the have the vulnerable code in their systems. They may not be using the vulnerable versions of Java or the Tomcat server. Spring4Shell appears to impact the following configurations:
- Spring Framework versions before 5.2.20, 5.3.18, and Java Development Kit (JDK) version 9 or higher
- Apache Tomcat
- Spring-webmvc or spring-webflux dependency
- A Spring parameter binding that is configured to use a non-basic parameter type, such as Plain Old Java Objects (POJOs)
- Deployable, packaged as a web application archive (WAR)
- JAR based deployments
Finally, keep reviewing resources and information. If they do not have their own internal discussion groups to flesh out the facts of the vulnerability, they can learn the nuances and more information in such sites as Reddit and security blogs. They often bring up additional questions or even workarounds that they and their team members may not have thought of. If they have external security resources such as a managed security service provider (MSSP), they should reach out to auditors and pentesters and get their advice and resources.
Bottom line: Customers should take Spring4Shell seriously but assign resources appropriately. They should avoid getting caught up in a headline when they may not be at risk.
