seanpesce/cve-2024-22243Exemples de scénarios exploitables pour CVE-2024-22243 affectant le framework Spring (redirection ouverte et SSRF).
Auteur: Sean Pesce
Ce projet contient une application web d'exemple qui démontre des scénarios exploitables pour CVE-2024-22243, une vulnérabilité d'analyse d'URL dans le Java Spring Framework (divulgation officielle ici).
Les versions affectées de Spring analysent le "segment userinfo" des URL d'une manière unique, ce qui peut entraîner l'extraction d'un segment de nom d'hôte qui diffère de nombreuses autres bibliothèques courantes.
Le comportement anormal est dû à l'expression régulière ("regex") suivante dans la
classe UriComponentsBuilder
(introduite par
ce commit
en 2014) :
private static final String USERINFO_PATTERN = "([^@\\[/?#]*)";
Cette regex n'autorise pas le caractère "crochet gauche" ([) dans le segment userinfo. Cependant,
Spring semble être une exception avec ce comportement, donc appeler getHost() sur un objet
UriComponents
construit en utilisant UriComponentsBuilder.fromUriString
ou
UriComponentsBuilder.fromHttpUrl
peut entraîner un comportement inattendu. Les classes
RestTemplate,
RestClient,
et WebClient
sont également affectées en raison de leur utilisation interne de UriComponentsBuilder ; donc,
les implémentations peuvent être rendues vulnérables même sans utilisation directe de UriComponentsBuilder.
Pour des entrées spécialement conçues, Spring renverra une valeur de nom d'hôte qui diffère de toutes les suivantes :
java.net.URI (apparemment seulement pour certaines versions de Java ; d'autres versions lèvent une URISyntaxException)java.net.URLcurlandroid.net.Uriokhttp3.HttpUrlurllib.parse.urlparse(Notez que cette liste n'est pas exhaustive.)
Ce comportement rend potentiellement vulnérables les applications web basées sur Spring aux redirections ouvertes et aux falsifications de requête côté serveur (SSRF) si l'implémentation dépendante utilise des noms d'hôte de confiance pour l'autorisation ou d'autres mécanismes liés à la sécurité.
L'application web d'exemple contient deux points de terminaison vulnérables.
Le premier point de terminaison, /redirect, montre comment l'analyse anormale des URL par Spring peut
entraîner une redirection ouverte. Il peut être exploité en utilisant une URL telle que la suivante :
https://127.0.0.1[@evil.com
Le second point de terminaison, /health-check, démontre comment une discordance dans l'analyse d'URL
entre Spring et la classe URL de la bibliothèque standard Java peut entraîner une falsification de requête
côté serveur (SSRF). Il peut être exploité en utilisant une URL telle que la suivante :
https://evil.com[@127.0.0.1
Pour construire ce projet avec Maven, exécutez simplement la commande suivante (testé avec OpenJDK 17) :
mvn clean package
Ensuite, démarrez l'application web avec une commande telle que la suivante :
java -jar seanpesce-cve-2024-22243.jar 9999
L'application web sera accessible à l'adresse http://127.0.0.1:9999/.
Pour construire l'image docker, exécutez la commande suivante :
docker build -t seanpesce-cve-2024-22243:latest .
Ensuite, démarrez l'application web avec une commande telle que la suivante :
docker run -i -e PORT=9999 -p 9999:9999 seanpesce-cve-2024-22243:latest
L'application web sera accessible à l'adresse http://127.0.0.1:9999/ sur l'hôte Docker.
Ce dépôt contient également des règles semgrep pour aider à scanner les
chemins de code potentiellement vulnérables. spring-cve-2024-22243_loose.yaml
effectue des analyses naïves de toute utilisation des API vulnérables ; ainsi, il renverra souvent un grand
nombre de faux positifs. spring-cve-2024-22243_strict.yaml
tente d'utiliser une logique plus stricte et une analyse de flux de données ; cependant, cela n'a pas été
testé de manière approfondie et a un fort potentiel pour manquer certaines implémentations vulnérables
(surtout lorsque Semgrep Pro n'est pas utilisé, ce qui est nécessaire pour l'analyse inter-fichiers).