umakant76705/cve-2022-22978Demostración paso a paso de la omisión de autorización CVE-2022-22978 en RegexRequestMatcher de Spring Security, con configuración de aplicación vulnerable, ejecución de payload y verificación de la corrección.
Según la información que he investigado, esta es una vulnerabilidad relacionada con la clase RegexRequestMatcher del framework Spring Security. En concreto, las aplicaciones que usan RegexRequestMatcher y que en su expresión regular contienen un punto (.) pueden ser evadidas mediante los caracteres \r(%0a) y \n(%0d); de este modo, los atacantes pueden acceder a rutas no permitidas sin necesidad de autenticarse.
Las versiones del framework Spring Security afectadas por la vulnerabilidad:
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. Concretamente, he usado la función de comparación de commits de GitHub entre las versiones 5.6.3 (vulnerable) y 5.6.4 (corregida). Ver el siguiente enlace: Comparing 5.6.3...5.6.4 · spring-projects/spring-security (github.com)
He revisado los cambios en la clase RegexRequestMatcher. Se puede ver que, en la versión 5.6.4, esta clase usa Pattern.DOTALL en lugar del . por defecto de la versión 5.6.3.
Donde:
Pattern: es una de las 3 clases del paquete java.util.regex, que se encarga de procesar las expresiones regulares.Pattern.DOTALL: al usar esta flag, el “.” en la expresión regular coincide con todos los caracteres, incluidos los caracteres de nueva línea como \n , \r.Pattern.CASE_INSENSITIVE: no distingue entre mayúsculas y minúsculas.
Por defecto, el . en una expresión regular coincide con todos los caracteres excepto los caracteres de nueva línea como \n, \r. En ese caso, si hay una función regex que valida el patrón de una cadena, esa función regex no coincidirá si la cadena contiene caracteres de nueva línea. Para evitarlo, se puede usar la flag Pattern.DOTALL.
Sin embargo, si alguien usa intencionadamente %0d en lugar de \n o %0a en lugar de \r, la regex anterior sigue sin coincidir. Por eso, en la versión 5.6.4, se añadió una comprobación para este caso en RegexRequestMatcherTests.java. En concreto, convierte %0d y %0a en \n y \r, respectivamente, antes de comprobar con la regex.
Paso 1: Crea una aplicación web Spring Boot con Spring Initializr y las dos dependencias Spring Security y Spring Web.
Paso 2: Crea un Controller que imprima el texto This is a CVE-2022-22978 demo cuando haya una petición a la ruta /admin/*
Paso 3: Configura un mecanismo de autenticación cada vez que un usuario acceda a la ruta /admin/<bất kì> usando regexMatchers("/admin/.*").authenticated(). Esta es precisamente la vulnerabilidad que los atacantes aprovechan para ver el contenido de las páginas /admin/<bất kì> sin autenticación.
Paso 4: En el archivo de configuración, declara la versión de Spring Security que contiene la vulnerabilidad. Aquí se elige la versión 5.6.3.
Paso 5: Ejecuta la aplicación con el comando gradlew bootRun; el programa usa por defecto Apache Tomcat escuchando en el puerto 8080. Accedemos a la ruta /admin/xyz (cualquier ruta sirve siempre que comience con /admin/).
El resultado devuelve el código 403 Forbidden, lo que significa que no se puede acceder porque no se ha autenticado.
En este punto, aprovechando la vulnerabilidad de la función regexMatchers en Spring Security (versión 5.6.3), que no coincide con los caracteres de nueva línea como \r(%0d) y \n(%0a) → se puede acceder a la ruta anterior sin autenticación mediante el payload /admin/%0dxyz
Lo mismo con el payload /admin/%0axyz
Así, hemos explotado con éxito la vulnerabilidad CVE-2022-22978 con un payload muy sencillo.
5.7.1
Probamos a atacar la web con el mismo payload de antes: /admin/%0dxyz
En este momento, la aplicación ya 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