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!

Cómo liarla y poner en bandeja a un atacante las sesiones de tus usuarios vía RSS

Continuando con el mismo tema de ayer, el de las trazas en aplicaciones .NET, hoy quería hablar de un componente muy popular que los desarrolladores configuran en muchos entornos de trabajo para tener información mucho más detallada y ajustada a sus necesidades. Se trata del módulo Elmah. Este es otro clásico en las fugas de información, al igual que Trace Viewer y en todas las auditorías de servidores Microsoft IIS se busca para ver si se puede conseguir información útil del entorno.

Figura 1: Cómo poner las cookies de sesión de tus usuarios en bandeja a un atacante

Elmah funciona como un módulo externo que se añade al entorno y que permite una configuración detallada. Una vez dentro del sistema permite una gran personalización de los códigos a de error a tracear, además de poder conseguir conectarse a los datos no solo vía web, sino también vía RSS, vía descarga de ficheros CSV, vía XML o vía JSON.

Figura 2: Elmah en un servidor con HTTPs que permite acceder a todos los datos de las trazas

Es decir, una vez que se localiza que un servidor web tiene este gestor de errores en sus aplicaciones, ya está todo preparado para gestionar las trazas de forma automatizada. Esta es una de las principales características del servicio, y por lo que se hizo tan popular, y por supuesto para una auditoría de seguridad es de lo más conveniente localizarlo, debido a toda la información que pone a disposición del pentester. Nosotros es una de las cosas que buscamos en nuestro servicio de pentesting persistente Faast.

Figura 3: Otra personalización distinta de Emlah

Para localizarlo hay que invocar Elmah.axd en el servidor web. A diferencia de Trace.axd, como no es un módulo estándar, la configuración de su seguridad, aunque también se hace vía Web.Config  se hace en su propia sección, y los mensajes de error que se obtienen cuando se busca y no se encuentra son distintos.

Figura 4: El mensaje de error es un 404 y no un error personalizado
de .NET como el que se obtiene con trace.axd

La configuración correcta que debería hacerse en el Web.Config, en la sección de Elmah es la siguiente. Si se configura el valor como true, entonces se genera el problema. Esto solo debe configurarse en servidores de desarrollo internamente, pero luego debe ser eliminado o configurado para acceso local únicamente.

<elmah/>
<security allowRemoteAccess="false" />
</elmah/>

Haciendo un poco de hacking con buscadores es posible localizar miles de sitios con Elmah habilitado. En la siguiente captura se puede ver que simplemente en Google hay algo más de 15.000 sitios que corren .NET con este módulo de trazas activado.

Figura 5: Miles de servidores con Emlah indexados en Google

Las personalizaciones que podemos encontrar son muchas, pero sea cual sea la personalización de los datos, invocando elmah.axd/download o elmah.axd/rss accederemos a los datos en formato CSV o XML para canales RSS. 

Figura 6: Accediendo a los datos en formato CSV con todas las trazas

Al igual que en el caso anterior de Trace Viewer, no importa si los datos se envían cifrados o no, siempre es posible acceder a todos ellos con las trazas, incluidas por ejemplo las cookies de sesión, tal y como se puede ver en la imagen. Esto hace que la protección de HTTPs no sirva para nada en tus servidores si tienes habilitada las trazas.

Figura 7: Cookies de sesión de un servidor con Https en una traza de Elmah

Si tienes servidores Microsoft IIS con aplicaciones .NET, recuerda quitar Elmah cuando estén en producción, y si eres tú quien los administra o audita, acuérdate de vigilar que no te los cuelen los desarrolladores en tus servidores.

Saludos Malignos!