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 auf einem
Objekt, das mit erstellt wurde,
oder
zu unerwartetem Verhalten führen kann. Die Klassen
,
,
und
sind ebenfalls betroffen, da sie intern verwenden; daher
können Implementierungen auch ohne direkte Verwendung von angreifbar sein.
getHost()UriComponentsBuilderUriComponentsBuilderBei 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).