книги хакеры / журнал хакер / специальные выпуски / Специальный выпуск 47_Optimized

Не всегда есть возможность и желание писать бэкдор самому. Я приготовил коротенький обзор полезных бэкдоров/руткитов, доступных в сети:

Bdoor.c - бэкдор, маскирующийся под HTTP-демон. Он не использует никаких stealth-технологий. Применять его можно только в расчете на невнимательность администратора (явление, надо признать, очень частое).

SYS_getuid был бы просто отличным руткитом, если бы не так просто ловился в системе. Для его обнаружения достаточно сделать копию таблицы системных вызовов после установки системы (до того как система затроянена), а потом время от времени сверять указатели, текущую таблицу с копией, любые расхождения будут означать присутствие бэкдора.

Superkit – замечательный многофункциональный руткит. Умеет прятать файлы, процессы, соединения в netstat. Имеет функцию защиты паролем. Умеет открывать порт и запускать на нем удаленный шелл. И самое приятное - он не может быть обнаружен с помощью сравнения таблиц системных вызовов.

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

kbdv2.c - Linux loadable kernel module backdoor. Классический пример бэкдора, подгружаемого к ядру системы. Перехватывает системные вызовы (SYS_stat, SYS_getuid). Интересен бэкдор не столько своими функциями, сколько хорошо комментированным исходным кодом. Его изучение может быть очень полезно при написании собственной программы подобного рода.

Neth – детище Forb’а. Отличный бэкдор! Написанный с использованием "сырых" сокетов, он не открывает TCP-портов, за счет чего не палится ни netstat’ом, ни удаленным сканером.

Практически все перечисленные мной программки можно скачать с сайта www.packetstormsecurity.nl.

Замаскированный бэкдор

39

Другой способ - написать LKM, который бы перехватывал системные вызовы утилиты netstat. Это вообще самый лучший подход к редактированию вывода любых системных утилит, будь то ps или netstat. Он немного сложен в реализации, но, если знать, куда копать - какие системные вызовы в каких случаях перехватывать, то справиться можно.

Допустим, нам удалось скрыть бэкдор из списка открытых соединений. А что, если администратор проверяет свою систему не локально, а, например, удаленно с помощью различ- ных программ вроде nmap? Тогда при сканировании администратор заметит, что в системе открыт "левый" порт, а netstat его не показывает. Админ сразу же просечет фишку, и больше мы на его машину не попадем. Именно для таких слу- чаев хакеры придумали еще кое-что для сокрытия своего присутствия в системе. При написании бэкдора следует использовать не SOCK_STREAM, а SOCK_RAW, то есть вместо TCP-сокетов юзать RAW-со- кеты. Красивый способ: RAW-сокеты позволяют слушать весь входящий трафик, а это дает нам огромные возможности. Например, мы можем сделать так, чтобы после посылки определенного пакета бэкдор открывал шелл на определенном порту. Примеры подобных бэкдоров - на packetstormsecurity.nl.

МАСКИРУЕМ ТРАФИК

Грамотный администратор не всегда ограничивается стандартными средствами при поиске бэкдора в своей системе. Иногда он прибегает к поиску злоумышленника с помощью снифера или IDS, подобной Снорту. А от зоркого глаза (или чуткого носа? :)) “нюхача” не скроется ни один даже самый навороченный бэкдор.

Как же уберечься от надоедливого админа и его кошмарной IDS? Тут поможет только одно – полное шифрование трафика, которое уберет заметный plain text команд из логов снифера. Хакеры используют для этого самые разные криптоалгоритмы: и IDEA, и xTEA, и Blowfish, и Twofish.

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

НАПОСЛЕДОК

В этой статье я описал лишь самые популярные подходы к маскировке. Время не стоит на месте, постоянно изобретаются все новые и новые способы сокрытия бэкдоров. Старайся не отставать от прогресса, ведь не просто так говорят: "Кто остановился, тот умер!" E

Утилита cron поможет обхитрить администратора.

Умный админ может регулярно считать MD5-хэши от всех файлов в системе. Он без труда может заметить изменения в системных утилитах.

атак или негодования пострадавших. Этот материал поможет тебе разобраться в DoS/DDoS-атаках.

IRC - самый популярный способ управления троянами

Если сервер атакует одна «точка», то он вполне может закрыться от нее фаерволом.

ÖÅËÜ

» Основная цель DoS/DDoS-атак - вывести объект из рабочего состояния. Конечно, в

большинстве случаев глобальная атака приводит к большим финансовым потерям со стороны атакуемого. Например, если какой-либо коммерческий сайт упадет на несколько часов, то это нанесет вред бизнесу, а если на неделю, то владелец ресурса вполне может разориться. Или взять локальные сети. Дело в том, что одним из эффектов популярных атак на Denial of Service (DoS) является огромный трафик, направляемый на жертву. Если для крупной западной фирмы это мелочь, то для небольшой отечественной домашней сети средняя атака может грозить разорением. Кроме огромного вреда, наносимого жертве, такие нападения отличаются простотой и огромной эффективностью. Против них нет стопроцентной защиты. Именно названные выше факторы привлекают к DoS внимание специалистов по сетевой безопасности и... DoS'еров.

ПРИНЦИП РАБОТЫ

Для того чтобы обнаружить, а уж тем более организовать DoS/DDoS-ата- ку, нужно разобраться в ее принципах. Эти атаки не направлены на получение доступа к ресурсам или к важной информации. Атака DoS делает ресурс недоступным для использования путем нарушения его нормальной работы. Атаку на отказ в обслуживании можно провести всего двумя способами: использовав уязвимости в программном обеспечении жертвы и при помощи отсылки большого количества определенно составленных сетевых пакетов (флуд). Первый способ состоит в том, чтобы, используя уязвимости типа переполнения буфера, отослать код, выполняющий DoS на сервере. Поскольку атака будет проводиться "изнутри", то через очень короткое время объект зависнет или будет отключен от интернета. Этот способ не требует больших вычислительных ресурсов нападающего, однако такая

пользовать в атаке типа "SYN Flood".

packet.ip.version=4; // Версия packet.ip.ihl=5; // Длина заголовка packet.ip.tos=0; // Тип сервиса packet.ip.tot_len=htons(40); // Общая длина packet.ip.id=getpid(); // Идентификатор packet.ip.frag_off=0; // Смещение фрагмента packet.ip.ttl=255; // Время жизни packet.ip.protocol=IPPROTO_TCP; // Протокол packet.ip.check=0; // Контрольная сумма packet.ip.saddr=saddress; // Адрес источника

packet.ip.daddr=daddress; // Адрес назначения

TCP flood - это вид атаки, при котором потенциальной жертве отправляется множество TCP-пакетов, что приводит

êсвязыванию системных ресурсов. Следующие виды DoS-атак основа-

ны на совершенно другом принципе. При помощи таких атак можно переполнить сеть или отдельно взятую мишень абсолютно бесполезными ping-пакетами. Для реализации следующих видов атаки достаточно нескольких строк кода. Итак, это атаки, основанные на протоколе ICMP:

PING OF DEATH È ICMP FLOOD

Большое количество DoS-атак основывается на протоколе ICMP. Некоторые его функции могут быть полезны для создания нападений такого рода. ICMP flood - это далеко не новый вид атаки, который, тем не менее, не теряет популярности. Здесь используется

ping. Ping изначально задумывался для проверки качества соединения с удаленным компьютером. Принцип работы следующий: программа отсылает некое сообщение, на которое удаленный компьютер автоматически отве- чает. Вроде бы все нормально. Однако при атаке используются большие (64 кБ), сильно фрагментированные ICMP-пакеты. При получении таких пакетов удаленная машина зависает.

Ping of Death основывается на ICMP flood, однако усиливает атаку за счет того, что ping-запросы пересылаются по адресу широковещательной рассылки. Используемый в пакетах запроса адрес - это адрес атакуемого сервера. Получившие такие "посылки

Схема работы FloodGuard (системы защиты)

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

UDP FLOOD

Это наиболее опасный вид атаки. UDP-сервис одной машины генерирует последовательность символов для каждого получаемого системой пакета. Делается это в целях тестирования. Далее связывается с echo-серви- сом другой машины, которая повторяет эти символы. В результате, передается большое количество UDP-паке- тов с подделанным IP источника. Основная проблема для защиты состоит в том, что протокол UDP не устанавливает соединения и нет никаких индикаторов состояния, чтобы помочь межсетевой защите выявить нападение. Чтобы с большей долей вероятности избежать такой атаки, нужно удалить все ненужные UDP-сервисы, а остальным сервисам использовать механизм прокси-сервера.

САМЫЕ МОЩНЫЕ DOS/DDOS-АТАКИ

Теперь ты знаешь, что собой представляет атака на отказ в обслуживании. Пришло время составить небольшой хит-парад DoS/DDoS-атак.

1.Пожалуй, самой нашумевшей атакой из разряда DoS стала атака на корневые DNS-сервера, произошедшая в ноябре 2002 года. Тогда распределенной атаке подверглись все 13 DNS-серверов, семь из которых вышли из строя. Только высокий уровень избыточности в структуре интернета позволил избежать задержек при обращении к ресурсам.

2.Атака на сайт SCO, совершенная при помощи вируса MyDoom и всех его подцепивших. 22 августа 2003 года сайт компании SCO перестал отве- чать на запросы пользователей. Атака продолжалась несколько дней и прекратилась только 25 августа. Поскольку вирус MyDoom имел очень широкое распространение, то атака получи- лась мощнейшей. Вторая редакция вируса MyDoom.B, созданная для атаки

41

на сайт Microsoft, не имела такого "успеха" у пользователей.

3. Серверы Osirusoft крупнейшего хранилища IP-ад- ресов, замеченных в спаме, были отключе- ны после большого количества распределенных атак на отказ в обслуживании. Данная служба занималась ведением динамического списка IP-адресов, замеченных в спаме.

Атаки на отказ в обслуживании, несомненно, большое зло на просторах интернета. И если отдельно взятую пользовательскую машину можно защитить с помощью фаервола, то для серверов стопроцентной защиты нет и в скором времени не предвидится. Так что с DoS/DDoS-атаками сложилась довольно грустная (или веселая? :)) ситуация. Многие хостеры при обнаружении атаки просто выключают сервера. Это о чем-то говорит ;). E

SYN-FLOOD.

Способы подключения к жертве(2 вида атаки)

42 ВЗЛОМ ОТЫЩИ И ВЫПОЛНИ!

Докучаев Дмитрий aka Forb (forb@real.xakep.ru)

ОТЫЩИ И ВЫПОЛНИ!

УДАЛЕННОЕ ВЫПОЛНЕНИЕ КОМАНД

X акеры способны атаковать сервер со всех сторон. Взломщик может использовать эксплоит или поразить сервер командой, выполненной через дырявый сценарий. HTTP-демон является самой опасной стороной сервера, которая

скрывает за собой возможность интерпретирования практически любой *nix-команды. Об этом и многом другом ты прочтешь в данном материале.

По умолча- нию, директива allow_url_fo pen разрешена. Это означает, что функция fopen() способна подгрузить любой удаленный скрипт.

В PHP также можно произвести атаку на system(). Для этого необходимо поставить ";" по краям переменной, а саму переменную представить в виде команды.

верждение, что удаленно выполнять команды можно только через Web, ошибочно. Любой рабо- чий эксплоит, нацеленный на бажный сервис, способен выполнить какое-ли- бо действие. Это может быть добавление пользователя, запуск интерпретатора и т.д. Важно то, что сам факт переполнения буфера приводит к фатальной ошибке и, как следствие, к удачному выполнению команды. Я бы с удовольствием раскрыл все тайны переполнения, но это уже было сделано в Спеце #08.04(45), посвященном дырявым буферам.

Второй способ - атака через Web. На тысячах Web-серверов крутятся миллионы бажных сценариев, через которые можно выполнять системные запросы. Некоторые админы не исправляют уязвимые сценарии, так как надеются на фаервол, но грамотный взломщик может влегкую отключить брандмауэр даже через Webлазейку. Я расскажу о самых известных уязвимостях в CGI/PHP-скрип- тах, эксплуатация которых приводит к фатальным последствиям.

АТАКА НА ПАЙПЫ

Начнем с самой популярной ошибки программистов. Баг таится в функции open(), которая есть в каждом более-менее серьезном сценарии. Суть ошибки состоит в следующем: функции передается имя файла, который необходимо прочитать и вывести на экран. Само имя поступает с входа CGI-потока, то есть задается удаленным пользователем как параметр скрипта. Всем известно, что open() понимает символ перенаправления (пайп) "|". Если этот символ встретится перед именем или после имени, функция попытается обратиться к файлу и выполнить его как команду! Хакеру достаточно изменить параметр скрипта на команду и обрамить ее вертикальными палочками.

Рассмотрим это на наглядном примере. Пусть в сценарии юзается следующий код:

$file=param('file'); open(FILENAME,$file); while(<FILENAME>) { print } close(FILENAME);

Мы видим, что переменная $file поступает с потоком данных. Она не проверяется на наличие каких-либо спецсимволов, поэтому хакер без проблем может добавить в переменную парочку пайпов. При нестандартном запросе в open() поступит переменная "|id|", которая выполнится как команда, а результат будет выведен на экран. Не думай, что этих скриптов мало - по статистике, каждый третий сервер можно атаковать таким тривиальным запросом.

SYSTEM() ПОГУБИТ МИР

Как известно, функция system() предназначена для выполнения системных команд. Изредка ее используют в CGI-сценариях, запуская внешние приложения. Ничего страшного не происходит, если системный запрос не содержит пользовательских параметров скрипта. В противном слу- чае злоумышленник может добиться выполнения произвольной команды. Рассмотрим пример бажного кода. Проект, из которого он позаимствован, и по сей день находится в онлайне, его код удалось выцепить после успешного эксплуатирования ошибки.

#!/usr/bin/perl

### Simply Perl-Whoiser by XXX.

use CGI qw(:standard); $host=param('host'); system("whois $host > log");

...

После того как скрипт получил параметр host, он выполняет system() с этой опцией безо всякой проверки символов. Стоит атакующему подставить в переменную $host (читай: в параметр скрипта host) символ ';', а за

ним произвольную команду, как в файл log поместится уже не ответ бинарника /usr/bin/whois, а команда взломщика. К примеру, запрос вида http://victim.com/whois.cgi?host=blabla.ru;id покажет текущего пользователя (то есть пользователя, с правами которого выполняются CGI-скрипты на сервере).

SENDMAIL - ВРАГ НАРОДА

Я не могу не упомянуть про старый добрый баг в вызове sendmail, который до сих пор можно отыскать в тухлых скриптах. Ошибка заключа- ется в использовании опции -t. Этот параметр позволяет указывать имя получателя в командной строке. Часто при таком раскладе это имя берется из входных данных CGIскрипта и не проверяется на спецсимволы. Вот фрагмент кода уязвимой гостевой книги:

use CGI qw(:standard); $email=param('email');

open(MAIL,"|/usr/sbin/sendmail -t $email");

print MAIL "From: admin@victim.com\n"; print MAIL "Subject: Thanks\n\nThank

you!\n";

close(MAIL);

Как видно, переменная $email никоим образом не проверяется, что может привести к нежелательным последствиям. Стоит только указать на странице e-mail в виде lamer@xakep.ru|cat /etc/passwd, и

Пара пайпов - и команда выполнена!

Если в CИшном коде программиста заботит явление переполнения буфера, то Web-раз- работчика в первую оче- редь должны волновать параметры, передаваемые CGI-сцена- рию.

Ничто не мешает хакеру залить эксплоит через Web, получить рутовые права и насильно отключить фаервол.

операционной системы зависит от ядра, давай обратим внимание именно на эту часть ОС.

вольно сложно разобраться в структуре системы и ядре. Ядро полностью скрывает специфику компьютера от пользователя, но в то же время зависит от этой специфики.

ОСНОВЫ

Первое, с чем нам предстоит столкнуться, - понятие пользователя. Здесь пользователь - это некто (нечто), имеющий свою учетную запись, состоящую из имени и пароля и еще некоторых данных, например, домашней директории. Ядро UNIX "узнает" пользователя по UID (User IDentifier) - идентификатору, который представляет собой уникальное целое число, присваемое при регистрации (автоматически или вручную админом). Пользователь относится к некой группе, определяемой GID'ом (Group IDentifier). Администратору системы отводится нулевой UID. Пользователь с таким UID называется root (рут). Это наиболее интересный персонаж, поскольку он имеет полный контроль над системой. Идеальный вариант использования ка- кой-либо уязвимости для захвата системы – получение прав рута.

Любой пользователь в процессе работы так или иначе обращается к файлам, и здесь нельзя избежать упоминания о файловой системе (ФС).

ФС присуща древовидная структура, совершенно непривычная для пользователя DOS (Windows). Корневой каталог всегда имеет имя "/". Но это не значит, что в *nix возможно использование только одного устройства для хранения информации. "Куски" файлового дерева системы чаще всего размещаются на разных носителях, но логически это одна система. Каждый зарегистрированный пользователь имеет так называемую домашнюю директорию. В ней пользователь - царь и бог :). Теоретически юзер мо-

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

Подсистема управления файлами В UNIX каждому файлу в соответствие ставится некий индекс, в котором содержатся описание размещения информации на физическом носителе, права доступа, владелец и другие данные. Каждый файл имеет только один индекс. Когда процесс обращается к файлу по имени, ядро возвращает индекс файла. То есть

каждое имя является указателем. Индексы хранятся в файловой сис-

теме, однако при работе с файлом ядро заносит их в таблицу индексов, которая находится в ОЗУ. Кроме таблицы индексов, ядро использует еще две информационные структуры: таблицу файлов и таблицу дескрипторов файла. Пользователь может полу- чить доступ к файловым дескрипторам и раскрыть информацию.

Итак, основные компоненты файловой системы:

-Блок загрузки. Располагается в на- чале файловой системы и содержит программу начальной загрузки.

-Суперблок. Здесь обозначаются свойства файловой системы: размер, расположение свободного пространства, количество файлов и другая информация.

-Список индексов. Размер списка указывается администратором при генерации файловой системы.

-Информационные блоки. Содержат данные файлов, а также служебные данные. Информационный блок может принадлежать только одному файлу.

Подсистема управления процессами После того как загрузка ядра выпол-

нена, нужно как-то создавать, завершать и следить за существующими процессами и нитями (здесь нить - это

ßäðî

"процесс", выполняемый на общей виртуальной памяти). Этим занимается функция управления процессами и нитями. Ввиду мультипроцессорности *nix ядро обеспечивает разделение процессорного времени или процессоров, что создает эффект параллельности выполнения разных задач. Ядро – это невыгружаемый компонент, и поэтому процесс, выполняющийся в режиме ядра, продолжает свое выполнение до тех пор, пока не вернется в режим задачи либо пока не перейдет в состояние «сна». Благодаря невыгружаемости ядро обеспечивает целостность информационных структур и стабильность работы.

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

ГОРЕ ОТ УМА, ИЛИ ПРОБЛЕМЫ "ИДЕАЛЬНОЙ" АРХИТЕКТУРЫ

Как видно из вышесказанного, архитектура ОС в целом и архитектура ядра в частности - это стройная, хорошо продуманная система взаимодействия компонентов. Однако несмотря на это любая *nix - уязвимая система. В том числе и на самом нижнем уровне – ядре. Одна из основных причин уязвимостей ядра – возраст ОС. С одной стороны, клоны этой операционной системы становятся популярнее день ото дня в течение 25 лет, и это уникальный случай! Кроме того, на протяжении этих лет наращиваются и возможности системы, что является большим плюсом. Однако качественные улучшения структуры не успевали (и не успевают) за ростом ее возможностей. И поэтому можно утверждать, что современные варианты UNIX структурированы не идеально. Рассмотрим основные типы уязвимостей.

Переполнение буфера (buffer overflow)

Одна из самых распространенных уязвимостей программного обеспече- ния и ОС в частности. Эту уязвимость вызывает небольшая ошибка, позволяющая, однако, творить чудеса. Ошибка переполнения буфера случа- ется, если в программе происходит копирование данных без проверки свободного места в пункте назначения (буфере). Когда данных слишком много, происходит переполнение и информация попадает за границы буфера. Умелое использование этого факта позволяет запускать произвольный код с правами переполненного приложения (то есть вполне может быть, что с правами администратора). Существует огромное количество такого рода уязвимостей. Главная при- чина уязвимости - использование не-

45

которых функций стандартной библиотеки языка С, не проверяющих размеры своих аргументов (например strcpy, strcat, gets или sprintf), а *nix-сис- темы (в том числе и большая часть ядра), как ты помнишь, почти целиком написаны на C. Актуальность этой уязвимости доказывает хотя бы последний найденный баг. В UNIX 9.x найдены множественные переполнения буфера в функциях strcpy() и p_stcopy(), позволяющие локальному пользователю переписывать в стеке значение регистра eip, что может привести к выполнению произвольного кода c root-правами (см. www.securitylab.ru).

Уязвимость состояния операции Данная проблема характерна как для *nix, так и для Windows. В никсах эта дырка обнаруживается в ядре и

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

Если вышеперечисленные проблемы ядра носят «хронический» характер, то следующие уязвимости – разовые, характерные для определенного клона и его версии:

1.таблица перенаправления может быть подменена удаленными пользователями, если посылать пакеты с подделанным исходным адресом;

2./proc/tty/driver/serial раскрывает точное число введенных символов через последовательные ссылки. В результате локальный атакующий может определить длину пароля и задержку между нажатиями клавиш в те- чение ввода пароля;

3.локальный пользователь может эксплуатировать уязвимость состояния операции чтения файла в системном вызове execve(), чтобы аварийно завершить работу системы;

4.уязвимость в программе обработки TCP-опций входящих пакетов. Причем уязвимость действительна, если в правилах встроенного фаервола применяется tcp-option. Во всем виновата функция tcp_find_option, которая некорректно обрабатывает поле длины пакета. Если это значение больше 127, программа зацикливается. Таким образом, можно исчерпать системные ресурсы и вызвать отказ в обслуживании (DoS).

Итак, мы видим, что ядра систем *nix уязвимы. Некоторые уязвимости возникают из-за непосредственных ошибок при реализации. Другие – плоды изначально неправильной структуры ядра. E