snip3r69/spring-shell-vulnSpring has Confirmed the RCE in Spring Framework. The team has just published the statement along with the mitigation guides for the issue. Now, this vulnerability can be tracked as CVE-2022-22965.
Spring has Confirmed the RCE in Spring Framework. The team has just published the statement along with the mitigation guides for the issue. Now, this vulnerability can be tracked as CVE-2022-22965.
Some information about the Spring4Shell vulnerability and have shared the details on Spring4Shell: Details and Exploit post. Additionally, the security team from Praetorian has confirmed Spring Core on JDK9+ is vulnerable to remote code execution due to a bypass for CVE-2010-1622.
Initially, it was started on 30th March, the first notification of the vulnerability was hinted at by the leader of the KnownSec 404 team, Heige. He twitted with the warning message "Spring core RCE （JDK >=9" along with the PoC Picture.
As we go live with the story of vulnerability, Heige disappears from Twitter. Don't know the reason behind this but there may be something.
At the end of 2021, the internet was on fire with the drop of Zero-day a remote code execution vulnerability also known as Log4Shell, in Apache Log4j2. The vulnerability was found by the Alibaba Cloud security team.
Today, researchers found another worst vulnerability which may cause severe damage. Now the bug is been tracked as CVE-2022-22965, we may call it Spring4Shell. The vulnerability exists in the Spring core with the JDK version greater or equal to 9.0.
Spring Framework and derived framework spring -beans-*.jar files or CachedIntrospectionResults.class
All the details below are confirmed now. I don't take responsibility for any damage caused.
As one of the world's most popular Java lightweight open-source framework, Spring allows developers to focus on business logic and simplifies the development cycle of Java enterprise applications.
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. For example, when Spring is deployed to Apache Tomcat, the WebAppClassLoader is accessible, which allows an attacker to call getters and setters to ultimately write a malicious JSP file to disk. However, if Spring is deployed using the Embedded Tomcat Servlet Container the classloader is a LaunchedURLClassLoader which has limited access.
However, in the JDK9 version (and above) of the Spring framework, a remote attacker can obtain the AccessLogValve object and malicious field values through the parameter binding function of the framework on the basis of meeting certain conditions.
On the running server of the organization system, run the "java -version" command to check the running JDK version. If the version number is less than or equal to 8, it is not affected by the vulnerability.
After completing the above two steps of troubleshooting, the following two conditions are met at the same time to determine that it is affected by this vulnerability:
Now the Spring team has fixed the vulnerability and released the latest versions of Spring Boot 2.6.6 and 2.5.12 that depend on Spring Framework 5.3.18
On network protection devices such as WAF, implement rule filtering for strings such as "class.", "Class.", ".class.", and ".Class." according to the actual traffic situation of deployed services. After filtering the rules, test the business operation to avoid additional impact.
Temporary repair of the leak should be performed in the following two steps at the same time:
Search the @InitBinder annotation globally in the application to see if the dataBinder.setDisallowedFields method is called in the method body. If the introduction of this code snippet is found, add {"class.","Class. to the original blacklist ",".class.", ".Class."}. (Note: If this code snippet is used a lot, it needs to be appended everywhere)
Create the following global class under the project package of the application system, and ensure that this class is loaded by Spring (it is recommended to add it in the package where the Controller is located). After the class is added, the project needs to be recompiled and packaged, and tested for functional verification. and republish the project. import org.springframework.core.annotation.Order;
import org.springframework.web.bind.WebDataBinder;
import org.springframework.web.bind.annotation.ControllerAdvice;
import org.springframework.web.bind.annotation.InitBinder;
@ControllerAdvice
@Order(10000)
public class GlobalControllerAdvice{
@InitBinder
public void setAllowedFields(webdataBinder dataBinder){
String[]abd=new string[]{"class.*","Class.*","*.class.*","*.Class.*"};
dataBinder.setDisallowedFields(abd);
}
}
From the Git Repository of Spring projects, it seems that the Spring developer is working on a fix for the remote code execution vulnerability, but we have to wait for the official confirmation.