raghvendra1207/cve-2022-22978Prueba de concepto que demuestra la omisión de autorización en RegexRequestMatcher de Spring Security (CVE-2022-22978) mediante inyección CRLF, con análisis y pasos de mitigación.
Según la información que he investigado, esta es una vulnerabilidad relacionada con la clase RegexRequestMatcher en el framework Spring Security. Específicamente, las aplicaciones que usan RegexRequestMatcher donde la expresión regular contiene un punto (.) pueden ser omitidas mediante los caracteres \r(%0a) , \n(%0d); de esta forma, los atacantes sin autenticación pueden acceder a rutas no permitidas.
Versiones afectadas del framework Spring Security:
5.5.x anteriores a 5.5.75.6.x anteriores a 5.6.4Necesitamos acceder al código fuente de Spring Security para analizar estáticamente esta vulnerabilidad. Específicamente, utilicé la función de comparación de commits entre las versiones 5.6.3 (versión vulnerable) y 5.6.4 (versión corregida) de Github. Véase en el siguiente enlace: Comparing 5.6.3...5.6.4 · spring-projects/spring-security (github.com)
Revisé los cambios en la clase RegexRequestMatcher. Se puede observar que en la versión 5.6.4, esta clase utiliza Pattern.DOTALL en lugar del . por defecto de la versión 5.6.3. Donde:
Pattern : es una de las tres clases del paquete java.util.regex, que se encarga de procesar expresiones regulares.Pattern.DOTALL : Al usar esta bandera, "." en una expresión regular coincidirá con todos los caracteres, incluidos los saltos de línea como \n , \r.Pattern.CASE_INSENSITIVE: no distingue entre mayúsculas y minúsculas.
Por defecto, el punto . en una expresión regular coincide con todos los caracteres excepto los saltos de línea como \n, \r. Si hay una función regex que valida el patrón de una cadena, esa función no coincidirá si la cadena contiene saltos de línea. Para evitar esto, se puede usar la bandera Pattern.DOTALL.
Sin embargo, si alguien utiliza intencionadamente %0d en lugar de \n o %0a en lugar de \r, la regex anterior aún no coincidiría. Por lo tanto, en la versión 5.6.4, se añadió una verificación adicional para este caso en RegexRequestMatcherTests.java. Específicamente, convierte %0d y %0a respectivamente en \n y \r antes de verificar con la regex.
Paso 1: Crear una aplicación web Spring Boot usando Spring Initializr con dos dependencias: Spring Security y Spring Web.
Paso 2: Crear un Controller que imprima el texto This is a CVE-2022-22978 demo cuando se reciba una solicitud en la ruta /admin/*
Paso 3: Configurar un mecanismo de autenticación cada vez que un usuario acceda a la ruta /admin/<cualquier> usando regexMatchers("/admin/.*").authenticated(). Esta es la vulnerabilidad que los atacantes aprovechan para ver el contenido de las páginas /admin/<cualquier> sin autenticación.
Paso 4: En el archivo de configuración, declarar la versión de Spring Security que contiene la vulnerabilidad. Aquí elegí la versión 5.6.3.
Paso 5: Ejecutar la aplicación con el comando gradlew bootRun; el programa utiliza por defecto Apache Tomcat escuchando en el puerto 8080. Accedemos a la ruta /admin/xyz (cualquier ruta que comience con /admin/).
El resultado devuelve un código 403 Forbidden, lo que significa que no podemos acceder porque no estamos autenticados.
En este punto, aprovechamos la vulnerabilidad de la función regexMatchers en Spring Security (versión 5.6.3) que no coincide con caracteres de nueva línea como \r(%0d) y \n(%0a) → podemos acceder a la ruta anterior sin autenticación usando el payload /admin/%0dxyz
Similar con el payload /admin/%0axyz
Así, hemos explotado con éxito la vulnerabilidad CVE-2022-22978 con un payload muy simple.
5.7.1
Intentar atacar la web con el payload similar: /admin/%0dxyz
Ahora, la aplicación no devuelve la respuesta que el atacante esperaba.
git clone https://github.com/ducluongtran9121/CVE-2022-22978-PoC.git
cd CVE-2022-22978-PoC
gradlew bootRun
Java 18
Gradle 7.4.1