A new zero-day remote code execution (RCE) vulnerability in the Spring Java Framework is drawing comparisons to Log4Shell, due to a widespread presence in Java applications and the relative ease with which it can be exploited.
As was the case with Log4Shell, the vulnerability can be mitigated by updating Spring Java Framework to a more recent version. However, that can be easier said than done due to its presence throughout a variety of Java applications.
Spring Java Framework Vulnerability can be exploited without user interaction
Spring Java Framework is part of JDK9+, and the RCE vulnerability can be exploited by simply sending a crafted HTTP request to a target system. Updating Spring Java Framework puts an end to this zero-day, but as with Log4Shell this is not necessarily the easiest task as there is not a central way to push the update to all instances in the wild. Older and no longer supported Spring Java Framework versions may not be able to upgrade, in which case the developers suggest either upgrading to Apache Tomcat or downgrading to Java 8 if that cannot be done.
There is no word yet that threat actors discovered the RCE vulnerability; it was discovered by security researchers, and Spring Java Framework VMWare says that they had not seen any zero-day chatter about it prior to disclosing it. It was disclosed due to the potential severity and the availability of patches, after a Chinese security researcher leaked it to the web for several hours and other researchers were able to reverse engineer what they posted. As with Log4Shell it will be up to individual IT teams to be diligent about locating instances and applying updates throughout their networks.
While the RCE vulnerability can be exploited without user interaction via an HTTP POST request, this approach apparently only works with certain configurations. Other configurations require the attacker to do additional research on the target system and tailor the payload appropriately. Exploitation of the zero-day appears to require an endpoint with DataBinder enabled and can potentially be thwarted by the servlet container for the application.
While some are referring to it as “Spring4Shell” due to the similarities, this particular zero-day is tougher to reliably pull off due to a longer list of particular circumstances and elements needing to be in place. However, unpatched target systems that meet these criteria can be relatively easily compromised and attackers can craft scripts to scan the internet for vulnerable systems, leading to some debate over whether the CVSS score is high enough.
As John Bambenek, Principal Threat Hunter at Netenrich, notes: “With a PoC for this vulnerability in the open … it could be bad. What made Log4j such a problem is that it is often installed on appliances and other ‘headless’ devices that are not maintained by the end customer. It is unclear how true this will be for Spring, but any RCE issue should go straight to the top of the pile for security teams to address.”
Zero-day RCE vulnerability allows full access to attackers
The issue is also serious as an attacker that manages to exploit the RCE vulnerability would have full remote access to the target system, able to execute commands and potentially deploy ransomware or exfiltrate documents and emails.
In addition to seemingly not being able to decide on calling it “SpringShell” or “Spring4Shell,” security researchers were also not initially sure that this was actually a zero-day as it looked as if it might be connected to prior known issues with Spring Java Framework. The RCE vulnerability was eventually determined to be something entirely new, however, and it was tagged with the identifier CVE-2022-22965.
Exploitation attempts had not yet been observed in the wild as of the end of March, but they are almost certainly forthcoming as cyber criminals scan for unpatched systems. It does not appear to have the raw system count that Log4Shell does (due to the more narrow list of added requirements for it to be exploitable), but is nevertheless a critical and “instant” RCE vulnerability and could cause just as much damage to those that are compromised by it. Estimates put the amount of Spring Java Framework developers in the millions, and it could be in use in as many as 74% of Java applications.
Cybersecurity firm Flashpoint has analyzed the zero-day and says that while it bears strong surface similarities to Log4Shell, it is not the “second coming” of that devastating vulnerability and is not comparable at a “deeper level.” Flashpoint believes that most exploitable instances in the wild will take some amount of probing and a higher skill level from attackers, giving security teams more time and opportunity for warning. Also, while Spring Java Framework may touch nearly three-quarters of Java applications the actual list of apps that meet all the requirements to be exploitable is likely a great deal smaller than that. By contrast, the vast majority of organizations were thought to have Log4Shell openings lurking around somewhere or another in their environment.
Jonathan Knudsen, senior software strategist for Synopsys Software Integrity Group, also notes that there is a separate Spring-related vulnerability that should not be confused with “Spring4Shell”.
“The Internet is buzzing with talk about two separate vulnerabilities related to different Spring projects. The two are not related, but have been confused because both vulnerabilities were disclosed at nearly the same time,” says Knudsen.
“The first is CVE-2022-22963, tracked in the Black Duck Knowledgebase as BDSA-2022-0850. This is a remote code execution vulnerability in Spring Cloud Function. Issued with a medium severity by vendor, researchers have since found that achieving remote code execution is possible. An upgrade patch already exists, so affected users are urged to upgrade as soon as possible.
“Regardless of how Spring4Shell evolves, these two vulnerabilities highlight the importance of knowing what open source components you are using and keeping on top of vulnerabilities as they are disclosed.”
