seanpesce/cve-2024-22243Ejemplos de escenarios explotables para CVE-2024-22243 que afecta al framework Spring (redirección abierta y SSRF).
Autor: Sean Pesce
Este proyecto contiene una aplicación web de ejemplo que demuestra escenarios explotables para CVE-2024-22243, una vulnerabilidad de análisis de URL en el Spring Framework de Java (divulgación oficial aquí).
Las versiones afectadas de Spring analizan el segmento "userinfo" de las URL de una manera única, lo que puede dar lugar a la extracción de un segmento de nombre de host que difiere de muchas otras librerías comunes.
El comportamiento anómalo se debe a la siguiente expresión regular ("regex") en la
clase UriComponentsBuilder
(introducida por
este commit
en 2014):
private static final String USERINFO_PATTERN = "([^@\\[/?#]*)";
Esta regex no permite el carácter "corchete izquierdo" ([) en el segmento de user info. Sin embargo,
Spring parece ser un caso atípico con este comportamiento, por lo que llamar a en un
objeto
construido mediante
o
puede dar lugar a un comportamiento inesperado. Las clases
,
y
también se ven afectadas debido a su uso interno de ; por lo tanto,
las implementaciones pueden volverse vulnerables incluso sin usar directamente .
getHost()UriComponentsBuilderUriComponentsBuilderPara entradas especialmente diseñadas, Spring devolverá un valor de nombre de host que difiere de todo lo siguiente:
java.net.URI (según se informa, solo para versiones específicas de Java; otras versiones lanzan una URISyntaxException)java.net.URLcurlandroid.net.Uriokhttp3.HttpUrlurllib.parse.urlparse(Tenga en cuenta que esta lista no es exhaustiva.)
Este comportamiento potencialmente hace que las aplicaciones web basadas en Spring sean vulnerables a redirección abierta y falsificación de solicitudes del lado del servidor (SSRF) si la implementación dependiente utiliza nombres de host de confianza para la autorización u otros mecanismos relevantes para la seguridad.
La aplicación web de ejemplo contiene dos endpoints vulnerables.
El primer endpoint, /redirect, muestra cómo el análisis anómalo de URL de Spring puede resultar en una
redirección abierta. Puede explotarse utilizando una URL como la siguiente:
https://127.0.0.1[@evil.com
El segundo endpoint, /health-check, demuestra cómo un desajuste en el análisis de URL entre Spring y
la clase URL de la librería estándar de Java puede resultar en una falsificación de solicitudes del
lado del servidor (SSRF). Puede explotarse utilizando una URL como la siguiente:
https://evil.com[@127.0.0.1
Para compilar este proyecto con Maven, simplemente ejecute el siguiente comando (probado con OpenJDK 17):
mvn clean package
Después, inicie la aplicación web con un comando como el siguiente:
java -jar seanpesce-cve-2024-22243.jar 9999
La aplicación web será accesible en http://127.0.0.1:9999/.
Para construir la imagen de docker, ejecute el siguiente comando:
docker build -t seanpesce-cve-2024-22243:latest .
Después, inicie la aplicación web con un comando como el siguiente:
docker run -i -e PORT=9999 -p 9999:9999 seanpesce-cve-2024-22243:latest
La aplicación web será accesible en http://127.0.0.1:9999/ en el host de Docker.
Este repositorio también contiene reglas de semgrep para ayudar a escanear
rutas de código potencialmente vulnerables. spring-cve-2024-22243_loose.yaml
realiza escaneos ingenuos de cualquier uso de las API vulnerables; por lo tanto, a menudo devolverá un gran
número de falsos positivos. spring-cve-2024-22243_strict.yaml
intenta utilizar una lógica más estricta y análisis de taint; sin embargo, esto no se ha
probado a fondo y tiene un alto potencial de pasar por alto algunas implementaciones vulnerables (especialmente cuando no se utiliza
Semgrep Pro, que es necesario para el análisis entre archivos).