DoS-УЯЗВИМОСТИ

Спецвыпуск Xakep, номер #021, стр. 021-036-1

обзор дыр, приводящих к DoS

Alex Shark (qqqqqwww@ring.by)

DoS-атака считается самой грубой атакой в сети. Финальный результат атаки - падение, зависание или просто отключение какой-либо части сервера. Как правило, уязвимости данного типа происходят из-за недочетов программистов, которые написали сервер. На настоящий момент нет ни одной системы, против которой нельзя было бы осуществить DoS-атаку. Самой надежной системой остается по-прежнему забетонированная гиря без ручки (чтоб на ногу не уронить случайно). Если, например, на XP-сервер еще не нашли дырку, то это всего лишь значит, что у него еще все впереди :). Так что заDoS`ить можно все, что угодно. И ты это сам поймешь, когда прочитаешь этот небольшой обзор DoS-уязвимостей.

WIN-DoS

Начнем с любимой мастдайки. Первый на очереди у нас IIS 4, входящий в комплект NT-4.0 Server, и долгое время на серверах с NT-ей именно он и стоял. Позже начали устанавливать Apache по причине большей надежности и открытого кода (а, следовательно, полной бесплатности). Дырка была обнаружена ребятами из eEye. Основана на неправильной обработке запроса файла с расширением HTR. В оригинале данный баг (переполнение буфера) должен давать доступ на чужую тачку, но в четырех случаях из пяти происходит банальный обвал сервака с последующим зависанием. Можно завалить и руками, послав телнетом:

POST /tralala.htr HTTP/1.0

Host: www.server.com

Transfer-Encoding: chunked

AAAAAAAAAA (и так 1-3 кило :))

[enter][enter]

Брать тут:

Exploit: www.eeye.com/html/Research/Advisories/AD20020612.html

Patch: www.microsoft.com/technet/security/bulletin/MS02-028.asp

Следующая стадия развития IIS - версия 5. Ставится вместе с 2000-Server. И тут не все гладко. Первая дырка появилась при обработке внутреннего поля запроса Content-length - в этом поле лежит длина передаваемых данных. Так вот, если туда написать 5300000, то независимо от того, полетят вслед за запросом сами данные или нет, сервер выделяет память под них (сначала в RAM, потом на винте) на пять метров с копейками. Сам запрос достаточно короткий:

GET /index HTTP/1.1

Host: 192.168.0.1

Connection: Keep-Alive

Content-Length: 5300000

Authorization: Basic

AAAAAAAAAAA

Послав это на сервер, ты заставишь его отожрать 5300000 с небольшим байт в своей памяти. Как видно, посылать можно хоть telnet`ом. Скорость отжирания памяти просто дикая. От сотни таких запросов сервак (P3-750/256Mb/64k-bit) вышел из себя и в течение двух часов не вернулся обратно - пришлось ребутить :).

Брать тут:

Exploit: www.security.nnov.ru/files/IISContent.pl

Patch: www.microsoft.com/technet/security/

Очередная дырка относится и к IIS 4, и к IIS 5, но только в том случае, если запущена поддержка FrontPage (FrontPage Server Extension). Дыра отлично работает благодаря неправильному обращению к модулю авторизации (author.dll), который запускается при обращении к shtml файлам. При отправке неправильного запроса на сервер с NT4 файл inetinfo.exe просто выпадает. На 2k-виндах данный агрегат не падает, а начинает жутко тормозить. По заверениям Microsoft, файлец должен сам себя перезагрузить, но на практике этого не происходит, в результате чего достучаться до сервака можно, но на запросы он никак не отвечает. Самое интересное - отключение аутентификации в FrontPage не решит проблему :). Для ее решения мелкософтовцы советуют полностью снести FrontPage (хорошо - не посоветовали винт форматнуть) или загрузить патчик. Нашли эту дырочку все те же ребята из eEye. Дыра реально проверялась и забавно работает. Эксплоит они, если сказать честно, недоделали. Поэтому делается все так: запускается наша любимая хакерская программа telnet, начинается коннект с серваком. Далее пихается в телнет текст того самого эксплоита. Все, можно запускать браузер и наблюдать, а точнее не наблюдать, итоги работы дырки.