Uno de nuestros servidores IIS (IIS 7.5, Server 2008 R2) es aparentemente "vulnerable" altilde Divulgación de nombre de archivo cortoasunto.
Sin embargo, me está costando solucionar el problema. Hasta ahora, he
Se deshabilitaron los nombres de archivos 8.3, se detuvo el servidor web, se recreó el directorio del sitio y se inició el servicio nuevamente.
Se agregó una regla de filtro para una tilde en la URL:
- Se agregó una regla de filtro para una tilde EN CUALQUIER LUGAR:
IISRESET
un par de vecesComprobado que
web.config
tiene agregadas las reglas de filtrado relevantes.
.. pero aún así, no puedo hacer que mi sitio pase elprueba:
java -jar ~/temp/IIS-ShortName-Scanner-master/IIS_shortname_scanner.jar http://www.example.com
[...SNIP...]
Testing request method: "TRACE" with magic part: "/webresource.axd" ...
Testing request method: "DEBUG" with magic part: "" ...
Testing request method: "OPTIONS" with magic part: "" ...
Testing request method: "GET" with magic part: "" ...
Reliable request method was found = GET
Reliable magic part was found =
144 requests have been sent to the server:
<<< The target website is vulnerable! >>>
¿Qué más necesito hacer para resolver esto?
EDITAR:Esto es DIR /x
lo que parece no mostrar nombres de archivos 8.3:
y aquí está el grupo de aplicaciones para el sitio (todos los demás sitios en el servidor son iguales):
EDITAR2: Verificación de que no quedan nombres de archivos 8.3:
Respuesta1
Intente buscar nombres de archivos cortos existentes con fsutil
:
fsutil 8dot3name scan /s /v E:\inetpub\wwwroot
Y quítelos si los encuentra:
fsutil 8dot3name strip /s /v E:\inetpub\wwwroot
También mirando el registro con la parte mágica vacía ( magic part: ""
), me pregunto si podría ser un error en el POC. Esta línea enconfiguración.xmlParece que tiene una coma adicional después /webresource.axd
:
<entry> key="magicFinalPartList">
<![CDATA[\a.aspx,\a.asp,/a.aspx,/a.asp,/a.shtml,/a.asmx,/a.ashx,/a.config,/a.php,/a.jpg,/webresource.axd,,/a.xxx]]>
</entry>
Le pregunté al desarrollador. vía Twitter al respecto y respondió:
Entonces, parece que ahora estás a salvo :)
Respuesta2
también "NOTA: El cambio en la entrada de registro NtfsDisable8dot3NameCreation afecta solo a los archivos, carpetas y perfiles que se crean después del cambio. Los archivos que ya existen no se ven afectados".
Nota: Aunque deshabilitar la creación de nombres de archivos 8.3 aumenta el rendimiento de los archivos en Windows, es posible que algunas aplicaciones (16, 32 o 64 bits) no puedan encontrar archivos y directorios que tengan nombres de archivo largos.
Respuesta3
Desafortunadamente, la única forma de lidiar realmente con esto es un molesto conjunto de giros, dependiendo de su versión de Windows, que desactivan la capacidad de generar nombres 8.3.
Para su versión de Windows:
Para deshabilitar la creación de nombres 8.3 en todas las particiones NTFS, escriba fsutil.exe Comportment Set Disable8dot3 1 en un símbolo del sistema elevado y luego presione Entrar.
Respuesta4
La mejor solución se encuentra a continuación, ya que no podemos retirarnos después de cada nueva implementación.
Pruebe/escanee el sitio en busca de vulnerabilidades con el siguiente enlace (instale Java y ejecute el comando para probar/escanear).
Comando para escanear el sitio:
java -jar iis_shortname_scanner.jar 2 20 https://example.com/
Busque nombres de archivos cortos existentes:
fsutil 8dot3name scan /s /v c:\inetpub\wwwroot
Verifique que la creación de nombres 8dot3 esté habilitada o deshabilitada:
fsutil 8dot3name query C:\Release\SiteRootDocumentPath
Si la creación de nombres 8dot3 está habilitada, use el siguiente comando para deshabilitarla:
fsutil 8dot3name set C:\Release\SiteRootDocumentPath 1
Las propiedades de 8dot3name están configuradas para habilitar la creación de nombres 8dot3 para un volumen específico (0) o para deshabilitar la creación de nombres 8dot3 en el volumen especificado (1)
Incluso si vuelve a implementar el código en la ruta física del sitio (SiteRootDocument), no creará archivos con nombres cortos.
Se pasará el escaneo :)