Крис Касперский - ТЕХНИКА СЕТЕВЫХ АТАК

send(SRV, "POST /cgi-bin/test-cgi HTTP/1.0\n",0);

send(SRV,"Content-Length:$size\n\n",0);

$count++;

print "Content-Length:$size\n";

print "«BR»";

}

Приведенный пример [283]посылает 100 запросов с требованием выделить 10 килобайт памяти для каждого из них. В результате этого, 100x10 - 1000 килобайт оказываются потерянными [284]

Скорее комичная, чем опасная ошибка была обнаружена в… принтере «HP LaserJet 4500 + HP JetDirect J3111A», имеющим встроенный Web-сервер, предназначенный для удаленного администрирования. Неумеренно длинный запрос GET приводил к выдаче на печать страницы диагностики. Атакующий мог в короткое время привести в негодность всю бумагу, находящуюся в лотке и блокировать остальные задания на печать.

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

Гораздо большую опасность представляют концептуальные уязвимости, одинаково хорошо работающие на любых платформах, операционных системах и серверах. Одним из недостатков протокола HTTP является неограниченный размер заголовка запроса. А ведь для его хранения и обработки требуется некоторое количество памяти и процессорного времени!

Забросав сервер, огромными, бессмысленными (или осмысленными - это роли не играет) заголовками, можно значительно ухудшить его производительность, вплоть до полного отказа в обслуживании остальных клиентов.

Именно эта бесхитростная технология и была положена в основу Sioux [285]- атак, один из примеров программной реализации которой показан ниже [286].

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

Девятого Февраля Торговый Департамент США убеждал On-line компании и агентства в своей непричастности к хаосу, пошатнувшего мирное течение жизни Всемирной Паутины (предполагалось, что именно их компьютеры были использованы для атаки).

«Там и правда неважно обстояло с защитой» заметил Вильям Делай на пресс-конференции в Чикаго, кивая в сторону «Yahoo», первую жертву хакерской атаки, случившийся днем раньше. Следом были атакованы http://Amazon.com, http://Buy.com, http://CNN.comи несколько других сайтов, не упомянутых здесь по причине их малой известности российским интернетчикам.

ФБР невнятно отозвалось насчет перспективы поимки и наказания злоумышленника (который все же позже был пойман не без участия российского ФСБ). Зато активно пропагандировало превентивные меры защиты, то есть «латание дыр» в системах безопасности серверных приложений, в чем ФБР обещало активную помощь, рекламируя свежие «заплатки» выложенные на http://www.fbi.gov/nipc/trinoo.htm.

Заглянув туда трудно было удержаться от разочарования. Похоже, что ФБР не заботило ничего, кроме собственной безопасности, на что указывал падч, предназначенный для операционных систем Solaris 2.5.1, 2.6, Solaris 7 (Sparc, Intel), то есть тех, на которых ФБР, собственно, и работает.

Так же поддерживалась неизвестная версия LINIX для платформы Intel. А Windows?

Но ФБР не волнует судьба пользователей (и администраторов), сидящих под Windows, поэтому «…This file will not work on a Windows-based PC», или, говоря человеческим языком, «сушите весла».

Билл Клинтон предпочел более действенные меры, пообещав 2 биллиона долларов ( http://news.cnet.com/news/0-1005-200-1516764.html), на войну с тем гнусным типом хакеров, чьи атаки подрывают сетевую экономику (которая составляет не много не мало, а что-то порядка 25%, по крайней мере, в США).

Правда деньги будут выделены едва ли к концу этого года, а то и к середине следующего (то есть 2001). Зато уже находятся желающие оторвать себе кусок от этого пирога. Часть денег уйдет в Лабораторию Информационных Технологий ( http://www.itl.nist.gov/) и, конечно же, Национальный Институт Стандартов ( http://www.nist.gov/).

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

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

За подробностями сих разборок можно сходить на сайт агентства CNN ( http://news.cnet.com/news/0-1005-200-1546306.html?tag=st.ne.1002)

Первыми на эту атаку отреагировали разработчики Apache, добавив новую директиву « LimitRequestFields », ограничивающую максимальное количество полей в заголовке запроса. К сожалению, остальные производители проявили гораздо меньшую оперативность и до сих пор некоторые серверы могут быть блокированы таким способом [287].

Но, если дыры в серверах элементарно затыкаются выпущенной производителем заплаткой, то ошибки в скриптах, созданных владельцем сервера (или командой работающих на него программистов) находить и устранять приходится самому разработчики, что не так-то просто. Очень трудно создать непротиворечивую систему обработки пользовательского ввода, предусматривающую и отсекающую все потенциально опасные шаги злоумышленника. Большинство программистов рассчитывают на лояльного клиента, обращающегося со скриптом «как нужно» и «как того требует здравый смысл».

Классическое подтверждение тому код, отправляющий письмо по адресу, указанному пользователем, который встречается практически в любой регистрационной WEB-форме. В UNIX-системах для этой цели, как правило, используется вызов приложения SendMail, с передачей адреса назначения в командной строке. Ввиду своей простоты такая схема заслужила большую популярность и как будто бы работала нормально. Пока, однажды, кому-то не пришла в голову мысль использовать перенаправления ввода для копирования файлов, доступ к которым при нормальном ходе вещей невозможен. Если злоумышленник вместе с почтовым адресом передаст SendMail-у свои команды, он сможет получить любой файл, какой ему заблагорассудится. В основе этого приема лежит механизм обработки адресов программой SendMail: « Любой адрес, проходящий через начальный алгоритм синтаксического разбора локальных адресов (то есть не являющийся действительным адресом для другой почтовой программы) сканируется на два специальных случая. Если он предварен вертикальной чертой ("|"), то оставшаяся часть адреса будет обработана как команда оболочки (shell command). Если имя пользователя начинается со знака косой черты ("/"), то это имя используется как имя файла, вместо имени пользователя. Файлы, имеющие выставленные биты смены владельца (setuid) или смены группы (setgid) но не имеющие битов выполнения имеют эти биты, если sendmailзапущен от пользователя root .» [288]