One month in: CyCognito looks at Spring4Shell

It’s likely by now that you are aware of Spring4Shell, a vulnerability in the Spring framework that permits remote code execution (RCE) and was publicly disclosed on March 30th, 2022. 

NIST assigned Spring4Shell a score of 9.8, presumably out of concern of a similar blast radius to Log4Shell, which was trivial to exploit and very common. With 6 out of 10 Java developers reporting using the Spring framework (Snyk research, 2020), this vulnerability jumped quickly to the headlines. 

On the outside this appears to be a nightmare; a critical RCE on a widely used web application framework in a current version. 

But is it?

[For more information on Spring4Shell, please see our April 6th blog post]

The importance of rapid visibility to risk

Time is of the essence when any vulnerability is disclosed but is especially important with critical severity vulnerabilities like Spring4Shell. Response windows are tight – the majority of CVEs start to be exploited within hours or days of disclosure, according to the Cybersecurity & Infrastructure Security Agency (CISA):

“…threat actors are extremely fast to exploit their vulnerabilities of choice: of those 4% of known exploited CVEs, 42% are being used on day 0 of disclosure; 50% within 2 days; and 75% within 28 days!”.

Unfortunately this is a catch-22 scenario for many security teams. They understand the importance of rapid response but without visibility into their entire attack surface they can’t understand vulnerability relevance. The act of response is necessary to quantify the risk to their organization. This equates to a constant fire drill for many IT security teams, contributing to uncertain prioritization and resource burnout.

Spring4Shell data from CyCognito research

CyCognito began tracking Spring4Shell (CVE-2022-22965) immediately after disclosure. We examined attack surface scan results and quantified the number of customer assets using the Spring framework. We then cross referenced the assets running Spring with version and system information to understand the number vulnerable to the Spring4Shell exploit.

Our results? Out of nearly 4,000 assets discovered running Spring, less than 1% were vulnerable to the Spring4Shell exploit. This was great news for our customers – with this information they were able to quickly understand external risk posture and communicate it across all levels of their organization. 

We were initially surprised at this result considering the number of assets CyCognito monitors across many industries; software development, manufacturing, telecommunications, energy, and more. As a data company, the “why” is as important as the “what”, and with that in mind we determined multiple explanations that may occur to an outsider:

• CyCognito customers respond more efficiently to emergency patches (mature playbooks, etc.)
• Sample size targeted the wrong demographic or was not large enough
• CyCognito testing had errors
• Spring4Shell exploitable systems are rare

While some CyCognito customers will naturally respond more efficiently to emergency patches than others, it’s not likely across our entire sample set. Same response regarding the wrong demographic and size; possible but not likely. Now, regarding CyCognito testing, error is not possible with multiple verification passes, both human and automated.

Our conclusion is that the fourth option, exploitable systems are rare, is the reality. A review of NIST description for Spring4Shell provides some color to the moon alignment that must happen for a system to be exploitable:

“A Spring MVC or Spring WebFlux application running on JDK 9+ may be vulnerable to remote code execution (RCE) via data binding. The specific exploit requires the application to run on Tomcat as a WAR deployment. If the application is deployed as a Spring Boot executable jar, i.e. the default, it is not vulnerable to the exploit.”

A recent update to a Microsoft Spring4Shell blog reports Microsoft has also observed a low volume of exploit attempts for these vulnerabilities across their cloud services.

Why is this conclusion important? Let’s compare Log4Shell and Spring4Shell next.

Log4Shell and Spring4Shell 

Log4Shell is a vulnerability in the Apache Log4j framework that permits arbitrary code execution. Hundreds of millions of systems use log4j as a means to interact with adjacent systems and the vulnerability enabled a jump off point to access internal data.

Spring4Shell is a vulnerability in a programming and configuration framework for developing Java applications. Most of the systems using Spring framework are internal corporate apps that cannot be scanned or accessed from the “outside world” – so the % of affected assets may be higher, but the chance of actually exploiting those internal apps from an external access point, is much lower.

Understand your attack surface and prioritize patching with CyCognito

CyCognito is not saying that Spring4Shell is trivial or ignorable. But we are saying that this is an example of how exploit intelligence, which ties vulnerability, exploitability and accessibility, is essential for accurate and timely visibility into external risk management.

In many instances critical vulnerabilities may be of lower urgency for your organization than what is reported for the industry. As reported by CISA “…many vulnerabilities classified as “critical” are highly complex and have never been seen exploited in the wild – in fact, only 4% of the total number of CVEs have been publicly exploited.”

When information is sparse, organizations that are highly risk-averse must treat all threats as top priority. Armed with accurate and comprehensive information on exposure and risk, organizations can focus on what is truly critical for the security of their infrastructure.

---

CyCognito allows customers to discover exposure, address security gaps timely, and operate efficiently. To learn more about CyCognito’s approach to attack surface management or if you have questions about this blog, please contact your CyCognito account representative.