Uno de los mayores problemas que tenemos los desarrolladores cuando usamos alguna librería o plugin de terceros es no documentarnos correctamente antes de usar dicho componente. Posteriormente, una vez “probado todo” subimos nuestra aplicación a producción y sin darnos cuenta podemos tener una brecha de seguridad bastante importante, concretamente en el caso de usar mal ELMAH, bastante “gorda”. Esto se acentua con el el uso de Nuget, que es un pedazo de herramienta ojo!, pero a veces nos hace ser vagos o puede ser que no haga todo lo que tenga que hacer y nosotros no lo verifiquemos. Añadimos un paquete desde Visual Studio y por arte de magia todo funciona, pero no nos paramos a revisar que es lo que ha hecho el paquete, ¿Qué ficheros ha incluido?, ¿Qué configuraciones ha hecho?…
Nota: No recuerdo a partir de que versión del paquete de ELMAH ha sido corregido un pequeño fallo de seguridad de configuración (Vamos a verlo ahora) a la hora de instalar ELMAH a través del paquete Nuget elmah pero ya había mecanismos en ASP.NET para evitar este fallo de seguridad utilizando el elemento location en el web.cofig, al fin y al cabo ELMAH usa un handler axd que podemos securizar.
Demo
Lo primero será crear una proyecto web que usaremos como ejemplo:

Un sitio MVC como muestra la siguiente imagen:

Voy a publicarlo en un WebSite de Azure para comprobar que ocurre cuando intentamos acceder a ELMAH en remoto:

Una vez creado el sitio, añadimos el paquete de Nuget de ELMAH:


Una vez instalado, publico la aplicación web e intentamos acceder a la consola de errores de ELMAH en la dirección:
http://elmahdemoseguridad.azurewebsites.net/elmah.axd

Como os comentaba antes, el fallo de seguridad debido a una falta de configuración que había antes, ha sido resuelto en las nuevas versiones de ELMAH. Vamos a ver que han modificado y que puede pasar sino tenemos cuidado.
Abrimos el web.config y vamos a la sección de configuración de ELMAH:

Si queremos poder acceder remotamente a la consola de ELMAH, debemos establecer el valor del atributo allowRemoteAccess a true o 1 explicitamente o por defecto aunque lo comentemos o borremos seguiremos sin poder acceder. En versiones anteriores de ELMAH creo que esto no sucedía así.
Vamos a actualizar el valor del atributo allowRemoteAccess para simular que es lo que pasaba antes por defecto con ELMAH y que es como actualmente muchos sitios web se encuentran en internet (Luego lo demostraremos). Además añadimos el errorLog de Xml para grabar los errores de ELMAH.

Volvemos a acceder a nuestro sitio web:

A partir de ahora, cualquier usuario podría acceder a visualizar los errores que se han porducido en el servidor, eso te pasa también si usas incorrectamente el elemento customErrors, aunque para mi lo más preocupante es el tema relacionado con el ROBO DE SESION
Robando la sesión a un usuario
Vamos a modificar la aplicación web para que se produzca un error cuando el usuario visita la página de About

Arrancamos la aplicación y visitamos la página de About y se produce el error

Ahora vamos a la consola de ELMAH para ver el error con más detalle:

Como podemos observar, el campo User está vacío pues estamos accediendo anónimamente a la aplicación. Si pulsamos sobre el enlace Details… podemos ver con todo detalle la traza de la excepción así como un conjunto de variables de servidor. Nos vamos a quedar con HTTP_COOKIE:

Actualmente no hay ninguna cookie de autenticación, así pues vamos a registrarnos en la aplicación con un usuario:

Esto nos creará una cuenta nueva y nos redireccionará a la home autenticados:

Ahora vamos a volver a navegar a About

Volvemos a la consola de ELMAH

Ahora si tenemos un usuario en el campo User. Pinchamos sobre el detalle del error y vamos a ver que contiene HTTP_COOKIE:

Ahora si está presente .AspNet.ApplicationCookie que es la cookie que genera AspNetIdentity y que ha sido registrada por ELMAH cuando se produjo el error.
Ahora vamos a copiar esta cookie y vamos a usar un plugin de Chrome para manipular cookies que se llama EditThisCookie. Para ello abrimos una nueva ventana en modo incognito y verificamos que no hay nadie con login:

Ese icono es EditThisCookie y como bien nos muestra la imagen no hay cookies:

Pulsamos sobre el icono + y añadimos la cookie que copiamos de ELMAH:

Refrescamos el navegador y voliá!!!

Hemos robado la sesión al usuario elmah@demo.es sin unos cracks en seguridad informática.
¡AUN HAY MÁS! Como nos solía recordar el mítico SUPER RATÓN, al ser una página pública, Google indexa la página de ELMAH sino le decimos lo contrario o no la securizamos, así pues podemos consultar a Google sobre sitios que contengan esa Url:

Recomendaciones
Es una mala práctica manipular el atributo allowRemoteAccess para poder acceder remotamente ELMAH. Sería recomendable acceder al servidor a través de un escritorio remoto y acceder de manera local.
Siempre tratar de actualizar este tipo de componentes a la última versión y estar al tanto de posible fallos de seguridad que se encuentren.
Utilizar alguna herramienta para revisar la seguridad de nuestros sitios web como esta:

Un saludo y happy hacking.