Pull to refresh

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

Reading time 8 min
Views 114K
Всё началось с того, что ко мне (как к фрилансеру) обратились за помощью и попросили настроить 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'у!
Tags:
Hubs:
+560
Comments 150
Comments Comments 150

Articles