Vulnerabilidad – Ayuntamiento de Jaén

Introducción

El martes 27/09/2022 descubrí una vulnerabilidad en la página del Patronato de Deportes del Ayuntamiento de Jaén. En concreto, la vulnerabilidad descubierta ha sido un HTML Injection pudiendo dar lugar a un XSS Stored.

¿Qué es HTML Injection?

HTML Injection es un tipo de vulnerabilidad web que ocurre cuando un usuario puede controlar y puede inyectar código HTML arbitrario en una página web vulnerable. Esta vulnerabilidad puede tener muchas consecuencias, como la divulgación de cookies de sesión de un usuario que podrían usarse para hacerse pasar por la víctima o, en general, puede permitir que el atacante modifique el contenido de la página que ven las víctimas (defacement).

HTML Injection ocurre cuando la entrada del usuario no está sanitizada correctamente y la salida no está codificada. Una inyección permite al atacante enviar una página HTML maliciosa a la víctima. El navegador objetivo no podrá distinguir (confiar) las partes legítimas de las partes maliciosas de la página y, en consecuencia, analizará e interpretará toda la página en el contexto de la víctima.

Ataque

La vulnerabilidad descubierta se ha llevado a cabo en un activo perteneciente al Ayuntamiento de Jaén, en concreto dentro del patronato de deportes.

Podemos hacer click en un espacio “libre” para poder reservar una supuesta pista de deporte: https://dmzwin.aytojaen.es/CronosWeb/Modulos/VentaServicios/Alquileres/ReservaEspacios?token=… (Comentar que se asigna un token por sesión pudiendo dar lugar a otros posibles ataques). Mediante la herramienta de Intruder de BurpSuite he intentado realizar distintos tipos de ataque pero no han sido vulnerables (Sqli, XSS Reflected, etc)

Cargué la el payload Windows-Attack.fuzzdb.txt ya que vi en la url que por detras utilizaba “dmzwin” que a nivel de OSINT podemos buscar información en fuentes publicas y vemos que el ayuntamiento contempla los servicios web en una DMZ y el servidor es una máquina Windows, de ahi el diccionario en concreto contra este sistema operativo.

Volviendo a Burpsuite la vista previa del ataque quedaría:

Observo el siguiente etiquetado <h1>

En este espacio he intentado inyectar en cada uno de los campos de entrada al usuario ciertos caracteres que puedan dar lugar a una inyección. Entre ellas se ha comprobado que no se encuentra sanitizado el tag de html “<h1>”.

A la hora de interpretar el servidor ese etiquetado html lo interpreta el servidor por detrás y dar lugar a una posible inyección html.

El servidor ha interpretado de manera correcta la etiqueta <h1>. He comprobado si era vulnerable a otras etiquetas y no lo he confirmado.

Esto puede dar lugar a un ataque XSS stored. He comprobado la respuesta por parte del servidor:

Detrás actúa un WAF hay restricción de caracteres pero un tercero puede obtener un dominio malicioso de pocos caracteres y se puede llevar a cabo el ataque ya que como se observa, el servidor lanza una petición GET contra un archivo en js.

Se hace una petición GET contra el recurso.

Por ejemplo, realizando una busqueda por dominios similares en caracteres al utilizado en la PoC:

Como se oberva, a nivel de PoC el dominio es x55.is y en la búsqueda de dominios es x55.es. Por lo tanto a nivel de que se lleve a cabo el ataque sería válido puesto que el número total de caracteres es el mismo.

Por unos 10 euros un tercreo podria obtener este dominoi malicioso. Sabiendo que a nivel de JavaScript el servidor realiza una peticion GET contra este dominio, un tercero podria realizar distintos tipos de ataques con una severidad elevada.

Impacto de la inyección de HTML:

• Puede permitir que un atacante modifique la página (defacement). Algunas veces esto puede resultar en un cambio de apariencia total de la página (defacement), o en otros casos, la creación de formularios para engañar a los usuarios.
• Para robar la identidad de otra persona.
• El atacante crea enlaces maliciosos, dentro de HTML inyectado, y lo envía a un usuario.
• El usuario visita la página debido a que la página se encuentra dentro de un dominio de confianza.
• El HTML inyectado por el atacante se procesa y se presenta al usuario solicitando un nombre de usuario y una contraseña.
• El usuario ingresa un nombre de usuario y una contraseña, que se envían al servidor del atacante.

Mitigación de la inyección de HTML:

• Cada entrada debe verificarse si contiene algún código de secuencia de comandos o cualquier código HTML. Se debe verificar si el código contiene algún script especial o corchetes HTML: <script></script>, <html></html>.
• Hay muchas funciones para verificar si el código contiene corchetes especiales. La selección de la función de verificación depende del lenguaje de programación que esté utilizando. He comprobado que la etiqueta <h1> es vulnerable en el campo nombre pero he descartado otras como <tr>,<th>, etc.

Mitigación XSS:

• Sanitizar el input del usuario. En el punto donde se recibe la entrada del usuario, filtre lo más estrictamente posible en función de lo que se espera o de la entrada válida.
• Codificar datos en la salida. En el punto donde los datos controlables por el usuario se emiten en las respuestas HTTP, codifique la salida para evitar que se interprete como contenido activo. Según el contexto de salida, esto puede requerir la aplicación de combinaciones de codificación HTML, URL, JavaScript y CSS.
• Use cabeceras de respuesta apropiadas por parte del servidor. Para evitar XSS en las respuestas HTTP que no están destinadas a contener HTML o JavaScript, puede usar los encabezados Content-Typey X-Content-Type-Optionspara asegurarse de que los navegadores interpretan las respuestas de la manera que desea.
• Política de seguridad de contenido. Como última línea de defensa, puede usar la Política de seguridad de contenido (CSP) para reducir la gravedad de las vulnerabilidades XSS que aún ocurren.

Conclusión

Finalmente despues de unas semanas comprobé si habian “parcheado” la vulnerabilidad que descubrí en el Ayuntamiento de Jaén y efectivamente he visto que lo han hecho.

Si intentas ejecutar la inyección el botón de confirmar compra te impide que puedas efectuar dicha compra. Por lo tanto, vieron la vulnerabilidad cuando contacté con ellos, lo comprobaron y lo han paliaron.

Recibí poco despues un correo por parte del Jefe de Servicio de Departamento de Informática del Ayuntamiento de Jaén agradeciéndome el descubrimiento de la vulnerabilidad.

Gene Spafford

El único sistema completamente seguro es aquel que está apagado, encerrado en un bloque de cemento y sellado en una habitación rodeada de alambradas y guardias armados.