Remote Code Execution with Spring Data Commons (CVE-2018-1273)
In the recent days another critical vulnerability in Spring Framework was published (CVE-2018-1273). This time the vulnerable component is Spring Data Commons. Spring Data component goal is to provide a common API for accessing NoSQL and relational databases. Spring Data Commons provides basic implementation and interfaces to the other Spring Data projects. It was found that the MapDataBinder class of the Spring Data Commons project was unsafely parsing and evaluating a Spring Expression Language (SpEL) Expression which may be controlled by the user. Because of this unsafe evaluation an attacker can send a string that contains the special T() operator which tells Spring expression parser to treat the string inside it as a class reference and consequently may allow execution of arbitrary code. To mitigate the issue, Spring developers changed the class which they were performing the expression evaluation with from StandardEvaluationContext which allows evaluating Java type references, constructors and bean references to SimpleEvaluationContext which prohibits them and was designed to support only a subset of the Spring Expression Language syntax. Figure 1: Spring Data Commons Github commit showing the change from StandardEvaluationContext to SimpleEvaluationContext Figure 2: CVE-2018-1273 Proof of Concept as it was posted by @shengqi158 (xxlegend) via Twitter Mitigating the vulnerability with BIG-IP ASM BIG-IP ASM customers under any supported BIG-IP version are already protected against this vulnerability. The exploitation attempt will be detected by existing Java code injection attack signatures which can be found in signature sets that include the “Server Side Code Injection” attack type or “Java Servlets/JSP” System. Also, operating system command execution signatures will detect the attempt to execute operating system commands as the payload for the exploit. Figure 3: Exploit blocked with attack signature 200003437. Figure 4: Exploit blocked with attack signature 200003073 Figure 5: Exploit blocked with attack signature 200002273Directory Traversal with Spring MVC on Windows (CVE-2018-1271)
Recently a directory traversal vulnerability in the Spring Framework was published (CVE-2018-1271). The Spring application will only be vulnerable when it is deployed on a Microsoft Windows based operating system and the application developer uses the “file://” scheme as the path of the static resources. Figure 1: Example of a vulnerable resource path configuration The answer for why only applications deployed on servers based on Microsoft Windows operating systems are vulnerable can be found in the Github commit that fixes the vulnerability. We can see that the “isInvalidEncodedPath” function covered only the case of “../” directory traversal attempts, while Windows operating systems supports paths that contains backslashes, and thus “..\” will also lead to directory traversal. Figure 2: Spring Framework’s Github commit fixing the vulnerability Mitigating the vulnerability with BIG-IP ASM BIG-IP ASM customers under any supported BIG-IP version are already protected against this vulnerability. The exploitation attempt will be detected by existing evasion techniques in URL, "Directory Traversal” and “IIS Backslashes”. Figure 3: Exploitation attempt blocked by “Directory Traversals” evasion technique. Figure 4: Exploitation attempt blocked by “IIS backslashes” evasion technique.Spring Framework Spring-Messaging Remote Code Execution (CVE-2018-1270 / CVE-2018-1275)
In the recent days a critical vulnerability in Spring framework was published. The vulnerable component is Spring-Messaging which is the Spring implementation of WebSockets, Spring-Messaging uses the STOMP messaging protocol as the subprotocol for WebSockets. The vulnerability allows attackers to run arbitrary code by sending a crafted STOMP WebSocket message. A Proof of Concept code exploiting this vulnerability is already publicly available. Mitigating the vulnerability with BIG-IP ASM BIG-IP ASM customers with BIG-IP versions greater than 12.1.0 which allows WebSocket inspection are already protected against this vulnerability. The exploitation attempt will be detected by existing Java code injection attack signatures which can be found in signature sets that include the “Server Side Code Injection” attack type or “Java Servlets/JSP” System. Also, operatingsystem command execution signatures will detect the attempt to execute operatingsystem commands as the payload for the exploit. Figure 1:Exploit blocked with attack signature 200003437. Figure 2:Exploit blocked with attack signature 200003073. Figure 3:Exploit blocked with attack signature 200002273.
