Всё началось с того, что ко мне (как к фрилансеру) обратились за помощью и попросили настроить 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
Рядом с sshd валялся sshd0
Удаление файла ни к чему ни привело:
Идем дальше
Переустанавливаю 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 мне говорит, что его отключили. Ясно, суппорт подбежал. Ушел от ноутбука и начал думать дальше…
Пока стоял и дышал свежим воздухом, ко мне в голову забежал очень образованный таракан и сказал «А что если файлы, которые вызывают сегфолт, подмененные?». Сказано сделано. Жду что скажет клиент насчет тикета суппорту. Через несколько минут он пересылает мне ответ суппорта:
Хрена себе подумал я… Говорю клиенту, что не может такого быть, т.к. fsck произвел проверку диска и никаких нарушений в файловой системе не выявил. Клиент пишет ответ суппорту, а в это время возвращается доступ к KVM, где я вижу всё те же тщетные попытки вызвать mount, hdparm, который в системе не установлен, и работа с fdisk.
Последняя же вывела ни что иное как:
Вот на основе последних 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
Скачиваю пакет с утилитой kill, переименовываю файл /bin/cat в /bin/cat_ и прибиваю процесс. Файлы перестают модифиццироваться. Победа. Теперь остаётся заменить все модифицированные файлы оригинальными. Скачиваю нужные пакеты и устанавливаю через dpkg -i *deb, предварительно проверив дату создания самого dpkg. После всех сделанных замен, скрестя пальцы, ввожу reboot и наблюдаю за окном KVM. Загрузка проходит успешно, сайт работает. Далее провожу сканирование скопированных мною зараженных файлов с помощью clamav и обнаруживаю Linux.RST.B-1 FOUND. Кто там говорил, что нет под Linux вирусов? Кстати 2001 года вирус…
Сканирование sshd и ssh ни к чему не приводят. Видимо это просто модифицированные ssh и sshd. Первый скорее всего отсылает логин и пароль при успешном подключении к серверу, второй скорее всего пускает на сервер всех с определенным паролем. Сейчас копать эти файлы нет сил, но желающие могут их скачать и покопаться: zalil.ru/32063611
P.S. Если в командах что-то не так, то прошу прощения, многие из них писал на память. Настраивать exim4 тоже отпало желание. Денег еще не просил. Да и за что? Основную задачу то не выполнил =)
P.P.S. Привет Infobox'у!
Работы на пару часиков включая обновление DNS, но не тут то было. Залогинившись под рутом я включил свой любимый screen по привычке командой screen -x и лицезрел прелюбопытнейшее действо в любимой многими папке /dev/shm. Злоумышленник не удосужился прикрыть сессию screen, либо всё еще работал в ней. И тут начинается квест:
Первое, что я сделал — просмотрел, чем же занимался злоумышленник:
wget http://ravenul.zzl.org/it/noi/up/8.txt
mv 8.txt list.txt
php lol.php
php lol.php
netstat -an | grep :22
w
rm -rf list.txt
w
rm -rf .x
netstat -an | grep :22
Судя по всему рассылал спам и запускал некий файл ".x" (или это была папка?), а еще проверял ssh соединение. Там же лежал архив с php скриптом lol.php, который я к сожалению забыл сохранить.
Вывод команды last и who не показали ничего сверхестественного, root сессий за месяц не было, что и подтвердил владелец сервера. Однако…
$ lsof -ni | grep ssh
показал established соединение с IP 172.190.125.14, которое я тут же прибил.
Обратил внимание на /usr/sbin/sshd
$ ls -la /usr/sbin/sshd
-rwxr-xr-x 1 root root 320724 Oct 11 23:29 /usr/sbin/sshd
Рядом с sshd валялся sshd0
$ ls -la /usr/sbin/sshd0
-rwxr-xr-x 1 root root 757356 Jul 31 2010 /usr/sbin/sshd0
Удаление файла ни к чему ни привело:
$ rm -f /usr/sbin/sshd
rm: cannot remove `/usr/sbin/sshd': Operation not permitted
Идем дальше
$ lsattr /usr/sbin/sshd
-u--ia------------- /usr/sbin/sshd
$ chattr -aui /usr/sbin/sshd
$ rm /usr/sbin/sshd
$ lsattr /usr/bin/* | grep -v -- '-------------------'
-u--ia------------- /usr/bin/ssh
$ chattr -aui /usr/bin/ssh
$ rm /usr/bin/ssh
Переустанавливаю 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.
Последняя же вывела ни что иное как:
$ fdisk -l
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/ и вижу следующую картину:
$ ls -latr /bin
-rwxr-xr-x 1 root root 96408 Nov 15 18:11 vdir
-rwxr-xr-x 1 root root 30896 Nov 15 18:11 pwd
-rwxr-xr-x 1 root root 30712 Nov 15 18:11 ping6
-rwxr-xr-x 1 root root 24252 Nov 15 18:11 nc.traditional
-rwxr-xr-x 1 root root 8612 Nov 15 18:11 mountpoint
-rwxr-xr-x 1 root root 68208 Nov 15 18:11 mount
-rwxr-xr-x 1 root root 32244 Nov 15 18:11 mknod
-rwxr-xr-x 1 root root 39144 Nov 15 18:11 loadkeys
-rwxr-xr-x 1 root root 17244 Nov 15 18:11 kill
-rwxr-xr-x 1 root root 9764 Nov 15 18:11 fgconsole
-rwxr-xr-x 1 root root 26216 Nov 15 18:11 false
-rwxr-xr-x 1 root root 8524 Nov 15 18:11 dmesg
-rwxr-xr-x 1 root root 96408 Nov 15 18:11 dir
-rwxr-xr-x 1 root root 51988 Nov 15 18:11 dd
-rwxr-xr-x 1 root root 59148 Nov 15 18:11 date
-rwxr-xr-x 1 root root 49440 Nov 15 18:11 chgrp
-rwxr-xr-x 1 root root 30956 Nov 15 18:11 cat
-rwxr-xr-x 1 root root 12252 Nov 15 18:11 bzip2recover
Причем дата изменения файлов меняется каждые 3 минуты и 10 секунд. Начинаю просматривать crontab'ы, ничего не нахожу. Отловить lsof'ом какой процесс изменяет файлы не получается. Вывожу ps auxww и вижу, что висит некий процесс cat /sys/class/net/lo/operstate
Скачиваю пакет с утилитой kill, переименовываю файл /bin/cat в /bin/cat_ и прибиваю процесс. Файлы перестают модифиццироваться. Победа. Теперь остаётся заменить все модифицированные файлы оригинальными. Скачиваю нужные пакеты и устанавливаю через dpkg -i *deb, предварительно проверив дату создания самого dpkg. После всех сделанных замен, скрестя пальцы, ввожу reboot и наблюдаю за окном KVM. Загрузка проходит успешно, сайт работает. Далее провожу сканирование скопированных мною зараженных файлов с помощью clamav и обнаруживаю Linux.RST.B-1 FOUND. Кто там говорил, что нет под Linux вирусов? Кстати 2001 года вирус…
Сканирование sshd и ssh ни к чему не приводят. Видимо это просто модифицированные ssh и sshd. Первый скорее всего отсылает логин и пароль при успешном подключении к серверу, второй скорее всего пускает на сервер всех с определенным паролем. Сейчас копать эти файлы нет сил, но желающие могут их скачать и покопаться: zalil.ru/32063611
P.S. Если в командах что-то не так, то прошу прощения, многие из них писал на память. Настраивать exim4 тоже отпало желание. Денег еще не просил. Да и за что? Основную задачу то не выполнил =)
P.P.S. Привет Infobox'у!
