Sí, un Task Manager en tu sitio web... sin darte ni cuenta!!

Hacía tiempo que no tenía tiempo de investigar algunos de los leaks que mi amigo rootkit me envía, pero aprovechando que en las siestas de verano he sacado algo de tiempo, he mirado este de WestWind Technologies que me ha resultado peculiar.

Figura 1: Un Task Manager en tu servidor web... Sin darte ni cuenta!!

A simple vista, cuando lo ves, es la típica página de administración de servicios Microsoft Internet Information Services que la propia Microsoft ofrecía desde las primeras versiones de su servidor web & FTP. En ella, se pueden ver un montón de opciones, que van desde subir ficheros, hasta tocar configuraciones del servidor, lo que puede resultar muy peligroso. No debería estar expuesta a Internet.

Figura 2: Panel de control de WestWind Technologies

Por supuesto, cuando haces clic en los enlaces, todos llevan a ficheros que están protegidos, ya que de no estarlo los servidores durarían unos segundos en la vorágine de la red, pero sin embargo, se pueden hacer cosas muy curiosas con este página web de administración que no es de Microsoft, sino de Westwind Technologies.

Figura 3: Firma que aparece en el panel del fabricante

Haciendo un poco de Hacking con buscadores con la firma que la compañía pone a sus paneles de administración web se pueden encontrar un buen número de otras herramientas de ayuda, y ejemplos de la compañía, pero yo me voy a centrar en la original.

Figura 4: Buscando paneles de Westwind indexados en Google. Bing y Shodan dan aún más.

Aquí tenéis otro de los paneles de Westwind Technologies con muchas Demos "peligrosas" que recuerdan a los ejemplos que instalaba Microsoft FrontPage en Server-Side.

Figura 5: Otro panel de Westwind Technologies con "Demos" jugosas

En la página original, lo primero que llama la atención es que se puede acceder a la ruta de instalación del software, lo que ya es un leak en sí mismo que puede ser de utilidad en ataques LFI o RFI, como hemos visto en tantas ocasiones (véase Hacking Web Technologies).

Figura 6: Ruta de instalación del sitio web

La segunda cosa que llama poderosamente la atención es que hay un buscador de procesos... What?. Sí en la parte inferior del panel puedes poner una letra por la que quieres filtrar, y accedes a la lista completa de los procesos del sistema - más los del servicio web - que están corriendo, con su PID incluido si pasas el ratón por encima de la opción de matar el proceso, ya que lo usa como parámetro POST.

Figura 7: Lista de procesos que comienzan por s

Con ello, puedes averiguar todo el software de seguridad que está en ejecución, pero también si tiene DNS, servicios extras, etcétera. En este ejemplo se puede ver que este servidor utiliza un antivirus avp.exe que apunta directamente a Kaspersky.

Figura 8: Procesos del antivirus avp.exe

Pero también se puede saber si el administrador de este sitio navega, como en este caso, donde se puede ver cómo se está utilizando el web browser de Moxilla Firefox. Todo esto es debido a que el formulario que refresca la lista de procesos no está llamando a ningún otro fichero del servidor web, sino que es una petición directa sobre la página web que estamos visitando. Es decir, es el propio panel el que gestiona las llamadas al sistema para acceder a la lista de procesos. Y además hay opción de parar procesos, o actualizar constantemente para ver si hay cambios.

Figura 9: Procesos de Firefox

En la imagen superior se puede ver cómo el administrador ha dejado de utilizar Firefox, o bien alguien ha matado los procesos, o simplemente ha cambiado de navegador de Internet. Si alguien pudiera matar desde un sitio web un proceso - incluso los de los vhosts - corriendo en escritorio daría medida de cuáles son los privilegios con los que corre el sitio web (probablemente sin Application Pool), el servicio web, y la falta de uso de niveles de integridad - luego apuntaría a versiones de Windows concretas -.

Figura 10: Procesos de Firefox cerrados

Lo cierto es que estos paneles de Westwind Technologies son de gran utilidad para muchos administradores web, pero nunca, nunca, nunca, deberían estar expuestos a Internet sin estar protegidos por credenciales.

Saludos Malignos!

Preguntas del examen de Seguridad en Aplicaciones Web de la UEM 2017

Ayer fue el día en que mis alumnos del Master de Seguridad de la UEM tenían que hacer el examen del modulo de Seguridad en Aplicaciones. Este año, además, aprovechamos para ir en uno de los días de clase a la RootedCON, así que entre las preguntas que cayeron estaba una relativa a la charla que allí dimos. 

Figura 1: Preguntas del examen de Seguridad en Aplicaciones Web de la UEM 2017

Como suelo hacer, os dejo lo que les pregunté. Cosas sencillas, para que me quede claro si han aprendido los conceptos básicos de este módulo. Os las dejo por aquí por si los que estáis estudiando las queréis comprobar. Además, os dejo enlaces a algunos artículos que detallan las respuestas.

1.- Dada una aplicación PHP que utiliza MySQL como motor de base de dato. y es vulnerable a SQL Injection en el programa miprog.php?id=1 que muestra noticias. Explicar cómo sería un ataque de Blind SQL Injection para sacar la versión del motor de la base de datos.

Los ataques Blind SQL Injection se basan en hacer una booleanización de los datos que se buscan utilizando patrones de reconocimiento de las repuestas True o False basados en mensajes de error, cambios en las respuestas de la web, tiempos de respuesta o sumas lineares de valores ASCII. Una vez encontrada la vulnerabilidad se puede explotar manualmente con consultas del tipo miprog.php?id=1 and 54>ASCII(Substr(version(),1,1). En el vídeo se puede ver la explotación SQLbFTools

Figura 2: Blind SQL Injection en MySQL con SQLbTools

2.- Dada una aplicación PHP que utiliza MySQL como motor de base de dato. y es vulnerable a SQL Injection en el programa miprog.php?id=1 que muestra noticias. Explicar cómo sería un ataque de Time-Based Blind SQL Injection para sacar la versión del motor de la base de datos.

En este caso es necesario utilizar un ataque de Time-Based Blind SQL Injection. En MySQL se pueden utilizar las funciones de retardo de tiempo explícito "sleep()" a partier de MySQL 5 o superior, las funciones intensivas en cómputo Benchmark o los ataques con Heavy Queries.

Figura 3: Time-Based Blind SQL Injection using Heavy Queries

3.- Una aplicación web cuenta con un programa download.php?file=doc.pdf que es vulnerable a técnicas de LFI (Local File Inclusion) o RFD (Remote File Downloading). Explica cómo sacarías las credenciales de acceso de la aplicación a la base de datos.

Si se pueden descargar ficheros del servidor con un Local File Inclusion o con técnicas de Remote File Downloading, al final te pueden inspeccionar el código Server-Side para ver dónde está configurada la conexión a la base de datos. En este artículo se explica un proceso completo: Cómo te pueden robar la Base de Datos de tu sitio web con bugs de Path Transversal & Local File Inclusion.

4.- Una aplicación ASP tiene un formulario de login vulnerable a SQL Injection en el campo de usuario. Explica alguna combinación que pudiera utilizarse para intentar hacer login con el usuario Chema sin conocer la password del mismo.

Esta es una pregunta básica de SQL Injection. Dependiendo del motor de bases de datos y la creación de la consulta SQL que haya hecho el programador habrá muchas pequeñas diferencias (incluso si está hecho con Inverted SQL Queries). Pero lo más básico sería probar un Chema';--

5.- Dada una aplicación ASP que muestra un listado de alumnos de una clase con nombre y apellidos con el siguiente comando SQL:

Select nombre, apellidos from alumnos where clase=‘+$clase+’;

Donde $clase se recibe como parámetro GET mediante listado.asp?clase=primeroA. Describe cómo sería un ataque Inband para sacar los usuarios y contraseñas de la tabla USERS (UID,PWD) por pantalla

En este caso se trata de un ataque UNION para usar el mismo Recordset que utiliza el programador, así que bastaría con hacer que la consulta original no devolviera ningún dato y enlazar la nuestra. Algo como: clasequenoexiste' UNION SELECT UID,PWD FROM USERS;--

Figura 4: Feliz 15 aniversario SQL Injection

6.- Describe en qué consiste un ataque de SQL Injection OutBand basado en errores ODBC

En la conferencia de arriba lo tenéis descrito. Se trata de conseguir ver la información que se quiere extraer de la base de datos usando los mensajes de error ODBC. Esta técnica fue descrita por David Litchfield en el año 2001 en el paper: Web Application Disassembly with ODBC Error Messages. Yo la utilicé combinada con los ataques de Serialized SQL Injection tiempo atrás.

7 .- Describe en qué consiste el ataque de Rogue DirtyTooth Speaker contra terminales iOS y qué mecanismos podría poner Apple para minimizar su impacto.

Esta pregunta es fácil si has atendido a la conferencia de la RootedCON y has leído el artículo en cinco partes que publiqué esta semana: DirtyTooth Hack.

Figura 5: Cómo funciona DirtyTooth Hack

8.- Una página web tiene un login con un fichero login.swf que no hace Callback. ¿Qué habría que probar?

Tan sencillo como decompilar el SWF a ver qué sorpresas nos trae. Parece mentira, pero aún nos encontramos sitios en los que el login se basa en eso.

9.- Una tienda online usa un sistema de venta de productos pero un cliente ha comprado un producto por la mitad de su precio. ¿Cuál puede haber sido el fallo? ¿Cómo se ha podido explotar?

Probablemente se trate de un error clásico en el que el programador ha utilizado el precio que le llega desde el cliente en lugar del precio de la base de datos. El atacante puede cambiar ese valor con un proxy de interceptación igual que en el caso de La compañía de vuelo low-cost y la tasa de facturación anticipada. En el libro de Hacking Web Technologies se explican en detalle estas técnicas.

10.- Explica en qué consiste una tautología en un ataque de SQL Injection.

Las tautologías son valores que son siempre ciertos. Se usan para conseguir manipular el funcionamiento de una web inyectando condiciones que anulan el resto de las comprobaciones. Especial mención de esto al artículo de las "quasi-tautologies" que también pueden utilizarse.

Hasta aquí el examen que hicieron mis alumnos. Ahora espero que las notas que saquen todos sean muy buenas y que te haya entretenido ver lo que aprenden en clase.

Saludos Malignos!

Aplicaciones .NET con campos ViewState sin firmar o cifrar

Las aplicaciones web escritas en ASP.NET utilizan desde su concepción hace ya muchos años un campo oculto llamado ViewState que controla el flujo de datos y estados de la aplicación en todo momento. Este campo se utiliza para garantizar la privacidad y la integridad de la información en cada uno de los intercambios de información que se producen entre el servidor web y el cliente web. Es decir, para garantizar que la información no ha sido manipulada y que además se ha transferido de forma correcta en todos sus campos.

Figura 1: Aplicaciones ASP.NET con campos ViewState sin firmar o cifrar

Para poder conseguir estos objetivos con garantías, ViewState debe ir firmado y cifrado, pero esto no siempre es así, sobre todo en aplicaciones más antiguas que puedan estar aún en los servidores de muchas organizaciones.

Firmado de ViewState

Desde ASP.NET v.1.0 los campos ViewState van firmados por con un código MAC (Machine Authentication Check), que no es más que un CheckSum de toda la información que se encuentra almacenada dentro de ViewState. La idea es tan sencilla como que una vez que se decide qué se tiene que transferir, se hace una codificación en BASE64, se hace el CheckSUM de la misma y se calcula el valor MAC.

Figura 2: Flujo de utilización de ViewState

De esta forma, cuando se carga la página que se debe renderizar o cuando se envía de vuelta al servidor se puede comprobar si esta ha sido modificada verificándola con el valor de ViewState. Si no coincide, el servidor dará un error de aplicación.

Figura 3: Error .NET de fallo de validación de MAC en el campo ViewState

Esto está configurado a TRUE por defecto en la propiedad EnableViewStateMac desde la versión ASP.NET 1.0, por lo que es raro encontrar aplicaciones que no manejen el campo ViewState firmado, pero si esto sucediera entonces las funciones de integridad de la web aportadas por ASP.NET no serían robustas. 

Cifrado de ViewState

En cuanto al cifrado del campo ViewState no se activó por defecto hasta la versión ASP.NET 2.0. donde para configurar que se cifre el contenido almacenado - y no vaya solo codificado en BASE64 y con un código MAC - hay que configurar los valores decryptionKey y decrypt de las propiedades de MachineKey, tal y como se explica en este artículo de la MSDN. 

Figura 4: Generación de claves de MachineKey

La claves para algunas versiones de ASP.NET, como se puede ver en la imagen superior, se pueden crear y renovar desde el servidor IIS 7, tal y como se explica en este blog de MSDN.

Decodificar campos ViewState sin cifrar

No es demasiado común encontrar aplicaciones ASP.NET que tengan el campo ViewState sin cifrar, pero aún así, en nuestro sistema de Pentesting Persistente Faast, uno de los plugins que se centra en la seguridad y vulnerabilidades de este tipo de tecnologías, sí que lo revisa. En el siguiente ejemplo se puede ver una web localizada en producción con el campo ViewState sin cifrar.

Figura 5: Detección de aplicación ASP.NET con ViewState sin cifrar

Cuando el campo está sin cifrar, lo único que sucede es que se pueden acceder a todos los datos en tránsito, y entre ellos pueden ir las cookies de sesión que se estén intercambiando, o cualquier otra información sensible de la web.

Figura 6: El campo ViewState localizado sin cifrar en un decodificador

El código para decodificar un campo ViewState sin cifrar es conocido - tenéis uno disponible en esta pregunta de StackOverflow -, y es fácil localizar decodificadores online que te muestran todo el contenido dentro del mismo, tal y como se puede ver en la imagen siguiente.

Figura 7: Contenido decodificado de un ViewState sin cifrar

La firma y el cifrado de ViewState ayudan a hacer mucho más robustas las aplicaciones ASP.NET y a protegerlas frente a ataques avanzados, por lo que es una recomendación de seguridad básica en estos entornos. Además, los campos ViewState ayudan también a gestionar la seguridad frente a ataques CSRF, pero eso exige otras configuraciones de las que ya os contaré en otro artículo.

Saludos Malignos!

OWIN y Katana: Cómo crear apps Asp.Net del futuro

OWIN (Open Web Interface for .NET) es una nueva especificación abierta definida por miembros del propio grupo de Asp.Net, cuya finalidad es desacoplar la dependencia entre el host de la aplicación web, y la propia aplicación. ¿Qué ha llevado a la necesidad de la especificación OWIN? Para responder a la pregunta, es necesario hacer una pequeña retrospección a la evolución de la plataforma Asp.Net.

Un poco de historia de Asp.Net

En el año 2002 nace Asp.Net, integrada en la primera versión de .Net Framework. Esta nueva tecnología mantuvo gran similitud con su antecesor, el clásico ASP, para no provocar un cambio completo en la forma en la que los desarrolladores construían sus aplicaciones. Además optó por el camino de lo que llamaron WebForms, formularios que se construían de una manera muy similar a como se hacía para aplicaciones escritorio (WinForms), y así atraer a los desarrolladores desktop hacia la web.

Durante varios años Asp.Net fue evolucionando de manera paralela a como lo hacía el propio .Net, ya que estaba completamente atado a éste por ser un framework monolítico. Todo Asp.Net se apoyaba en System.Web, que es parte del framework.

Entre 2007 y 2008 surge Asp.Net MVC, un framework de desarrollo web no orientado a Webforms, sino utilizando la arquitectura Modelo-Vista-Controlador. Además del cambio de filosofía que esto provocó, este framework no se incluía en el monolito .Net Framework, lo que permitía una evolución completamente independiente. Pero su ejecución seguía dependiendo de System.Web, por lo que la única manera de alojar una aplicación web basada en tecnología Microsoft, era a través de su servidor web, Internet Information Services (IIS). En este momento se empieza a ver la problemática que provoca todo el acoplamiento existente entre la aplicación web, .Net framework, y el host de aplicaciones.

Junto con la liberación de MVC4 surge Web API, una nueva API de desarrollo de aplicaciones web, pero esta vez sí, sin ningún tipo de dependencia sobre System.Web.dll. Y para marcar más esta independencia, se incluye un self-host para hospedar estas nuevas aplicaciones sin necesidad de IIS.

El nacimiento del Open Web Interface for .NET y Katana

Así, con todo lo aprendido durante la evolución de Asp.Net, y basándose en la filosofía de Web API, nace OWIN para crear la mayor independencia posible entre los componentes de un desarrollo web. Por tanto, la arquitectura para una aplicación OWIN queda de la siguiente manera:

• Host: Proceso del sistema que recibe toda la comunicación Http. (IIS, servicio Windows….)• Server: Implementación del protocolo Http que se encuentra alojado en el Host. Las peticiones son gestionadas según marca la definición OWIN.• Middleware: Son los componentes que reciben las peticiones del server con el formato OWIN para procesar (o no) una respuesta. Estos componentes se ejecutan de manera encadenada en una pipeline, y evidentemente, tienen funcionalidades diferentes. A cada componente se le dotará de una funcionalidad concreta, pudiendo “romper” la cadena de ejecución para retornar un valor concreto al cliente en el caso de que así se desee, o continuar la ejecución hacia el siguiente componente.• Application: La propia aplicación web, construida apoyándose en los frameworks que se consideren oportunos (y compatibles con la definición Owin), como por ejemplo MVC o Web API.

Figura 1: Componentes de la arquitectura OWIN

Como se ha citado anteriormente, OWIN no es más que una especificación, y es aquí donde entra Katana, la implementación (una de ellas) de este estándar, que ofrece toda la funcionalidad de OWIN mediante Clases y Helpers para el manejo de peticiones y creación de respuestas HTTP.

Creando una primera aplicación

Una vez vista la teoría y con la nueva arquitectura en mente, ya se puede comenzar con el desarrollo de la aplicación.

1. Se crea un nuevo proyecto con la plantilla de aplicación Asp.Net vacía.

Figura 2: Creación de una aplicación Asp.NET vacia

2. Mediante el gestor de paquetes nuget, se instalan los paquetes de Katana en el proyecto, todos pertenecientes al namespace OWIN:

• Install-Package Microsoft.Owin.Host.SystemWeb
• Install-Package Owin.Extensions
• Install-Package Microsoft.Owin.Diagnostics

Figura 3: Instalación de los paquetes de Katana con nuget

3. Se agrega una nueva clase al proyecto con nombre Startup.cs. En ésta, se crea un método void de nombre Configuration, y un parámetro de tipo IAppBuilder (del namespace Owin). En el paquete Owin.Diagnostics se incluye un método de extensión llamado UseWelcomePage, creado especialmente para comprobar el correcto funcionamiento del proyecto.

Figura 4: Creando la clase Startup

4. Una vez compilado el proyecto, al ejecutarse debería aparecer en el navegador la página Welcome.

Figura 5: Welcome Page

Como se puede observar hasta el momento, el objeto app del método Configuration contiene todo el contexto necesario de la petición y la respuesta HTTP, que son los parámetros que los componentes middleware se encargarán de utilizar. En este primer ejemplo, el middleware WelcomePage se encarga de escribir y enviar la respuesta directamente, para cualquier petición que se realice. Indagando un poco más en el método, se ve cómo es posible utilizar este middleware para un path concreto, es decir, solo respondiendo a las peticiones que se realicen a un path concreto.

Figura 6: middleware para el path Welcome

Ahora la página welcome solo se mostrará para peticiones realizadas al path /Welcome, mientras que para cualquier otra se mostrará un error 403. ¿Por qué ocurre esto? Básicamente porque se ha elegido IIS como servidor, y en el caso de que ningún middleware gestione la petición, ésta llegará a IIS, y realizará el comportamiento que tenga asignado, en este caso mostrar el error de listado de directorio no permitido.

Ampliando la aplicación con la creación de nuevos middleware

Evidentemente lo útil de los componentes middleware es crearlos según las necesidades de la aplicación, pudiendo delegar diferentes acciones a cada uno de ellos, como estadísticas, autenticación y respuesta final. De una manera rápida, se pueden crear middleware apoyándose en expresiones lambda (anónimas) pudiendo utilizar el contexto para analizar la petición y crear la respuesta, como se puede ver en el ejemplo:

Figura 7: Extendiendo el middleware

Aunque para un primer acercamiento es suficiente, para la creación de componentes middleware existe una clase abstracta llamada OwinMiddleware, que se puede implementar con la lógica que se le quiera otorgar. En este sencillo ejemplo, se van a crear tres componentes que se encargarán de crear la respuesta una vez estén anidados en el pipeline.

Figura 8: Componiendo una respuesta con varios métodos

Una vez definidos los middleware propios, es suficiente con llamarlos (en el orden correcto) desde el método Configuration utilizando el método genérico Use tantas veces como middleware se necesiten.

Figura 9: Componiendo la respuesta con la llamada a los métodos

La respuesta desde el navegador a cualquier recurso de la aplicación debería ser como se muestra en la imagen:

Figura 10: Respuesta obtenida

Y usar Latch en Asp.NET

Katana ofrece mucha más funcionalidad de la que se ha visto, pero esto es un pequeño acercamiento al nuevo rumbo por el que Asp.Net quiere caminar, que además también se integra perfectamente con Latch. El uso de middlewares permite modularizar la aplicación web y minimizar las dependencias entre módulos, por lo que el reemplazo de una funcionalidad concreta solo supone el rediseño o reimplementación de un middleware concreto. ¿Qué tal un middleware cuya única finalidad sea comunicarse con el servicio Latch, una vez comprobada la autenticación?

Figura 11: Integrando latch en aplicaciones Asp.Net 

Esto no sería nada difícil de realizar, y habría que hacer un uso análogo al que se describe en este documento de 16 páginas que explica cómo integrar con el SDK de .Net y/o el plugin de Latch para el .Net Login en cualquier aplicación Asp.Net que vayas a realizar.

Autor: Ioseba Palop 
Software Engineer en Eleven Paths

Desenmascarando al control invisible en ASP.NET

Ayer nuestros amigos de Cyberhades, que no solo nos escriben grandes Microhistorias, sino que nos mantienen informados de lo que pasa en el mundo de las conferencias, recopilaron todas las charlas de BlackHat Europe 2013. Como tenía algo de tiempo me puse a revisarlas, y leerme las que más curiosidad me fueron generando. Algunas estaban mejor, otras peor, pero en casi todas aprendí algo nuevo.

Me llamó la atención la charla en la que utilizaban un SSID WiFi malicioso para hacer ataques XSS o CSRF a paneles de control, la charla sobre la botnet creada con HTML5 para usando el LocalStorage y WebGL llegar a ejecutar comandos en la GPU y crackear como un ninja usando los equipos zombies. También citaré la de PowerShell for Pentesting, que por algo escribimos nosotros un libro de PowerShell. Por supuesto, en esta colección de charlas hay que citar TIME, a perfect CRIME?, una evolución de los ataques BEAST y CRIME basada en mediciones de tiempo a ciegas. Pasada.

Sin embargo, la que más me gustó de toda por su organización y utilidad práctica fue la de Invisibility Purge. Esta sesión se basa en descubrir controles ASP.NET del lado del servidor que están ocultos al cliente, para conseguir acceder a funciones en test, ocultas o prohibidas a un determinado usuario.

La charla comienza con el nivel más sencillo, en la que el control ha sido comentado en el código fuente del cliente. Algo que es tan fácil de evadir como descomentarlo.

Figura 1: Control ASP.NET comentado en el código del cliente

Luego se complica un poco y pasa a los controles deshabilitados y a los ocultos desde el lado del servidor, con lo que no se puede ver nada en la página cliente. Sin embargo, utilizando un poco de Hacking con Buscadores, caché en el navegador de previas versiones de la página y errores forzados ASP.NET salen muchos de ellos.

Figura 2: Mensaje de error ASP.NET que indica que Event Validation está activo

Para terminar, la charla se lo pone complicado, y termina modificando las llamadas teniendo que manipular el ViewState y lidiar con Event Validation activado.

Figura 3: Nivel Nightmare

Dentro de esta presentación han publicado también las herramientas que han usado, que están en SCIP Project dentro de Google Code.

Figura 4: Herramienta SCIP liberada. Se integra con OWASP ZAP Proxy.

Más trucos a tener en cuenta cuando se hace una auditoría de aplicaciones .NET, que la puerta que abre el camino a la sala del trono se encuentra en el lugar menos esperado.

Saludos Malignos!

Error 404 en aplicaciones ASP migradas a IIS 7.X

Ya os he contado muchas veces que FOCA analiza los errores 404 de JSP, ASPX, TCL en WebDNA, etcétera, para extraer información valiosa de fingerprinting. Estos errores suelen dar datos que te pueden ayudar a dibujar la red interna, o conocer mejor la estructura de seguridad del sitio. Este es el caso de este error de IIS 7.X que es bastante común encontrar aplicaciones ASP migradas a esta versión.

Figura 1: Error 404 en IIS 6

El Error 404 que aparece en tiene una aplicación ASP sobre IIS 6 suele dar pocos detalles, tal y como se ve en la captura anterior, ya que es bastante sobrio. Pero esto cambió.

Figura 2: Error 404 descubierto buscando aplicaciones asp migradas

Sin embargo, buscando por aplicaciones ASP, y forzando un Not Found, si el sitio ha sido migrado a IIS 7 o IIS 7.5, es probable que el administrador de la aplicación no se haya acordado de fortificar el mensaje de error, por lo que es bastante común encontrar estos mensajes.

Figura 3: Error 404 en otro IIS 7 con una aplicación ASP

Como se puede ver son muy descriptivos, y permiten encontrar la estructura de permisos con los que está corriendo el application pool, el nombre de la aplicación, o rutas locales de acceso a los ficheros del servidor.

Figura 4: Error 404 en un IIS 7.5 con almacenamiento en red y direcciones locales

Por supuesto, esto funciona igual en IIS 7 como en IIS 7.5, así que hay que darle una revisión a las opciones de fortificación si migras una aplicación legacy ASP a un servidor IIS sobre Windows Server 2008 o Windows Server 2008 R2.

En una auditoría de seguridad, siempre revisamos bien todos los mensajes de error, así que si no quieres que tu servidor haga data leak por ellos, revísalos.

Saludos Malignos!