Corrigindo a vulnerabilidade do til do IIS

Question

Um dos nossos servidores IIS (IIS 7.5, Server 2008 R2) aparentemente está "vulnerável" à divulgação do nome de arquivo abreviado do til questão.

No entanto, estou tendo dificuldades para corrigir o problema. Até agora eu tenho

• Desativou nomes de arquivo 8.3, interrompeu o servidor da Web, recriou o diretório do site e iniciou o serviço novamente

• Adicionou uma regra de filtro para um til na URL:

• AdicionadaumaregradefiltroparaumtilEMQUALQUERLUGAR:

• IISRESET algumas vezes

• Verificou que web.config tem as regras de filtro relevantes adicionadas

.. mas mesmo assim, não consigo que meu site passe no teste :

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: eis DIR /x , que parece não exibir nomes de arquivo 8.3:

eaquiestáopooldeaplicativosdosite(todososoutrossitesnoservidorsãoosmesmos):

EDIT2 : verificação de que não há nomes de arquivo 8.3:

    

Answer 1

Tente verificar nomes de arquivo curtos existentes com fsutil :

• fsutil 8dot3name scan /s /v E:\inetpub\wwwroot

E descarte-os se forem encontrados:

• fsutil 8dot3name strip /s /v E:\inetpub\wwwroot

Também olhando para o log com parte mágica vazia ( magic part: "" ), eu me pergunto se isso poderia ser um bug no POC. Esta linha em config.xml parece ter uma vírgula extra apó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>

Eu perguntei ao dev. via Twitter sobre isso e ele respondeu:

For rare cases in which no extensions were required. But, recently that has caused more problems only! I'll remove it now.

I removed it from the Config file. This was the 2nd complaint so it was the right time for this change.

Então, parece que você está seguro agora:)

    

Answer 2

também "Observação: a alteração para a entrada de registro NtfsDisable8dot3NameCreation afeta somente arquivos, pastas e perfis que são criados após a alteração. Arquivos que já existem não são afetados."

Nota: Embora a desativação da criação do nome do arquivo 8.3 aumente o desempenho do arquivo no Windows, alguns aplicativos (16 bits, 32 bits ou 64 bits) podem não encontrar arquivos e diretórios com nomes longos.

    

Answer 3

Infelizmente, a única maneira de realmente lidar com isso é um conjunto irritante de oscilações, dependendo da sua versão do Windows, desabilitando a capacidade de gerar nomes 8.3.

Para sua versão do Windows:

Para desabilitar a criação do nome 8.3 em todas as partições NTFS, digite o comportamento do fsutil.exe defina disable8dot3 1 em um prompt de comando elevado e pressione Enter.

Fonte: link

    

Answer 4

Eu não sei exatamente como o script funciona e como sua rede é configurada, mas que tal filtrar por meio de algo na frente do servidor IIS (mesmo que seja apenas um dispositivo virtual em uma máquina virtual)? Ou seja, você configura um IPS com uma regra que elimina especificamente o tráfego referente a esse problema específico?