Listado de ficheros en IIS utilizando nombres acortados

No conocía esta vulnerabilidad hasta que la he visto en hackplayers, pero me ha dejado sorprendido la potencia del bug/"característica" para realizar un descubrimiento de ficheros en un servidor IIS por medio del sistema de nombres acortados que aún permite el sistema de ficheros en Microsoft Windows.

La herencia de los 8:3 caracteres en el nombre de los ficheros en un sistema Microsoft Windows, hace que sea posible aún poder acceder a un fichero utilizando ambos métodos, es decir, el del nombre acortado y el del nombre extendido. Aunque esta característica está disponible en Windows, en IIS no es posible, así, tanto si el fichero se encuentra como si no, se generará un error. 

El servidor IIS, cuando se solicita un nombre acortado, va a intentar acceder al mismo, y si lo encuentra, dará un error 404, algo que no debería ser normal. El caso es que cuando el fichero sí está, se continua ejecutando el procesamiento de la URL y si se construye una URL con ingenio, se puede conseguir un error de Bad Request.

Jugando con los errores 404 y los errores Bad Request, es posible hacer un ataque Blind para descubrir el nombre de los ficheros. Esto se puede hacer solo en algunas versiones de IIS y .NET en las que no se ha filtrado el caracter *. Tienes el paper que lo explica aquí, donde además explican cómo acceder a carpetas protegidas o saltar algunas protecciones.

Así, si se llega un servidor IIS 7 con ASPX se debe probar primero que los errores 400 de Bad Request y 404 de Not Found son distintos. Para ello, basta con hacer las dos siguientes pruebas para saber si es vulnerable a este ataque.

Figura 1: Prueba de 404

Figura 2: Prueba de Bad Request

Estas pruebas del ejemplo, darán distintos resultados según se vaya realizando sobre un servidor IIS 5, IIS 6 o IIS 7. La siguiente tabla recoge las pruebas a realizar, y los resultados que se obtienen cuando el nombre del fichero existe (valid) o no existe (invalid):

Figura 3: Tabla de pruebas

Si el sitio no es vulnerable se obtendrá siempre el mismo resultado, o cuando se intente hacer uso de los comodines obtendremos un mensaje como éste:

Figura 4: Servidor IIS NO vulnerable a esta técnica

Si el sitio es vulnerable, se puede proceder a realizar la booleanización haciendo uso del símbolo de acortamiento en el nombre ~1, el caracter comodín *, y tomando el error 404 como un True y el Bad Request como un False.

Figura 5: False. No hay ningún fichero que comience por ab

Figura 6: True. Al menos hay un fichero que comienza por ac

Solo se pueden descubrir los 6 primeros caracteres del nombre, ya que los últimos 2 serán ~1 o ~2, y luego la extensión será de 3 letras.

Figura 7: Nombre de fichero acortado descubierto

Llegados a este punto hay que "adivinar" los últimos caracteres del nombre y la extensión.

Figura 8: Nombre de fichero extendido

Para automatizar este escaneo hay una herramienta como POC llamada IIS Short Name Scanner desarrollada en Java y publicada en Google Code, pero dad por seguro que esto acabará en la FOCA.

Como gracia final, hay que decir que, en .NET las extensiones son de ASPX - 4 caracteres - mientras que el sistema 8:3 almacena los ficheros con extensión ASP, lo que hace que el error 404 sea el de IIS y no el del framework .NET. Para solucionarlo, basta con que hagas que todos los menajes de eror de .NET y de IIS estén controlados y sean iguales.

Saludos Malignos!