Prefacio de la Parte 1
Hace un tiempo, un amigo me pidió que le ayudara a revisar los problemas de seguridad del código fuente de un sistema financiero. Después de la gran competencia del año pasado, no había auditado el código durante mucho tiempo, así que lo miré más de cerca. En primer lugar, este sistema utiliza el marco Springboot y no se encontró ninguna vulnerabilidad de deserialización de Java. La vulnerabilidad de inyección SQL fue completamente bloqueada por el método de escritura precompilado y no hubo vulnerabilidad de carga. Fastjson usa la versión 1.2.83 y la versión Log4j2. También es más nuevo. Cuando estaba a punto de rendirme, volví a verificar el archivo de configuración y descubrí el componente thymeleaf. Busqué varias ideas en el código y finalmente encontré 4 vulnerabilidades de inyección de plantilla de thymeleaf.
Al investigar la vulnerabilidad de inyección de plantilla de thymeleaf, descubrí que hay muchos artículos en Internet, pero algunos de ellos son diferentes y algunos tienen errores . De esta manera, ABC_123 consultará artículos en línea, escribirá código para construir el entorno, probará los métodos de utilización de la vulnerabilidad de inyección de plantilla de thymeleaf en diferentes situaciones y compartirá los resultados de la prueba con todos.
Se recomienda que todos establezcan la cuenta pública "Laboratorio Xitan" como una estrella; de lo contrario, es posible que no la vean. Porque las cuentas oficiales ahora pueden mostrar imágenes grandes solo para cuentas oficiales leídas con frecuencia y destacadas. Cómo operar: Haga clic en [...] en la esquina superior derecha y luego haga clic en [Establecer como estrella].
Parte 2 Proceso de investigación técnica
Errores encontrados al construir el medio ambiente
1 El primer hoyo
Cuando comencé a construir el entorno ABC_123, me metí en un gran pozo y descubrí que el entorno descargado de github no se podía probar con éxito. Después de repetidas pruebas, descubrí que se debía a que el número de versión no estaba configurado en el pom. xml del entorno de vulnerabilidad. La última versión de thymeleaf se usó de forma predeterminada. componente, y la última versión del componente thymeleaf no tiene una vulnerabilidad de inyección de plantilla. Tal vez el personal de seguridad descubra nuevos métodos de omisión en el futuro .
2 El segundo hoyo
Las versiones más nuevas de thymeleaf con vulnerabilidades requieren declaraciones de omisión que pasan %0A y %0D para ejecutarse. Si la prueba aún falla, recuerde que necesita codificar en URL los caracteres especiales en la carga útil. Si realmente no sabe qué caracteres especiales deben codificarse en URL, entonces codifique en URL toda la carga útil como se muestra en la siguiente figura . .
Conocimientos básicos previos
Las expresiones de las plantillas de Thymeleaf incluyen lo siguiente: expresión de variable: ${...}, expresión de variable de selección: *{...}, expresión de mensaje: #{...}, expresión de URL de enlace: @ {...} , expresión de fragmento: ~{...}. Por lo tanto, muchas declaraciones de inyección de plantilla de thymeleaf ${...} se pueden usar con éxito si se reemplazan por *{...} .
A continuación, veamos un punto de conocimiento básico, como se muestra en la siguiente figura. El código de retorno "bienvenido" en la figura se refiere al nombre de la vista de retorno. thymeleaf agregará el prefijo predeterminado /templates y el sufijo .html al nombre de la vista de bienvenida. , que es el resultado final. El nombre de la vista es /templates/welcome.html y nuestro modelo de datos se traerá con él .
Con los conocimientos básicos establecidos, hablemos de las tres formas de vulnerabilidad de inyección de plantilla de thymeleaf.
En el primer caso, el contenido devuelto es controlable.
Es más probable que esta situación cause vulnerabilidades de inyección de plantilla de thymeleaf. Una vez que los datos enviados por el usuario pueden pasarse a la declaración de devolución, el atacante puede enviar una declaración de inyección de plantilla maliciosa para hacer que el componente de thymeleaf realice un análisis de plantilla, provocando una ejecución de código. vulnerabilidad.
Cuando comencé a observar esta vulnerabilidad de inyección de plantilla de thymeleaf, estaba confundido por los diferentes métodos de escritura de código Java en Internet. Finalmente, lo probé y descubrí que no había mucha diferencia. De hecho, el atacante puede controlar el retorno . valor, es posible causar una vulnerabilidad de inyección de plantilla, pero las declaraciones de explotación serán diferentes en diferentes situaciones . ABC_123 resumió varios artículos en línea y varios recursos de github y descubrió que existen aproximadamente cuatro formas de escribir código Java con vulnerabilidades:
Después de las pruebas, se descubrió que la misma declaración se puede utilizar para jugar con la calculadora con éxito.
En el segundo caso, la ruta URL es controlable.
Esta situación es relativamente rara y requiere que la clase de retorno del método sea nula. En este caso, el nombre de la vista se obtendrá de la URL, la ruta URL se utilizará como nombre de la vista y se llamará a la vista de plantilla para analizar gramaticalmente.
A continuación, veamos el método de escritura más utilizado en artículos en línea. Es obvio que la prueba puede tener éxito (la carga útil se publica directamente aquí para facilitar la visualización. Cuando realmente la prueba, debe codificar la URL) . carga útil ).
A continuación, mire la situación de /doc2. Aquí reemplacé @GetMapping con @RequestMapping. Descubrí que la vulnerabilidad también se puede explotar con éxito , y parece que no solo las solicitudes GET, sino también todo tipo de solicitudes se pueden explotar con éxito.
Incluso las solicitudes PUT se pueden probar con éxito, lo que no esperaba. Parece que cuando la ruta URL es controlable, esta vulnerabilidad no solo se activa mediante solicitudes GET .
En este caso, la prueba definitivamente no tiene éxito porque @RequestParam modifica el documento en el código .
En el tercer caso, el contenido de la plantilla es controlable.
Es muy raro que el contenido de la plantilla sea controlable, por lo que no entraré en detalles. ABC_123 envió una captura de pantalla del código que probó con éxito para referencia de todos. Se estima que en el uso real, pocos programadores escribirán un código como este, pero ¿qué pasa si lo encuentran?
Situaciones donde no existen vulnerabilidades y sugerencias para repararlas
1 Usa @ResponseBody o @RestController para decorar
@RestController es una anotación en el marco Spring que combina las funciones de las anotaciones @Controller y @ResponseBody para simplificar el desarrollo de servicios web RESTful.
2 Utilice redireccionamiento: o reenvío: modificación
De acuerdo con la definición de Springboot, si el nombre comienza con redirigir:, ya no se llamará a ThymeleafView para analizar, y se llamará a RedirectView para analizar el valor de retorno del controlador. Lo que hay que tener en cuenta aquí es que, además de redirigir:, también existeforward:, que rara vez se menciona en Internet .
3 Establecer en HttpServletResponse
Dado que el parámetro del controlador está configurado en HttpServletResponse, Spring cree que ha procesado la respuesta HTTP, por lo que no se producirá la resolución del nombre de la vista y no habrá vulnerabilidad de inyección de plantilla.
Resumen de la Parte 3
1. ABC_123 escribirá un artículo especial más adelante para resumir las diferentes versiones de las declaraciones de prueba de vulnerabilidad de inyección de plantillas de thymeleaf y los métodos de omisión de WAF. Bienvenido a seguir mi cuenta pública "Xitan Lab".
La cuenta pública se centra en compartir tecnología de seguridad de red, incluido el análisis de eventos APT, ataque y defensa del equipo rojo, análisis del equipo azul, pruebas de penetración, auditoría de código, etc. Un artículo por semana, 99% original, así que estad atentos.
Contácteme: 0day123abc#gmail.com (reemplace # con @)