A new critical zero-day vulnerability has been discovered in Spring, a popular open source framework widely used in modern Java applications. The issue could allow an attacker to execute arbitrary code on the vulnerable system. The vulnerability has been assigned CVE-2022-22965, and Spring has already released a patch.
The disclosure process for this issue has been somewhat chaotic so far. It was initially disclosed by a researcher on GitHub and Twitter before being removed. Then it was picked up by a security news site Cyber Kendra as an unconfirmed vulnerability. Confusing matters, another, patched (CVE-2022-22963) issue in Spring was also discussed on that site.
Subsequent work across the security industry has confirmed that this issue exists and can be exploited to gain unauthorised access to servers running Java web applications based on the Spring framework.
Technical details
The vulnerability occurs in Spring Core applications running on JDK9+. Applications are likely to be vulnerable if they have functions that allow users to pass POJO (Plain Old Java Objects) as parameters. The currently circulating exploit takes advantage of vulnerable configurations to drop a web shell onto the affected host. Once this web shell is in place, attackers can execute arbitrary code on the affected server with the rights of the user running the Tomcat server. Likely, they can also use other exploits to further escalate their rights on the host.
What you should do: Mitigation advice
Now that there’s an official patch available, organizations should look at updating possibly affected applications as quickly as possible.
In case that’s not practical, organizations will need to deploy other mitigations. Short-term mitigation could look to use a WAF or similar technology to block the signature or data contained in the currently circulating exploit code, but this will obviously be bypassed as attackers create new variant exploits.
Another line of defense, which has been suggested by Praetorian and Contrast Security, requires modifying the affected applications and restricting the bindings that can be used, as noted in the Spring documentation.
Detection and mitigation with Aqua
Aqua can identify this zero-day RCE vulnerability by scanning for CVE-2022-22965. Since we detected the CVE long before it was assigned a number, we assigned it ID AQUA-2022-0329 in our Aqua Vulnerability Database (AVD).
Based on the guidance from the VMware Spring.io blog, Aqua will flag any vulnerable Spring framework packages to notify you which applications in your environment are potentially exploitable.
The nature of the vulnerability is more general, and there may be other ways to exploit it that haven’t been reported yet. To stay on top of this, you can also search across your entire environment in the Aqua console to uncover which applications have this CVE.
Aqua’s assurance policies will allow you to block artifacts with certain CVEs to ensure that these vulnerable applications don’t make it into production.
And for the already running workloads, Aqua’s drift prevention will block any attempt of executing malicious code during runtime.
Conclusion
How serious this issue is for specific organizations is likely to depend on their reliance on the vulnerable Spring framework. Whether it becomes as widespread as last year’s Log4shell issue is still unclear. But initial indications show that although there will be many vulnerable systems, the prerequisites for exploitation (only applications coded in a specific way are vulnerable) will hopefully reduce the number of systems that can be compromised.
