Recently, NSFOCUS CERT detected a remote code execution vulnerability in Spring related frameworks. Unauthorized remote attackers can construct HTTP requests to write malicious programs on the target system to execute arbitrary code. This vulnerability is Spring framework remote code execution vulnerability. (CVE-2010-1622), but it has a wider impact. Officials have released versions 5.2.20.RELEASE and 5.3.18 in the afternoon of Mar 31 to fix this vulnerability. At present, the PoC has been made public, please relevant users as soon as possible Take measures to investigate and protect.
NSFOCUS has successfully reproduced the vulnerability:
Scope of Impact
- Spring Framework < 5.3.18
- Spring Framework < 5.2.20
and its derivatives:
- JDK ≥ 9
- JRE ≥ 9
- Spring Framework = 5.3.18
- Spring Framework = 5.2.20
- JDK < 9
- JRE < 9
1. Detect whether the Spring framework is used. If it is not used, the vulnerability does not exist.
Since Java projects have different packaging methods, Spring Bean is often packaged as a basic component Lib, and non-standard naming, etc., it is recommended to use automatic iterative decompression of jars and match spring-beans-*.jar with CachedIntrospectionResults.class. search. If there is a match, the Spring framework is used.
It is recommended to use the D-Eyes tool provided by NSFOCUS CERT for automated scanning.
According to the vulnerability information, a local inspection tool “D-Eyes Emergency Response Tool Spring Vulnerability Inspection Special Edition” has been urgently developed, which is suitable for Windows and Linux systems. This tool can be used not only to detect CVE-2022-22965 but also webshell as well. For relevant customers, please contact email@example.com
2. Check whether the project uses Spring parameter binding. If it is not used, the vulnerability does not exist.
Since this vulnerability requires the use of SpringMVC’s parameter binding, project-related developers who do not use parameter binding are not affected by this vulnerability.
3. Check the JDK version used by the middleware. If the version number is less than 9, the vulnerability does not exist.
First, through the system process, confirm the JDK path used by the middleware, and execute “java -version” on the command line to obtain the currently used JDK version.
4. Check whether the currently used middleware is Tomcat. If Tomcat is not used, it is not affected by this vulnerability.
The currently disclosed exploit code is only for Tomcat middleware, but it is not ruled out that new exploit code will appear in the future, so there is still the possibility of risk for non-Tomcat middleware.
5. Check whether AccessLog is enabled in Tomcat. If it is not enabled, it is not affected by this vulnerability.
The currently disclosed vulnerability exploit code implements backdoor file writing by overwriting Tomcat’s log-related configuration. Therefore, if AccessLog is not enabled, it will not be affected by this vulnerability for the time being, but it cannot be ruled out that new exploitation methods will appear in the future.
In the server.xml configuration file, the AccessLog related configuration can be located through the org.apache.catalina.valves.AccessLogValve keyword.
NSFOCUS RSAS, WVSS, UTS and ISOP have the ability to scan and monitor this vulnerability, users who deployed devices about shall upgrade to the latest version.
|Upgrade package version
|RSAS V6 System plugin package
|Spring Framework Remote Code Execution Vulnerability
|RSAS V6 Web plugin package
|WVSS V6 plugin upgrade package
If the above detection is passed, if it is confirmed that the vulnerability exists, the following methods can be used to check whether it is attacked.
1. Anomaly field detection
Since the currently disclosed exploit code will affect some fields of AccessLogValve and StandardHost, you can scan the relevant fields by executing the script provided by NSFOCUS CERT under Tomcat to detect the attack traces.
This detection method is only valid under the premise that the JVM has not been restarted or the content of the relevant fields has not been recovered by the attacker. Examples of normal business scan results are as follows:
An example of the scan result after being attacked is as follows:
2. Logs and backdoor files After the currently disclosed exploit code is executed, Tomcat will no longer generate a new AccessLog. You can check whether the latest AccessLog is missing to determine whether it is under attack.
Check whether there are suspicious backdoor files in the Tomcat-related web application directory. Since the attacker has modified some AccessLog configuration fields, there may be a large number of “-” in the file.
detect.jsp Code block:
At present, the official has released new versions 5.2.20.RELEASE and 5.3.18 to fix this vulnerability, please update the affected users as soon as possible for protection, download link: https://github.com/spring-projects/spring-framework/releases
In response to the above vulnerabilities, NSFOCUS’s Web Application Protection System (WAF) and Network Intrusion Prevention System (IPS) have released rule upgrade packages, and relevant users are requested to upgrade the rule packages to the latest version to form security product protection capabilities. The number of safety protection product rules is as follows:
|Safety protection products
|Upgrade package version
Note: If you want to apply a rule, check the corresponding rule number above for the protected site.
The pre-WAF web server/plugin protection rule (ID: 27002873) also supports protection against this vulnerability by default:
Please refer to the following link for the operation steps of product rule upgrade:
Other related users can implement rule filtering for strings such as “class. * ” ，“Class.*”，“*.class.*”，“*.Class.*” on network protection devices such as WAF according to the actual traffic situation of the deployed business, and after deploying the filtering rules, test the business operation to avoid additional impact.
Affected users can use the following measures to fix the vulnerability:
1. Search the setDisallowedFields method globally in the project
2. If setDisallowedFields is found, add the following code to the Controller:
3. If setDisallowedFields is not found, introduce Controller and use the ControllerAdvice annotation to implement global exception interception. The code is as follows:
Note: In the project source code, try not to use the setDisallowedFields method repeatedly, otherwise the global Controller will fail.
Reference code block:
This advisory is only used to describe a potential risk. NSFOCUS does not provide any commitment or promise on this advisory. NSFOCUS and the author will not bear any liability for any direct and/or indirect consequences and losses caused by transmitting and/or using this advisory. NSFOCUS reserves all the rights to modify and interpret this advisory. Please include this statement paragraph when reproducing or transferring this advisory. Do not modify this advisory, add/delete any information to/from it, or use this advisory for commercial purposes without permission from NSFOCUS.
NSFOCUS, Inc., a global network and cyber security leader, protects enterprises and carriers from advanced cyber attacks. The company’s Intelligent Hybrid Security strategy utilizes both cloud and on-premises security platforms, built on a foundation of real-time global threat intelligence, to provide multi-layered, unified and dynamic protection against advanced cyber attacks.
NSFOCUS works with Fortune Global 500 companies, including four of the world’s five largest financial institutions, organizations in insurance, retail, healthcare, critical infrastructure industries as well as government agencies. NSFOCUS has technology and channel partners in more than 60 countries, is a member of both the Microsoft Active Protections Program (MAPP), and the Cloud Security Alliance (CSA).
A wholly owned subsidiary of NSFOCUS Technologies Group Co., Ltd., the company has operations in the Americas, Europe, the Middle East and Asia Pacific.