Vulnerabilidad de inyección CRLF

En la anterior entrada comenté sobre el Centro de Gestión de Incidentes Informáticos (CGII), por tanto si gustan saber más de ellos, les invito a post precedente. El día de hoy les traigo la divulgación responsable de una vulnerabilidad de inyección que parecía ya extinta, y muchas veces pasamos por alto en su comprobación, pero que pueden darnos «más de una alegría”, con esto me refiero al punto de la alegría y satisfacción que supone tener un hallazgo relevante después de algunas horas de análisis, no lo hablo desde el punto de vista de un atacante, por favor que nadie se me confunda. Bien pues lo que les traigo el día de hoy es el descubrimiento, parte del análisis, algunas posibilidades y vectores de ataques a partir del hallazgo que me supuso identificar, comprobar y notificar a los responsables una vulnerabilidad de inyección de CRLF.

Lo primero será recordar que es una vulnerabilidad de CRLF Injection y para ello nos podemos quedar con la explicación de OWASP que básicamente nos explica que el término CRLF viene de Carriage Return (retorno de carro) y Line Feed (salto de linea) respectivamente, el primero (CR) representado en decimal como 13 y en hexadecimal como 0D, mientras que LF es representado en decimal como 10 y en hexadecimal 0A, estos valores en hexadecimal será interesantes de recordar. A continuación veremos el motivo.
Ambos valores son empleados para indicar la finalización de una línea y especialmente en el protocolo HTTP nos será de mucha utilidad.

Pues esta vulnerabilidad se da cuando a partir de una entrada de datos (por ejemplo sobre un parámetro HTTP o sobre la propia URL), es posible inyectar dicha secuencia (\r\n) y como respuesta la aplicación web obedece dicha inserción y lo interpreta, por lo tanto lograremos manipular la respuesta y por ende se nos abrirá un abanico de posibilidades (potenciales ataques).

Algunos de estos ataques serían los siguientes:

  • HTTP Response Header Injection
  • HTTP Response Splitting
  • Cross Site Scripting
  • Defacement
  • Log Injection
  • Cookie Injection
  • Phishing
  • Web Cache Poisoning

Podrían darse algunos otros, ya eso dependiendo de la creatividad del atacante. Para esta ocasión vamos a revisar los 4 primeros listados a través de un ejemplo real que he tenido la oportunidad de descubrir, analizar y reportar.

Caso en SICOES (Sistema de Contrataciones Estatales)

Identifiqué esta vulnerabilidad inicialmente analizando las cabeceras de la petición enviada al servidor, en este caso más concretamente me percaté como el valor de la cookie PHPSESSID se ve reflejada en las cabeceras de respuesta de la aplicación web.

Por tanto me dispuse de complementar el valor de la cookie PHPSESSID con una cadena de prueba, en este caso 3 veces la letra B.

Con esto queda demostrado el primer punto ‘HTTP Response Header Injection’.

Acto seguido iremos con la parte de ‘HTTP Response Splitting’, que para ello nos apoyaremos con los siguiente valores: %0D%0A, que como hemos visto anteriormente hacen referencia al retorno de carro y el salto de linea, cadena que nos permitirá demostrar como es posible inyectar una vez más una nueva “cabecera” en la respuesta HTTP de la aplicación web con la ligera diferencia al caso anterior que en esta oportunidad lo hacemos en una nueva línea.

Y por tanto puede ser interepretado como una cabecera “real” de la aplicación web, con todo lo que eso implica (por ejemplo deshabilitar los mecanismos de seguridad que filtran ciertos intentos de XSS). A continuación una inserción que lo hace más evidente:

Pues ahora bien, para darle algo más de impacto a la vulnerabilidades se generó la inserción de código JavaScript que permita representar y reflejar un ataque de ‘Cross Site Scripting’. El payload insertado es bastante estándar.

Al revisar la vista a través del navegador web el resultado será evidente:

Por último y ya tomando en cuenta que podríamos generar por nosotros mismo el cuerpo de la respuesta de la aplicación web se generó una PoC (prueba de concepto) de lo que sería un ataque de ‘Defacement’.

Ya con esto rápidamente demostrado y evidenciado, me tocó tomar las capturas de respaldo y mandar la notificación al CGII, que ya de paso aprovecho para dar las gracias por las gestiones y coadyuvar e intermediar con la mitigación de este fallo. Espero que estas breves líneas hayan sido interesantes para los que llegáis hasta aquí. Finalmente para acabar os dejo la línea de tiempo acontecido con este caso reportado y algunas referencias que nos vendrán muy bien como material de apoyo.

Timeline

  • 2021/04/24: Descubrimiento de la vulnerabilidad
  • 2021/04/25: Notificación de la vulnerabilidad vía CGII
  • 2021/04/27: CGII acepta el reporte y ejecuta procedimiento interno
  • 2021/06/28: CGII informa que la vulnerabilidad ha sido corregida
  • 2021/06/30: Divulgación responsable

Referencias: