VMware Spring Cloud Gateway Code Injection Vulnerability (CVE-2022-22947)
Date Added to KEV Catalog: May 16, 2022
CISA Due Date for Remediation: June 6, 2022
Table of Contents
Vulnerability
Introduction to Spring Cloud Gateway
Spring Cloud Gateway is an API gateway which aims to provide a simple way to route to microservices. An external client can access these microservices through the application gateway. This external client could be a mobile application, desktop application or a third party application. Spring describes how the Cloud Gateway works: “Clients make requests to Spring Cloud Gateway. If the Gateway Handler Mapping determines that a request matches a route, it is sent to the Gateway Web Handler. This handler runs the request through a filter chain that is specific to the request. The reason the filters are divided by the dotted line is that filters can run logic both before and after the proxy request is sent. All “pre” filter logic is executed. Then the proxy request is made. After the proxy request is made, the “post” filter logic is run.”
Vulnerability Description
Wyatt Dahlenburg found this Expression Language injection vulnerability. Applications using Spring Cloud Gateway are vulnerable to a code injection attack when the Gateway Actuator endpoint is enabled, exposed and unsecured. A remote attacker could make a maliciously crafted request that could allow arbitrary remote execution on the remote host. The maliciously crafted request uses Spring Expression Language (SpEL).
Systems Affected and Detection
Spring Cloud Gateway
- 3.1.0
- 3.0.0 to 3.0.6
- Older, unsupported versions are also affected
Exploitation
Wyatt Dahlenburg describes in two blog posts how to create a route and execute commands using the Actuator endpoint and SpEL.
There are three clear methods to exploit this vulnerability: manually through POST requests on Burp Suite, running a publicly available python exploit, or using a Metasploit module.
Manual exploitation through Burp Suite
Spring documentation outlines how to create and delete routes via the /actuator/gateway endpoint:
The above documentation shows how to view all listed routes with a GET request of /actuator/gateway/routes and a create new route with a POST request of /actuator/gateway/routes/{id}. In the below example, a route is added following the example shown on Github vulhub’s exploitation steps.
Confirm Spring Cloud Gateway is running via Linux command line:
ps aux | grep java
If running a vulnerable environment a sample test page is typically shown on port 8080:
Manual exploitation involves:
- Using a POST request to add a new route to the Spring Cloud Gateway actuator endpoint. The example below is “hacktest”: /actuactor/gateway/routes/hacktest. This added route will also include a SpEL expression value that defines the RCE. The example command is “id“.
- Send a GET request and POST request to refresh and confirm the new route
- Send a GET request to the new route, which will run the “id” command, shown in a HTTP response
Add a route “hacktest” with a POST request (/actuator/gateway/routes/hacktest) and the SpEL value (#{ ….”id” }).
The 201 HTTP response confirms the route is created.
Refresh the route with a refresh request. All new routes need a follow on request to make the application recognize the new route. The 200 HTTP response confirms the new route was successful added.
Send another GET request to the new “hacktest” route to run the malicious SpEL injection. In this case, the “id” command executed. The Burp Suite Response panel shows the root user:
An attacker could then attempt to get to use this RCE to attain a reverse shell.
Public Python Exploit
ExploitDB shows only one exploit under “spring cloud gateway”:
Spring Cloud Gateway 3.1.0 – Remote Code Execution (RCE)
Kali Linux users, with an updated ExploitDB database, can find the exploit through the searchsploit command and located here:
File Path: /usr/share/exploitdb/exploits/java/webapps/50799.py
This python exploit is also on Github and works on Vulhub’s vulnerable environment. Note: always read through and understand public exploits before running. The ExploitDB exploit is technically not listed as verified.
Metasploit Exploit Module
Another exploit option is using Metasploit and the module: exploit/linux/http/spring_cloud_gateway_rce.
Remediation
VMware Tanzu released the following mitigation notice:
Users of affected versions should apply the following remediation. 3.1.x users should upgrade to 3.1.1+. 3.0.x users should upgrade to 3.0.7+. If the Gateway actuator endpoint is not needed it should be disabled via management.endpoint.gateway.enabled: false. If the actuator is required it should be secured using Spring Security, see how to secure endpoints here.
Releases that have fixed this issue include: Spring Cloud Gateway 3.0.7+ and 3.1.1+.
References:
- https://wya.pl/2021/12/20/bring-your-own-ssrf-the-gateway-actuator/
- https://wya.pl/2022/02/26/cve-2022-22947-spel-casting-and-evil-beans/
- https://cloud.spring.io/spring-cloud-gateway/reference/html/#recap-the-list-of-all-endpoints
- https://www.rapid7.com/db/modules/exploit/linux/http/spring_cloud_gateway_rce/
- https://tanzu.vmware.com/security/cve-2022-22947