Исправление уязвимости тильды IIS

Один из наших серверов IIS (IIS 7.5, Server 2008 R2), по-видимому, «уязвим» к проблеме раскрытия короткого имени тильды .

Тем не менее, мне трудно на самом деле решить проблему. До сих пор я

• Отключил 8.3 имен файлов, остановил веб-сервер, пересоздал каталог сайта и снова запустил сервис

• Добавлено правило фильтра для тильды в URL:

• Добавлено правило фильтра для тильды в любом месте:

• IISRESET Пару раз

• Проверено, что web.configдобавлены соответствующие правила фильтра

.. но все же я не могу заставить свой сайт пройти тест :

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! >>>

Что еще мне нужно сделать, чтобы решить эту проблему?

РЕДАКТИРОВАТЬ: вот, DIR /xчто, кажется, показывает не 8,3 имени файла:

и вот пул приложений для сайта (все остальные сайты на сервере одинаковы):

РЕДАКТИРОВАТЬ 2 : Проверка, что не осталось 8.3 имен файлов:

Попробуйте найти существующие короткие имена файлов с помощью fsutil:

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

И раздеть их, если они найдены:

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

Также, глядя на журнал с пустой магической частью ( magic part: ""), мне интересно, может ли это быть ошибкой в ​​POC. Эта строка в config.xml выглядит как лишняя запятая после /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>

Я спросил Dev. через Twitter об этом он ответил:

Для редких случаев, когда не требуется никаких расширений. Но в последнее время это вызвало только больше проблем! Я удалю это сейчас.

Я удалил его из файла конфигурации. Это была вторая жалоба, так что это было подходящее время для этого изменения.

Итак, кажется, что вы в безопасности сейчас :)

также «ПРИМЕЧАНИЕ. Изменение записи реестра NtfsDisable8dot3NameCreation влияет только на файлы, папки и профили, созданные после изменения. На уже существующие файлы это не влияет».

Примечание. Хотя отключение создания имени файла 8.3 повышает производительность файла в Windows, некоторые приложения (16-разрядные, 32-разрядные или 64-разрядные) могут не иметь возможности находить файлы и каталоги с длинными именами файлов.

К сожалению, единственный способ действительно справиться с этим - это раздражающий набор вращений, в зависимости от вашей версии окон, отключающий возможность генерировать 8.3 имен.

Для вашей версии Windows:

Чтобы отключить создание имени 8.3 во всех разделах NTFS, введите в командной строке с повышенными правами fsutil.exe поведение set disable8dot3 1 и нажмите клавишу ВВОД.

Источник: http://support.microsoft.com/kb/121007

Я не совсем уверен, как работает скрипт и как настроена ваша сеть, но как насчет фильтрации через что-то перед сервером IIS (даже если это просто виртуальное устройство на виртуальной машине)? А именно, вы настраиваете IPS с правилом, которое специально отбрасывает трафик, относящийся к этой конкретной проблеме?