Нифига себе сходил за хлебушком, или история одного взлома

Всё началось с того, что ко мне (как к фрилансеру) обратились за помощью и попросили настроить exim4 так, чтобы почтовая рассылка не попадала в спам. Даже заботливо ссылку прислали на замечательную статью.

Работы на пару часиков включая обновление DNS, но не тут то было. Залогинившись под рутом я включил свой любимый screen по привычке командой screen -x и лицезрел прелюбопытнейшее действо в любимой многими папке /dev/shm. Злоумышленник не удосужился прикрыть сессию screen, либо всё еще работал в ней. И тут начинается квест:

Первое, что я сделал — просмотрел, чем же занимался злоумышленник:

Судя по всему рассылал спам и запускал некий файл ".x" (или это была папка?), а еще проверял ssh соединение. Там же лежал архив с php скриптом lol.php, который я к сожалению забыл сохранить.

Вывод команды last и who не показали ничего сверхестественного, root сессий за месяц не было, что и подтвердил владелец сервера. Однако…

показал established соединение с IP 172.190.125.14, которое я тут же прибил.

Обратил внимание на /usr/sbin/sshd

Удаление файла ни к чему ни привело:

Переустанавливаю openssh-server и openssh-client. Вроде всё хорошо, угрозы нет, больше ничего подозрительного не нашлось. Решил заодно обновить систему, да и tzdata старый был (привет Медведеву!). Проверил /etc/apt/sources.list и /etc/apt/sources.d. Все файлы в порядке, никаких левых строк, даты не менялись с год. И после apt-get update наложил все security обновления на Debian Lenny, включая новое ядро. Ну что. Нужно перезагружаться. Попросил на всякий случай KVM (как оказалось не зря) и начал ждать.

На следующий день предоставили KVM. Набрал «reboot» и тут на тебе: десятки segmentation fault. Волосы начинают седеть, руки трястись. В общем я думаю многие представляют мою ситуацию. Как говорится «если работает — не ТРОЖЬ!», но после обнаружения проникновения пришлось наложить обновления и перезагрузиться.

Короче говоря взял себя в руки, начал изучать в чем дело и загрузился в single user. Команда mount каждый раз при вызове вызывает segmentation fault, даже без параметров. Файловая система readonly, сделать ничего нельзя. /etc/fstab в порядке, df тоже работает. Команда date почему-то тоже сегфолтится. Запустил проверку диска (софтварный raid1) fsck.ext3 /dev/md0 — всё в порядке, никаких отклонений. В чем же дело? Тут я начинаю думать, что систему положил я, т.к. обновил пакет tzdata, который как раз таки связан со временем. И тут рвется DSL соединение с моим провайдером… Ребутаю модем — соединение поднимается, ну и славненько!

Владелец сервера негодует, т.к. сервер в дауне уже несколько часов, и решает написать тикет в суппорт «Инфобокса». Я же на измене, продолжаю ковыряться в системе. Самым вменяемым решением мне кажется перезагрузить машину и загрузиться с liveusb, чтобы диск был RW, а далее по обстоятельствам. Начал дебажить mount возможными на данный момент способами. gdb установлен не был, был лишь ldd, который ничего серьезного не показал и export LD_DEBUG=all, который тоже ничего сверхестественного не выявил. Сегфолт тупо начинался после инициализации всех библиотек. Тут KVM мне говорит, что его отключили. Ясно, суппорт подбежал. Ушел от ноутбука и начал думать дальше…

Пока стоял и дышал свежим воздухом, ко мне в голову забежал очень образованный таракан и сказал «А что если файлы, которые вызывают сегфолт, подмененные?». Сказано сделано. Жду что скажет клиент насчет тикета суппорту. Через несколько минут он пересылает мне ответ суппорта:

Повреждена таблица разделов, экспресс-методами восстановить ее не представляется возможным.

Если хотите, мы можем привлечь наших системных администраторов (стоимость работ составляет 870 рублей в час) для восстановления.

Либо же Вы можете это сделать самостоятельно. В таком случае рекомендуем воспользоваться Gpart (http://packages.debian.org/ru/sid/gpart)

Хрена себе подумал я… Говорю клиенту, что не может такого быть, т.к. fsck произвел проверку диска и никаких нарушений в файловой системе не выявил. Клиент пишет ответ суппорту, а в это время возвращается доступ к KVM, где я вижу всё те же тщетные попытки вызвать mount, hdparm, который в системе не установлен, и работа с fdisk.

Последняя же вывела ни что иное как:

Disk / dev / sda: 160.0 GB, 160041885696 bytes 255 heads, 63 sectors / track, 19457 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x000f0571

Device Boot Start End Blocks Id System / dev / sda1 1 18480 148440568 + fd Linux raid autodetect / dev / sda2 18481 19457 7847752 + fd Linux raid autodetect

Disk / dev / sdb: 160.0 GB, 160041885696 bytes 255 heads, 63 sectors / track, 19457 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x00000000

Device Boot Start End Blocks Id System / dev / sdb1 * 1 18480 148440568 + fd Linux raid autodetect / dev / sdb2 18481 19457 7847752 + fd Linux raid autodetect

Disk / dev / md0: 152.0 GB, 152003018752 bytes 2 heads, 4 sectors / track, 37110112 cylinders Units = cylinders of 8 * 512 = 4096 bytes Disk identifier: 0x00000000

Disk / dev / md0 doesn 't contain a valid partition table

Disk /dev/md1: 8036 MB, 8036024320 bytes 2 heads, 4 sectors/track, 1961920 cylinders Units = cylinders of 8 * 512 = 4096 bytes Disk identifier: 0x00000000

Disk /dev/md1 doesn' t contain a valid partition table

Вот на основе последних Disk /dev/md0 doesn't contain a valid partition table суппорт и выяснил, что проблема то оказывается в таблице разделов. Действительно, как я раньше не догадался. Ведь fdisk никогда не видел таблицы разделов программного raid. Отписываю все мои мысли клиенту и начинаю разрабатывать коварный план того самого таракана. Представляю чем бы закончилась эпопея суппорта и сколько бы она заняла, согласись клиент на их помощь. Да и сумму подсчитать не сложно.

Смотрю на дату изменения /bin/mount — время последней загрузки сервера. Перезагружаюсь, опять проверяю дату — время последней загрузки сервера. Странно. Значит что-то при загрузке модифицирует этот файл и с этим «что-то» нужно что-то делать.

/tmp — в readonly. Чтобы загрузить файл на сервер, нужна файловая система с правом записи. Вспоминаю о /dev/shm. Поднимаю сетевой интерфейс, присваиваю IP, и скачиваю deb пакет mount для lenny. Распаковываю, запускаю — вуаля! Работает! Перемонтирую файловую систему, теперь она RW. Дело пошло!

Проверяю файлы в /bin/ и вижу следующую картину:

Причем дата изменения файлов меняется каждые 3 минуты и 10 секунд. Начинаю просматривать crontab'ы, ничего не нахожу. Отловить lsof'ом какой процесс изменяет файлы не получается. Вывожу ps auxww и вижу, что висит некий процесс cat /sys/class/net/lo/operstate