Разоблачение хакера

Master-lame-master

Xakep, номер #061, стр. 061-052-2

Хакер открыл файл ~owner/.bash_history и почитал команды администратора с целью обнаружить там пароль для root. Интуиция не подвела нашего героя: админ ошибся в написании команды “su”, после чего следовал рут-пароль в plain-тексте. Это довольно типичная ошибка админов. Вообще, в .bash_history можно найти очень интересные команды ;).

Напоследок хакер должен был создать какую-либо маскировку в системе, чтобы администратор не засек его пребывание. Наскоро был поставлен руткит, скрывающий файлы, а также написан сишник, запускающий /bin/bash с правами root (посредством suid-бита). Затем взломщик создал файл /var/adm/.profile и написал туда всего две строки:

/var/lib/modules/linux.so

exit

Естественно, что linux.so являлся бинарником, в котором был последовательный запуск чистилки логов и шелла через исполняемый файл Adore (packetstormsecurity.nl/groups/teso/adore-0.14.tar.gz).

Затем хакер стер шелл у пользователя adm. Мало кто знает, что при отсутствии шелла юзеру присваивается дефолтовый интерпретатор /bin/sh. Он обрабатывает файл ~/.profile, а в нашем случае там содержался запуск рутового /bin/bash. После завершения сеанса выполнилась команда exit.

Сетевой ковырятель позаботился и о чистке бинарных логов, интегрировав linux.so с чистилкой vanish. Почистив логи и установив пароль юзеру adm, хакер удалился из системы. Теперь ему оставалось сконтачиться с заказчиком и предоставить ему доступ на хостинг. Именно это и произошло бы, если бы не бдительность системного администратора.

Разбор полетов

Поздней ночью администратор хостинга (он же owner) решил зайти в систему. Внутренний голос подсказывал ему, что с сервером что-то не так :). Проверив таблицу процессов и поверхностно изучив логи, админ успокоился – вроде бы все на своих местах. Администратор вспомнил о недавно установленной Tripwire (download.sourceforge.net/tripwire/tripwire-2.3.1-2.tar.gz). Она уже несколько дней слала ночные отчеты на его мыло. Хакер же совсем не заметил эту IDS в процессах, поэтому не позаботился о чистке ее логов.

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

В системе было довольно много пользователей, и на первый взгляд уловить, что именно поменял хакер в файле, не представлялось возможным. Если бы не логи, администратор так и не узнал бы метод атаки хакера. Я упоминал, что взломщик вычистил все системные журналы, но не посмотрел настроенный /etc/syslog.conf. А в нем содержалась следующая строка:

*.* root@home.rt.ru