Spring4Shell: Assessing the risk | CSO Online

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.