Cómo encontramos tu HTTP Response Splitting olvidado

Las vulnerabilidades de HTTP Response Splitting pueden ser utilizadas para hacer muchos ataques peligrosos. De hecho, están catalogadas con un nivel de criticidad alto y cuando aparecen se deben cerrar lo antes posible. La idea de una vulnerabilidad de HTTP Response Splitting es que un atacante es capaz de inyectar código en la cabecera de la respuesta HTTP y por tanto reescribir toda la página que llega al cliente. Esto se produce cuando se puede inyectar en un campo que va uno de los campos de la cabecera y el atacante decide escribir, en su inyección, campos HTTP para cambiar la respuesta por completo.

Figura 1: Cómo encontramos tu HTTP Response Splitting olvidado

Nosotros nos encontramos con uno de ellos hace poco utilizando nuestro sistema de Pentesting Persistente Faast con el que monitorizamos la seguridad de las webs haciendo pentesting 365 días al año de manera continua, y aplicando un algoritmo voraz, es decir probando todo lo que haya que probar en cada punto. La gracia en el artículo de hoy no está en la vulnerabilidad en sí, sino en cómo el sistema recursivo funcionó para localizar el bug, que ya está corregido, así que os lo cuento rápidamente hoy sábado.

Figura 2: Bug de HTTP Response Splitting detectado por Faast en un proyecto

El comienzo fue bastante sencillo. Como en cualquier proceso de Ethical Hacking, el motor de Faast tiene una fase de Discovery en la que busca en todos los lugares posibles los recursos expuestos en Internet. Por supuesto, también haciendo hacking con buscadores. En una de esas búsquedas apareció una URL que, como tantas otras, y al igual que se hace con FOCA, pasa a ser analizada por el motor de Faast.

Figura 3: Descubrimiento de una URL indexada y extracción de URLs para Spidering

El código HTML de la página de respuesta de esa URL se pasa por una serie de plugins, y uno de ellos lo que hace es, por supuesto, buscar nuevas URLs a partir de enlaces en la página. Esto es una tarea básica en cualquier pentesting. Hacer spidering a partir de una URL, tal y como se explica en el libro de Hacking Web Technologies. Nosotros, antaño, lo hacíamos con Burp y luego lo pasábamos a FOCA.

Figura 4: Proceso de Spidering con Burp

De esa URL sacamos más URLs con directorios y recursos enlazados. Y, por supuesto, cada directorio que es descubierto se pasa por una serie de plugins de forma recursiva. En búsqueda de cosas como fallos de Directory Listing, de IIS Shortname, Múltiple Choices, errores no controlados, etcétera.

Figura 5: Descubrimiento de un DWSync.xml

Una buena batería, donde también se buscan los sensitive files, tipo .DS_Store, WS_FTP.log o ficheros .listing, por poner algún ejemplo. En este caso, lo que apareció fue un DWSync.xml de los que se quedan cuando alguien sube una web usando Dreamweaver, como ya hemos hablado muchas veces.

Figura 5: Descubrimiento del fichero CGI olvidado por medio de Spidering

Esto es un leak en sí mismo, y como tal quedó reportado en el proyecto para los responsables de seguridad, pero de él sacamos nuevas URLs, como la que se puede ver en la captura del mismo.

Conclusiones

Al final, ese CGI (Common Gateway Interface) resultó ser vulnerable a HTTP Response Splitting. Un fichero que hacía mucho tiempo que se había quedado sin utilidad en la web, pero que aún estaba presente en el servidor. No lo habían limpiado, y el motor de Faast, buscando de manera persistente dio al final con él. 

Figura 6: Encadenamiento recursivo de plugins en Faast hasta llegar al HTTP Response Splitting

Si quitas algo de la web, quítalo. Este es uno de los errores más comunes que encontramos en los proyectos de pentesting persistente - como los que os dejé de Apple - y a partir de ellos se pueden localizar muchas cosas peligrosas. En este caso, un HTTP Response Splitting. Si quieres, puedes pedirnos un piloto de Faast sin compromiso para tu empresa a través de nuestra web de contacto de ElevenPaths.

Saludos Malignos!