Spring4Shell Exploitation Can Fully Compromise a Host, but Is It as Dangerous as Log4Shell?

essidsolutions

Spring4Shell is a critical remote code execution vulnerability that can potentially enable a threat actor to execute arbitrary code leading to complete compromise of the vulnerable host or container. Tracked CVE-2022-22965, the vulnerability exists in the Spring Framework for enterprise Java applications. But like Log4Shell flaws, is Spring4Shell as devastating?

Two new security vulnerabilities have been making the rounds since they were discovered earlier this week. One of the vulnerabilities, dubbed Spring4Shell, is important enough to have drawn parallels to the widespread Log4shell vulnerabilities that Akamai CTO Charlie Gero saidOpens a new window : “will likely be with us not only for several months but potentially for years.”

And if that’s not enough, a Chinese security researcher jumped the gun and prematurely leaked details of this more severe vulnerability of the two, even before the developer of the vulnerable Spring Framework could release patches.

Spring is a popular framework used in ~70%Opens a new window of all enterprise-class applications based on Java. It is an open-source framework leveraged for J2EE development that eases inversion of control and dependency injection. In simpler words, it allows seamless testing, production, and maintenance while ensuring the different components of an application, such as classes, run as a cohesive unit while keeping them independent of each other.

On Tuesday, the vulnerability was reportedOpens a new window by codeplutos, meizjm3i of AntGroup FG to VMware, who owns Spring. However, Spring’s intention to quietly release an emergency fix on Thursday was foiled when the exploit details leaked, thus endangering thousands of organizations.

The exploit was leaked on a Chinese cybersecurity site and on Twitter (now deleted) and circulated on the QQ instant messaging service. Researchers confirmed that the exploit is real, a signal that threat actors may very well be keen on exploiting this vulnerability.

A Java Springcore RCE 0day exploit has been leaked. It was leaked by a Chinese security researcher who, since sharing and/or leaking it, has deleted their Twitter account.

We have not verified the exploit.

tl;dr big if true

Download the 0day POC here:

— vx-underground (@vxunderground) March 30, 2022Opens a new window

Aside from vx-underground, security teams at Rapid7, Synopsys, Cybereason, Cloudflare, LunaSec, Sysdig, Qualys, Tenable, Snyk, Salt Security, other companies, and scores of independent researchers also confirmed the threat posed by Spring4Shell.

Tracked as CVE-2022-22965, the Spring4Shell flaw enables remote code execution (RCE), which allows attackers to execute arbitrary code on the machine and compromise the entire host. It resides in the Spring Core module of the Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older ones.

The exploit also necessitates using JDK version 9 or later, which runs with spring-webmvc or spring-webflux dependency. Meanwhile, the Servlet container needs to be Apache Tomcat.

“Exploitation of Spring4Shell will allow an attacker to remotely execute arbitrary code on the target server, usually with equivalent permissions to the vulnerable web server itself,” explainedOpens a new window Yaniv Balmas, VP of research at Salt Security. “A successful attack might allow a user to access all website internal data, including possible access to any connected database. It may also allow an attacker to access additional internal resources to gain more permissions or to pivot to other parts of the internal network.”

CVE-2022-22965 or Spring4Shell actually exists because of a partially patched RCE vulnerability CVE-2010-1622 from 2010 in Spring Core, as discovered by PraetorianOpens a new window . While it hasn’t been assigned a CVSS score, organizations must take it seriously, considering Spring4Shell is being actively exploited in the wild, as attested byOpens a new window Unit 42 of Palo Alto Networks.

David Lindner, CISO at Contrast Security, said that since Java 9 was released in July of 2017, Spring4Shell has been exploitable in production apps and APIs for five years. Lindner told Toolbox, “The Contrast Labs team has proven the exploit due to how a Spring application handles binding, and we believe it could have a larger impact than Log4j.”

After some assessments, however, security researchers believe that the impact may not be as severe as initially thought.

See More: Dirty Pipe Flaw in Linux Kernel Lets Hackers Overwrite Root Files, Escalate Privileges

“In certain configurations, exploitation of this issue is straightforward, as it only requires an attacker to send a crafted HTTP request to a vulnerable system. However, exploitation of different configurations will require the attacker to do additional research to find payloads that will be effective,” wrote Anthony Weems and Dallas Kaman, both principal security engineers at Praetorian.

InfoSec researcher Kevin Beaumont explained that exploitation necessarily requires the vulnerable code.

The leaked PoC for this one does not work on an out of the box install. It relies on essentially introducing a vulnerability.

So far this continues to look like a vulnerability hype train without a real world risk.

— Kevin Beaumont (@GossiTheDog) March 30, 2022Opens a new window

Other researchers, including Chris PartridgeOpens a new window , researchers at Flashpoint, etc., also echoed the same.

“Although the ‘Spring4Shell’ name variation has gotten more traction in the media, we encourage others not to use it. The ‘4′ is strictly arbitrary, being used to reference the Log4Shell vulnerability, which derived its name from the Log4j library. Additionally, Spring4Shell implies that this issue is as severe as Log4Shell and current information does not support this,” Flashpoint clarified.

This essentially raises the question: why was CVE-2022-22965 named Spring4Shell in the first place? Travis Biehn, a principal security consultant at Synopsys, told Toolbox, “Spring4Shell is what happens when responsible disclosure processes aren’t followed – the lack of immediate and fully vetted credible information in a sea of strong personalities makes an already hard job seem impossible.”

Nevertheless, a patch for the vulnerability is available now in Spring Core Framework versions 5.3.18 and 5.2.20. If organizations cannot update, Lindner’s advice to their Java developers is “to specifically set the allowed fields property or properly set the disallowed fields for the known malicious attack patterns within the DataBinder class.”

Technical details of this temporary workaround are available here on the Spring4Shell advisory page.

Sam Curry, the chief security officer at Cybereason, told Toolbox to sit tight and wait for more details. But do proceed to patch up vulnerable systems. Curry said:

“With some early reports surfacing that Spring4Shell is significantly different from Log4j, we’ll know more as an industry soon enough on its severity and risk level. Regardless of what level of severity Spring4Shell poses, the recent Log4j vulnerability was the tip of the iceberg as we’re now seeing the looming shape and outline of what is below the waterline.

More embedded system weaknesses are lurking out there. Sadly, we live in an age where adversaries have the skills to quickly exploit these vulnerabilities. Now the call is out for Defenders to adapt, innovate faster and thrive. Spring4 Shell is another wake-up call, but there will be more vulnerabilities coming next month and beyond. As security practitioners, we need to collectively work on new ways of managing supply chain risk.”

Just before Spring4Shell exploit was leaked, Spring also notified about CVE-2022-22963, an RCE vulnerability existing in Spring Cloud Function versions 3.1.6, 3.2.2 and older unsupported versions. It has a CVSS score of 9.8. Because of the premature leak, CVE-2022-22963 was initially confused with Spring4Shell (CVE-2022-22965Opens a new window ).

CVE-2022-22963 has been fixed in Spring Cloud Function versions 3.1.7, 3.2.3.

Let us know if you enjoyed reading this news on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We would love to hear from you!

MORE ON SECURITY VULNERABILITIES