Um de nossos servidores IIS (IIS 7.5, Server 2008 R2) é aparentemente "vulnerável" aoDivulgação do nome de arquivo curto do tilemitir.
No entanto, estou tendo dificuldade em resolver o problema. Até agora, eu
Desabilitou nomes de arquivos 8.3, interrompeu o servidor web, recriou o diretório do site e iniciou o serviço novamente
Adicionada uma regra de filtro para um til no URL:
- Adicionada uma regra de filtro para um til EM QUALQUER LUGAR:
IISRESET
algumas vezesVerificado se
web.config
as regras de filtro relevantes foram adicionadas
.. mas ainda assim, não consigo fazer meu site passar noteste:
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! >>>
O que mais preciso fazer para resolver isso?
EDITAR:aqui está DIR /x
o que parece não mostrar nomes de arquivos 8.3:
e aqui está o pool de aplicativos do site (todos os outros sites no servidor são iguais):
EDITAR2: Verificação de que não há mais nomes de arquivos 8.3:
Responder1
Tente procurar nomes de arquivos curtos existentes com fsutil
:
fsutil 8dot3name scan /s /v E:\inetpub\wwwroot
E retire-os se forem encontrados:
fsutil 8dot3name strip /s /v E:\inetpub\wwwroot
Olhando também para o log com a parte mágica vazia ( magic part: ""
), me pergunto se isso pode ser um bug no POC. Esta linha emconfig.xmlparece que tem vírgula extra depois de /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>
Eu perguntei ao desenvolvedor. via Twitter sobre isso e ele respondeu:
Então, parece que você está seguro agora :)
Responder2
também "NOTA: A alteração na entrada de registro NtfsDisable8dot3NameCreation afeta apenas arquivos, pastas e perfis criados após a alteração. Arquivos que já existem não são afetados."
Nota: Embora a desativação da criação de nomes de arquivo 8.3 aumente o desempenho dos arquivos no Windows, alguns aplicativos (16 bits, 32 bits ou 64 bits) podem não conseguir localizar arquivos e diretórios com nomes de arquivo longos.
Responder3
Infelizmente, a única maneira de realmente lidar com isso é um conjunto irritante de giros, dependendo da sua versão do Windows, desativando a capacidade de gerar nomes 8.3.
Para sua versão do Windows:
Para desabilitar a criação de nome 8.3 em todas as partições NTFS, digite fsutil.exe behavior set disable8dot3 1 em um prompt de comando elevado e pressione Enter.
Responder4
A melhor solução está abaixo, pois não podemos remover após cada nova implantação.
Teste/verifique o site em busca de vulnerabilidade com o link abaixo (instale o java e execute o comando para testar/verificar).
Comando para verificar o site:
java -jar iis_shortname_scanner.jar 2 20 https://example.com/
Procure nomes de arquivos curtos existentes:
fsutil 8dot3name scan /s /v c:\inetpub\wwwroot
Verifique se a criação do nome 8dot3 está desabilitada ou habilitada:
fsutil 8dot3name query C:\Release\SiteRootDocumentPath
Se a criação de nome 8dot3 estiver habilitada, use o comando abaixo para desabilitar:
fsutil 8dot3name set C:\Release\SiteRootDocumentPath 1
As propriedades 8dot3name são definidas para ativar a criação de nome 8dot3 para um volume especificado (0) ou definidas para desativar a criação de nome 8dot3 no volume especificado (1)
Mesmo se você reimplantar o código no caminho físico do site (SiteRootDocument), ele não criará arquivos com nomes abreviados.
A verificação será aprovada :)