A new vulnerability was discovered in the Spring framework after a Chinese security researcher leaked a proof-of-concept (PoC) exploit on GitHub.
This vulnerability affects Java Springcore and permits an attacker to perform a remote code execution. The vulnerability affects JDK 9 and higher. At the moment, there is no CVE and no official announcement from Spring at this time.
When reading emerging documentation online, be careful to not confuse this vulnerability with CVE-2022-22963 as this one affects the Spring Cloud Function, not the spring framework. The newly-discovered zero-day vulnerability known as “Spring4Shell”, do not have a CVE yet and could have “a larger impact” than Log4j according to certain researchers.
[UPDATE 04/01/22] : A CVE number was allocated to this vulnerability on March 31st. This vulnerability is now tracked under cve-2022-22965.
How it works?
Apparently, in order to exploit the vulnerability, attackers will have to locate and identify web app instances that actually use the DeserializationUtils.
In addition, first analysis seem to demonstrate that the exploitation requires an endpoint with DataBinder enabled (e.g. a POST request that decodes data from the request body automatically) and depends heavily on the servlet container for the application.
When an attacker identifies such system, the exploitation is straightforward, as it only requires an attacker to send a crafted HTTP request to a vulnerable system.
However, it is not yet clear if the exploitation of different configurations will require the attacker to do additional research in order to find payloads that will succeed.
The only thing researchers seem to be sure of is that Spring4Shell affects a popular framework used widely in 74 percent of Java applications. Therefore, the impact of this vulnerability is potentially high.
How to know if one of your system is affected?
1. Check the JDK version number
On the running server of the organization system, run:
"java --version"
If the version number is less than or equal to 8, it is not affected by the vulnerability.
2. Check for Spring framework usage
Change the suffix of the war or jar packages to .zip and unzip.
- Search for a jar file in spring-beans-*.jar. If it exists, it means that the business system is developed using the spring framework.
- If the spring-beans-*.jar file does not exist search for the existence of the CachedIntrospectionResuLts.class file in the decompression directory. If it exists, it means that the business system is developed using the Spring framework.
Conclusion
An analysis made by praetorian tends to provide a workaround but we hope a fix will be provided soon. Of course, the security community has mixed feelings about the impact of this vulnerability. Some researchers are afraid of a new “log4j” scenario while other researchers minimize the impact of this vulnerability. Only time will tell.
Sources
- https://github.com/spring-projects/spring-framework/commit/7f7fb58dd0dae86d22268a4b59ac7c72a6c22529#diff-6c2618839eda075efe4491842d3673eab8fe1e342f6d9ddc2bbda8556e595864L153
- https://www.cyberkendra.com/2022/03/springshell-rce-0-day-vulnerability.html
- https://www.praetorian.com/blog/spring-core-jdk9-rce/
- https://securityaffairs.co/wordpress/129644/hacking/spring-java-framework-rce-zero-day.html
- https://developer-tech.com/news/2022/mar/31/spring4shell-vulnerability-could-larger-impact-log4j/
- https://threatpost.com/critical-rce-bug-spring-log4shell/179173/
- https://www.ironcastle.net/possible-new-java-spring-framework-vulnerability-wed-mar-30th/
- https://unit42.paloaltonetworks.com/cve-2022-22965-springshell/