RCE Bug in Spring Framework
While defenders are still reeling from the Log4j vulnerability, in late March, a high-severity remote-code execution vulnerability was found in the Spring Core Java Framework, a popular framework for building modern Java web applications. The specific exploit targets Java 9+ and especially those using TomCat as the WAR deployment.
The vulnerability allows an unauthorized and unauthenticated attacker to execute arbitrary code on a targeted system. While certain configurations are easy to exploit, other configurations will require some efforts In either scenario, we recommend immediate mitigation
Vulnerability Description
Recently, Ridge Security discovered a new 0-day RCE vulnerability in the Spring Framework. A change introduced in Java 9 roughly five years ago combined with the Spring Framework can lead to vulnerable applications. In JDK 9+ environments, the attacker can modify the log file of the middleware by deploying a malicious payload for remote code execution.
Due to the critical severity of this vulnerability, it is recommended that users of Spring Framework check whether they are impacted by the vulnerability, and take immediate remediation actions. RidgeBot 3.9.4 has updated its plugin library to include the Spring4Shell detection and exploitation.
Vulnerability number
CVE-2022-22965 (https://nvd.nist.gov/vuln/detail/CVE-2022-22965 )
Risk level
Critical
Affected version
- For Spring Framework 5.3 branch, version earlier than 5.3.18
- For Spring Framework 5.2 branch, version earlier than 5.2.20
Detection Methods
Method #1 Check Manually
JDK Version Check
Run the “java-version” command to check the JDK version. If the JDK version number is ≤8, it is not affected by this vulnerability.
Spring framework detection
- If the application is deployed in the form of a .war file, use the following steps:
- Unzip the .war file: change the suffix of the .war file to a .zip file;
- Search for files in the spring-beans-*.jar format (such as spring-beans-5.3.16.jar) in the decompressed directory. If it exists, it means the application is developed using the Spring Framework;
- If the spring-beans-*.jar files do not exist, search for the CachedlntrospectionResults.class file in the decompressed directory. If it exists, it means the application is developed using the Spring Framework.
- If the application runs independently in the form of a .jar file, detect by using the following steps:
- Unzip the .jar file: change the suffix of the .jar file to zip, and unzip the .zip file;
- Search for the existence of jar files in the spring-beans-*.jar format (for example, spring-beans-5.3.16.jar) in the decompressed directory. If it exists, it means the application is developed using the Spring Framework;
- If the spring-beans-*.jar files do not exist, search for the CachedIntrospectionResults.class file in the decompressed directory. If it exists, it means the business system is developed using the Spring Framework.
Further Detection
After completing the above two steps for troubleshooting, if two of the following conditions are met, then it is impacted by this vulnerability:
- JDK version ≥ 9;
- The Spring Framework or derived frameworks are used;
- The Web interface in the application uses the JavaBean object.
Method #2 Automated Check with RidgeBot
RidgeBot Penetration Testing
RidgeBot has supported Spring Framework vulnerability detection since release 3.9.4. Users can perform automated testing over the target systems by using RidgeBot. RidgeBot will then report back whether the spring4shell exists or not. The Screen Shot 1 shows the attack sequences that RidgeBot launched to exploit the Spring4Shell vulnerability; the Screen Shot 2 shows the actual evidence that the target has been compromised by RidgeBot’s successful exploit.
Screen Shot 1: attack sequence to test CVE-2022-22965
Screen Shot 2: Evidence of CVE-2022-22965 Spring Framework RCE Exploited
Recommended Fixes
Official Patch Released
The official patch has been released, and Spring can be upgraded to the 5.3.18 or 5.2.20 security version for mitigation.
https://github.com/spring-projects/spring-framework/tags
WAF protection
On the network protection appliance, add filtering rules for the “class.module.*” string based on the deployed traffic. After deploying the filtering rules, test the business operation to avoid additional impact.
Temporary mitigation
In addition, follow these two steps for temporary mitigation if you cannot upgrade the Spring Version:
1. Search the @InitBinder annotation globally in the application to see if the dataBinder.setDisallowedFields method is called in the method body. If the method is called in the code, add “class.module.*” to the original blacklist.
Note: If this code snippet is used frequently, it needs to be appended everywhere.
2. 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, packaged, and tested for functional verification, and republished.
Ridge Security Technical Support
Ridge Security will actively provide technical support to our users, and continue to track and report the progress of this Spring RCE in a timely manner. If you have any questions, please contact support@ridgesecurity.ai.