Esta semana hemos andado acelerando la modificación de un plugin de nuestro sistema de Pentesting Persistente Faast, debido al descubrimiento de que el bug de Short Name en servidores web IIS de Microsoft que permite listar los ficheros en formato 8:3 no se mitiga de igual forma para el método GET que para el método OPTIONS de HTTP, haciendo que de nuevo se pueda visualizar toda la estructura de archivos y carpetas de un directorio publicado en un servidor web IIS - siempre en formato 8:3 -.
Después de actualizar nuestra knowledge base en Faast y de notificar a nuestros clientes de cómo mitigar este bug, ayer sacamos en el blog de Eleven Paths un pequeño post explicando en qué consiste el fallo.
El bug de IIS ShortName para listar archivos
Como se ha explicado muchas veces, este bug afecta a todas las versiones de IIS siempre que haya compatibilidad en el sistema de ficheros NTFS con el formato de nombres cortos. En este escenario, una petición utilizando los caracteres especiales permiten hacer un ataque de booleanización a ciegas para extraer los 6 primeros caracteres del nombre - los otros tres caracteres son para ~1 (o ~2) - y los tres primeros de la extensión.
Figura 2: Pruebas a realizar para detectar la vulnerabilidad |
Dependiendo de la versión de IIS hay que probar diferentes condiciones para saber si es una respuesta positiva - existe un fichero con ese patrón en el nombre - o negativa - no existe ningún fichero que cumpla ese patrón -.
Figura 3: Listado de carpetas de windows.microsoft.com con el bug de IIS Short Name explotado por GET |
Una vez comprobado que existe ese fallo, es fácil hacer una automatización para extraer la lista completa de los ficheros, e incluso en Microsoft.com, con el plugin de la FOCA era posible listar el contenido del directorio. Si tienes el libro de Pentesting con FOCA, a este bug en concreto se le dedican partes en profundidad.
El parte del método GET y la nueva explotación por OPTIONS
Los servidores IIS fueron actualizados con una mitigación que ofrecía el mismo comportamiento para las respuestas TRUE y las respuestas FALSE, por lo cuál se acababa con la posibilidad de realizar un ataque de booleanización, pero esto no se mitigó en todos los métodos HTTP y con OPTIONS - un método que sirve para consultar cuáles son los métodos HTTP permitidos en una determinada ubicación del servidor web - se puede continuar detectando el bug y extrayendo el listado de archivos.
Figura 4: El fichero existe y se obtiene un 404 accediendo por OPTIONS |
Cambiada la detección y explotación del bug IIS ShortName del método GET al método OPTIONS, muchos servidores que parecían estar parcheados frente a este bug vuelven a estar afectados, por lo que hay que tomar medidas.
Figura 5: El fichero NO existe y se obtiene un 302 con el método OPTIONS |
Las alternativas no son muchas, deshabilitar el método OPTIONS en todos los servidores web con Internet Information Services, filtrar el método en los WAF (Web Application Firewalls) o bien deshabilitar la compatibilidad de nombres 8:3 en el servidor Windows Server. Para ello hay que configurar la siguiente clave de registro con un valor 1.
HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation
Si tienes un servidor web con Internet Information Services de Microsoft comprueba si es vulnerable y si lo es, toma medidas, porque si no te van a poder listar los ficheros de todo tu servidor web con más o menos facilidad.
Saludos Malignos!
Creo que tanto en el blog de Eleven Paths como aquí indicáis que el valor que hay que poner en el registro para deshabilitar los nombres cortos es un 0, pero como no me cuadraba lo he verificado en TechNet y dice lo contrario. Lo podéis verificar por favor?
ResponderEliminarhttps://technet.microsoft.com/en-us/library/cc959352.aspx