After multiple reports surfaced over the past week, Spring confirmed the remote code execution (RCE) vulnerability in the Spring Framework. The vulnerability has been tracked as CVE-2022-22965 and it is quite possible that it has already been actively exploited.

The exploitation of this flaw, now known as SpringShell, reportedly requires a DataBinder-enabled endpoint and relies heavily on the servlet container for the application. For example, when Spring is deployed in Apache Tomcat, WebAppClassLoader can be accessed, allowing threat actors to call collectors and definers to write a malicious JSP file to disk. However, if Spring is implemented using the built-in Tomcat servlet container, the class loader is a LaunchedURLClassLoader that has limited access.

In JDK9 and later versions of the Spring framework, remote malicious hackers can obtain the AccessLogValve object and the values of the malicious fields through the parameter linking function of the framework on the basis of the fulfillment of certain conditions, thus activating the pipeline mechanism to write arbitrary files to the path.

HOW TO CHECK EXPOSURE TO THIS FLAW?

Cybersecurity specialists mention that there are various methods to verify the degree of exposure to an attack.

Check the JDK version number

On the running server of the system, run the java -version command to verify the running JDK version. If you are running versions 8 or later, the system will not be affected.

Verify the use of the Spring framework

If the system project is deployed in the form of a war package, follow the steps below to determine if the system is compromised:

  • Unzip the war package. Change the suffix of the war file to .zip and unzip the zip file
  • Search for a jar file in spring-beans-*.jar format in the decompression directory. If it exists, it means that the system is developed using the Spring framework
  • If the spring-beans-*.jar file does not exist, search for the cachedIntrospectionResuLts.class file. if this file exists it means that the system is developed using the spring framework

If the organization system project runs directly and independently in the form of a jar package, verify by applying the following steps:

  • Unzip the jar package; change the suffix of the jar file to .zip and unzip the zip file
  • Search for a jar file in spring-beans-*.jar format in the decompression directory. If it exists, it means that the system is developed using the Spring framework
  • If the spring-beans-*.jar file does not exist, search for the cachedIntrospectionResuLts.class file. If it exists it means that the system runs using the spring framework

IN SEARCH OF THE FLAW

After completing the previous two troubleshooting steps, the following two conditions are met at the same time to determine the presence of the flaw:

  • Use of JDK in versions 9 and later
  • Use of the Spring frame

MITIGATION

The vulnerability has not been officially fixed, although it is already known of the existence of two applicable workarounds at least until spring developers can issue a full patch.

WAF

On web application firewall (WAF) protected systems, implement rule filtering for strings such as “class.*”, “Class.*”, “*.class.*”, and “*. Class.*”, according to the actual situation of the traffic of deployed services. After applying the filtering, do the necessary tests to avoid an additional impact on your systems.

Additional Solutions

You can simultaneously apply the following steps to mitigate the risk of exploitation:

  • Look for the annotation @InitBinder 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.*”, “*.class.*”, “*. Class.*”
  • Create the following global class in the application system project package and ensure that Spring loads this class. after you add the class the project must be recompiled and packaged and tested for functional verification and republishing 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);
             }
        }

The patches will be ready shortly, so it is expected to be able to prevent the massive exploitation of this vulnerability.

To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

The post How to temporarily fix SpringShell? Zero-day vulnerability in Spring Core appeared first on Information Security Newspaper | Hacking News.

source

You May Also Like

Zero-day vulnerabilities in all Chrome browser versions affect millions of users

Google has issued an update for Chrome users on Windows, Linux and…

3 important vulnerabilities in Samba: Patch immediately

Samba announced the release of some updates that aim to address various…

3 XSS vulnerabilities in IBM Security QRadar SOAR: Update immediately

Cybersecurity specialists reported the detection of multiple vulnerabilities in IBM Security QRadar…

Critical privilege escalation vulnerability affects almost all HP printers

HP security teams announced the correction of multiple critical flaws in dozens…