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


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

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

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

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

enter image description here

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

enter image description here

  • 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 имен файлов:

enter image description here

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

enter image description here

EDIT2: Убедитесь, что осталось 8.3 имени файла:

enter image description here


8
2018-02-23 09:53


Источник


Быстрый способ удвоить проверку, если в каталоге есть какие-либо имена 8.3. dir /x, Ваш сайт может иметь символические ссылки на каталоги, которые по-прежнему содержат автогенерированные имена 8.3. - Brian
Никаких признаков каких-либо 8.3 имен файлов, которых я боюсь :( - KenD
Установка .NET 4.0 (которая не уязвима для этого эксплойта) - это другая общая работа для этой проблемы. Вы уже пробовали это? - HopelessN00b
.Net 4, и все пулы приложений на сервере настроены на использование .NET Framework v4.0.30319 - см. снимок экрана в редакции выше. - KenD
Вау. Наверное, хватаясь за соломинку здесь, но уверены ли вы, что сканер уязвимостей, который вы используете, надежный? Попробуйте другой инструмент или попытайтесь выполнить атаку вручную и посмотрите, что вы видите. - HopelessN00b


Ответы:


Попробуйте просмотреть существующие короткие имена файлов с помощью 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. через Твиттер об этом, и он ответил:

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

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

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


5
2018-03-01 20:53



Боюсь, что нет изменений - см. «EDIT2» в моем оригинальном посте :( - KenD
Глядя на журнал с пустой магической частью (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> - beatcracker
Это очень Интересно - хотя, оглядываясь назад, что «двойная запятая» находится в коде некоторое время. Удаление это означает, что тест теперь выполняется без очевидной ошибки ... - KenD
Ха, ты в безопасности, см. Обновление! - beatcracker
Все это работает, и мы были в безопасности все время :) Спасибо за вашу помощь и свяжитесь с разработчиком! - KenD


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

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


1
2017-11-11 13:58





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

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

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

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


0
2018-02-26 04:50



В статье, которую вы указали, говорится, как отключить создание имени файла 8.3, а не почему оно решает проблему. - Michael Hampton♦
Я уже отключил 8.3 имена файлов и dir /x не отображает краткие имена файлов в каталоге сайта - KenD
Кен, это был метод, который ты использовал? - Dave Holland
Да; Я также видел ссылку на параметр реестра, но fsutil команда, похоже, просто установила для меня эту клавишу. - KenD


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


0
2018-02-26 16:27