Grabduck

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

:

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

Работы на пару часиков включая обновление 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'у!