seanpesce/cve-2024-22243Beispielhafte ausnutzbare Szenarien für CVE-2024-22243, die das Spring-Framework betreffen (Open Redirect & SSRF).
Autor: Sean Pesce
Dieses Projekt enthält eine Beispiel-Webanwendung, die ausnutzbare Szenarien für CVE-2024-22243, eine URL-Parsing-Schwachstelle im Java-Spring Framework (offizielle Offenlegung hier).
Betroffene Spring-Versionen parsen das "userinfo"-Segment von URLs auf eine einzigartige Weise, was möglicherweise zur Extraktion eines Hostnamen-Segments führt, das sich von vielen anderen gängigen Bibliotheken unterscheidet.
Das anomale Verhalten ist auf den folgenden regulären Ausdruck („Regex“) in der
UriComponentsBuilder
-Klasse zurückzuführen (eingeführt durch
diesen Commit
in 2014):
private static final String USERINFO_PATTERN = "([^@\\[/?#]*)";
Dieser Regex erlaubt das Zeichen „linke eckige Klammer“ ([) nicht im User-Info-Segment. Allerdings,
Spring scheint mit diesem Verhalten ein Ausreißer zu sein, daher kann der Aufruf von getHost() auf einem
UriComponents
Objekt, das mit UriComponentsBuilder.fromUriString erstellt wurde,
oder
UriComponentsBuilder.fromHttpUrl
zu unerwartetem Verhalten führen kann. Die Klassen
RestTemplate,
RestClient,
und WebClient
sind ebenfalls betroffen, da sie intern UriComponentsBuilder verwenden; daher
können Implementierungen auch ohne direkte Verwendung von UriComponentsBuilder angreifbar sein.
Bei speziell konstruierten Eingaben gibt Spring einen Hostnamen-Wert zurück, der sich von allen folgenden unterscheidet:
java.net.URI (nach Berichten nur für bestimmte Java-Versionen; andere Versionen werfen eine URISyntaxException)java.net.URLcurlandroid.net.Uriokhttp3.HttpUrlurllib.parse.urlparse(Beachte, dass diese Liste nicht vollständig ist.)
Dieses Verhalten macht Spring-basierte Webanwendungen potenziell anfällig für Open Redirect und Server-Side Request Forgery (SSRF), wenn die abhängige Implementierung vertrauenswürdige Hostnamen für die Autorisierung oder andere sicherheitsrelevante Mechanismen verwendet.
Die Beispiel-Webanwendung enthält zwei angreifbare Endpunkte.
Der erste Endpunkt, /redirect, zeigt, wie Springs anormales URL-Parsing zu einer offenen
Weiterleitung führen kann. Er kann mit einer URL wie der folgenden ausgenutzt werden:
https://127.0.0.1[@evil.com
Der zweite Endpunkt, /health-check, zeigt, wie eine Diskrepanz beim URL-Parsing zwischen Spring und
der Java-Standardbibliothek URL zu Server-Side Request Forgery (SSRF) führen kann. Er kann
mit einer URL wie der folgenden ausgenutzt werden:
https://evil.com[@127.0.0.1
Um dieses Projekt mit Maven zu bauen, führe einfach den folgenden Befehl aus (getestet mit OpenJDK 17):
mvn clean package
Starte dann die Web-App mit einem Befehl wie dem folgenden:
java -jar seanpesce-cve-2024-22243.jar 9999
Die Web-App ist unter http://127.0.0.1:9999/ erreichbar.
Um das Docker-Image zu erstellen, führe den folgenden Befehl aus:
docker build -t seanpesce-cve-2024-22243:latest .
Starte dann die Web-App mit einem Befehl wie dem folgenden:
docker run -i -e PORT=9999 -p 9999:9999 seanpesce-cve-2024-22243:latest
Die Web-App ist auf dem Docker-Host unter http://127.0.0.1:9999/ erreichbar.
Dieses Repository enthält außerdem semgrep-Regeln, die beim Scannen nach
potenziell angreifbaren Codepfaden helfen. spring-cve-2024-22243_loose.yaml
führt naive Scans nach jeder Verwendung der anfälligen APIs durch; daher liefert es oft eine große
Anzahl falscher Positiver. spring-cve-2024-22243_strict.yaml
versucht, strengere Logik und Taint-Analyse zu verwenden; dies wurde jedoch nicht
gründlich getestet und birgt ein hohes Potenzial, einige anfällige Implementierungen zu übersehen (insbesondere wenn nicht
Semgrep Pro verwendet wird, das für die dateiübergreifende Analyse erforderlich ist).