When a significant vulnerability like Spring4Shell is discovered, how do you determine if you are at risk? Insurance or verification services might require you to run external tests on web properties. These reports often show spurious exposures that may or may not lead to more issues on your website. You 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 you have a pen test or vulnerability scan, know that you can disagree with the findings and explain to the researcher how the item in question is not making you 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, always review what resources you have to put something between you 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 your 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, review if you have the have the vulnerable code in your systems. You 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 you do not have your own internal discussion groups to flesh out the facts of the vulnerability, you can learn the nuances and more information in such sites as Reddit and security blogs. They often they bring up additional questions or even workarounds that you and your team members may not have thought of. If you have external security resources, reach out to auditors and pentesters and get their advice and resources.
Bottom line: Take Spring4Shell seriously but assign resources appropriately. Don’t get caught up in a headline when you may not be at risk.
Copyright © 2022 IDG Communications, Inc.
