Ebury. Выводим рут с сервера.

Недавно словило несколько клиентов эту, как уже во время расследования, гадость :)

Проблема понятно какая - наличие руткита лечится реинсталом, но, естественно, редко клиент на это согласен, так как даунтайм весьма нежелателен.

Решил поделиться своими потугами, может кому будет полезно, либо кто чего посоветует.

Если кто еще не слышал - так называемый "Ebury" - это что-то типа SSH rootkit'a, похожий на уже существующий Ebury. Руткит позволяет зловреду входить на сервер по хардкорно зашитому паролю в любой момент, а также при каждом входе пользователя на сервер по SSH отпарвлять его IP и введенный пароль на коллектор зловреда.

Судя по наблюдениям есть разные версии этого руткита, но в среднем можно отметить, что изменяются libkeyutils, сам ssh демон и, самое противное, ssh клиент. Иногда заражен только libkeyutils, иногда все вместе заменено.

Проблема в паблик впервые активно стала обсуждаться, по-моему, с этого топика - http://www.webhostingtalk.com/showthread.php?t=1235797.

Если почитать все топик видно, что до сих пор ходят разные слухи каким образом в самый первый раз эта гадость попадает на сервер.

Говорят об разных 0day узявимостях как на самом сервере, дырках в ядре, дырках на ПК клиентов в какой-нибудь Java.

Доподлинно неизвестно через что руткит лезет. Возможно ломатели используют все возможные дырки, поэтому невозможно выделить какой-то конкретной линии атаки, но точно могу сказать, что самое противное - это заражение по цепочки через ssh клиент. Сам, судя по всему, на это напоролся, администрируя зараженного клиента.

Смысл в том, что если вы с зараженного сервера зайдете ssh клиентом на свой супер защищенный сервер - пароль сразу же улетит в коллектор и ваш IP поместят в очередь на заражение. Не все сразу меняют пароль после того как подключились к серверу с постороннего сервера. И я был одним из таких - загрузил бэкап данных клиента на свой сервер и получил почти сразу абузу на портскан.

Вы скорее всего заражены, если:

1. К вам пришла абуза на какой-то странный netscan или ssh brute с вашего сервера. Либо конкретно абуза с пометкой "Ebury". Коллекторы периодически накрывают и по остаткам данных вытягивают список серверов-зомби, после чего делают abuse рассылку.

2. После захода на сервер по SSH по паролю от вас уходит UDP пакет на 53-ий порт. Не путать с тем, что смотрит PTR запись. Сообщение по типу: "7741e5e7255ce5fc71.64.1.31.5" Первая часть - наверняка HEX-представление зашифрованное представление введенного пароля, а вторая часть - IP, с которого был произведен логин.

Последнее наверняка используется, чтобы раскручивать клиента дальше. Проверить наличие трафика можно просто, например, запустить tcpdump в screen:

tcpdump -nli eth0 udp and port 53

И попробовать подключиться к самому себе:

ssh root@localhost

Даже не обязателно вводить корректный пароль - пакет в любом случае пошлется, если зараза есть.

3. Руткит использует shared memory, поэтому можно посмотреть есть ли какие-нибудь большие подозрительные сегменты shared memory с широко открытыми правами - 666. Пример зараженной машины:

ipcs -ma



------ Shared Memory Segments --------

key        shmid      owner      perms      bytes      nattch     status      

0x0000125b 32768      root       666        3281900    1

Т.к. nattch не равен 0 - можно попробовать грубо посмотреть в lsof кто реально использует этот кусок памяти:

lsof | grep 32768

Скорее всего выдаст sshd.

4. Если у вас на сервере есть какие-то левые libkeyutils. Например, для debian 32bit:

ls -lah /lib/libkeyutils.so.1*

lrwxrwxrwx 1 root root   20 Mar 27  2010 /lib/libkeyutils.so.1 -> libkeyutils.so.1.3.0

-rw-r--r-- 1 root root 6.5K Mar 27  2010 /lib/libkeyutils.so.1.3

-rw-r--r-- 1 root root  31K Mar 27  2010 /lib/libkeyutils.so.1.3.0

/lib/libkeyutils.so.1.3.0 - зараза. Но название зараженной библиотеки может отличаться. После бурного обсуждения руткита в сеть выложили bash скрипты, которые проверяли заражен ли сервер по наличию, если правильно помню, libkeyutils.so.1.6 или что-то типа того. Через несколько недель зловред стал создавать файлы с другим названием. Скорее всего если у вас несколько libkeyutils - стоит задуматься.

Исходя из предыдущих вещей можно попробовать почистить.

Для начала удалить shared memoery segments. В выводе ipcs -ma посмотреть shmid и удалить его:

ipcs -ma



------ Shared Memory Segments --------

key        shmid      owner      perms      bytes      nattch     status      

0x0000125b 32768      root       666        3281900    1



ipcrm -m 32768

Если есть левые libkeyutils - удалить и поменять симлинк:

ls -lah /lib/libkeyutils.so.1*

lrwxrwxrwx 1 root root   20 Mar 27  2010 /lib/libkeyutils.so.1 -> libkeyutils.so.1.3.0

-rw-r--r-- 1 root root 6.5K Mar 27  2010 /lib/libkeyutils.so.1.3

-rw-r--r-- 1 root root  31K Mar 27  2010 /lib/libkeyutils.so.1.3.0



rm /lib/libkeyutils.so.1.3.0 ; rm /lib/libkeyutils.so.1

cd /lib && ln -s libkeyutils.so.1.3 libkeyutils.so.1

На всякий случай переставить SSH демон и клиента и libkeyutils. Для Debian Squeeze 64 bit:

cd /tmp

wget http://ftp.us.debian.org/debian/pool/main/o/openssh/openssh-client_5.5p1-6+squeeze3_amd64.deb

wget http://ftp.us.debian.org/debian/pool/main/o/openssh/openssh-server_5.5p1-6+squeeze3_amd64.deb

wget http://ftp.us.debian.org/debian/pool/main/k/keyutils/libkeyutils1_1.4-1_amd64.deb

dpkg -i *.deb

Для Squeeze 32 bit

cd /tmp

wget http://ftp.us.debian.org/debian/pool/main/k/keyutils/libkeyutils1_1.4-1_i386.deb

wget http://ftp.us.debian.org/debian/pool/main/o/openssh/openssh-server_5.5p1-6+squeeze3_i386.deb

wget http://ftp.us.debian.org/debian/pool/main/o/openssh/openssh-client_5.5p1-6+squeeze3_i386.deb

dpkg -i *.deb

Перезагрузить SSH процесс, выйти из сервера и попытаться залогиниться на сервер, проверить вывод ipcs -m и трафик. Если все в порядке - shared memory больше не вылезет и пакеты никуда не уйдут.

После этого попробуйте на всякий случай с сервера подключиться к самому себе. Проверьте опять ipcs -m. Если что-то вылезло - ssh клиент все еще заражен.

Продлжаю наблюдать почищенными машинами со стороны - пока ничего не видно и не слышно. Понятное дело, что рутаной машине нельзя доверять, но возможно данный руткит не так глубоко залезает в систему, что шагов, описанных выше, достаточно, чтобы пережить проблему без реинстала :)

Надеюсь кому-то помог. Переходите на авторизацию по ключам :)