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!