Критическая уязвимость Vesta CP диагностика и лечение

На протяжении последних нескольких дней появились панические сообщения о взломах серверов с панелью управления Vesta CP.

В этой статье мы расскажем Вам, как проверить свой сервер и как поступать, если Ваш VPS или VDS уже скомпрометирван.

На момент написания этой статью основным источником информации является форум VestaCP, мы рекомендуем обращаться именно к этому ресурсу за актуальной информацией.

Что известно в данный момент?

С конца марта производились автоматизированные взломы различных ОС семейства *nix (Centos, Debian, Ubuntu различных версий). Далее, после получения доступа к ОС, загружался и запускался вредоносный код — Trojan.DDoS_XOR. Подробнее об этом семействе вредоносного ПО см. документ от CheckPoint.

Взломы не связаны с Вашими паролями, CMS или настройками – были взломаны виртуальные сервера, где не было работающих сайтов, однако была установлена панель управления Vesta CP.

Этот вредоносный код используется для организации DDoS-атак удаленных узлов. По команде из командного центра (C&C – command and control center) начинает производится атака (syn-флуд, udp-флуд и т.п.) адреса, полученного из центра управления. Так как используются все доступные ресурсы, в случае подобной атаки адрес отправителя (то есть – зараженного сервера или VDS в данном случпе) достаточно легко и в большинстве случаев автоматически может быть определен и заблокирован либо провайдером услуг, либо оператором связи.

Таким образом, если ваш сервер в течение последних 2-3 суток был недоступен какое-то время (или генерировал необычно много трафика) и вы используете Vesta CP – очень велика вероятность заражения Вашей системы. Мы настоятельно рекомендуем проверить свои сервера всем пользователям Vesta CP.

Как определить, взломана ли система? Давайте проверим. Авторизуйтесь с помощью ssh и выполните команду:

find /etc -name gcc.sh -print

Если результатом работы команды будет:

/etc/cron.hourly/gcc.sh

То Ваш сервер, скорее всего заражён.

Паниковать не стоит – избавиться от этого трояна довольно просто. Вы можете сделать это сами, можете обратиться в поддержку Вашего провайдера или к своему системному администратору.

Расскажем, как это сделать самостоятельно и проверить затем результаты лечения. (помните, все действия Вы производите на свой страх и риск, делайте бэкапы).

Самое главное – не торопитесь и не волнуйтесь. Выполните резервную копию Ваших данных и настроек. Резервную копию стоит хранить отдельно от сайтов – на другой VDS, на сетевом хранилище, на Dropbox или Google Drive и т.д.

Поехали!

Блокируем gcc.sh:

chmod 0 /etc/cron.hourly/gcc.sh; chattr +ia /etc/cron.hourly/gcc.sh; chattr +i /etc/crontab

Далее ищем работающего трояна в памяти. Есть два варианта – один называется update, второй (обновленный) имеет имя (ahzihydns, rangqpbjp). В списке процессов не всегда можно бегло видеть эти модули, потому что они меняют имя процесса на что-то похожее на работу стандартных утилит. Мы попробуем по-другому.

Для начала ищем первый вариант, используя lsof:

# lsof -n |grep /tmp/update
update 31116 root txt REG 253,2 625611 146301 /tmp/update
update 31116 31124 root txt REG 253,2 625611 146301 /tmp/update
update 31116 31125 root txt REG 253,2 625611 146301 /tmp/update
update 31116 31126 root txt REG 253,2 625611 146301 /tmp/update

Если будет подобный вывод – присутствует первый вариант зловреда. Запомните 31116 – это ID процесса.

Прибиваем процесс:

kill -STOP 31116

И удалим файл:

rm /tmp/update

Уничтожаем процесс:

kill -9 31116

Проверим с помощью lsof -n |grep /tmp/update – как правило, все проходит гладко и в памяти вредоносного кода не остается.

Далее следует удалить файл /etc/init.d/update, если такой существует.

Затем удаляем /lib/libudev.so:

rm /lib/libudev.so

Второй вариант зловреда остановить чуть сложнее. Проверим, есть ли подозрительные файлы в /usr/bin:

# ls -lt /usr/bin | head -20

итого 171828
-rwxr-xr-x 1 root root 625622 апр 4 00:01 xmpwotmqnr
-rwxr-xr-x 1 root admin 625633 апр 3 23:55 lluoohrpal
[...]

 

Видно, что есть два очень похожих бинарных файла, которые отличаются немного по размеру. Имена файлов могут меняться, поэтому попробуем автоматизировать остановку и удаление процессов. Запомним их размер, и остановим процессы с помощью небольшого скрипта. Если у вас файлы другого размера – укажите их в параметре вызова egrep.

kill -STOP `lsof -n | egrep "625622|625633" | grep -v deleted| awk '{print $2}' | uniq`

Смотрим список файлов, которые нужно удалить:

# lsof -n | egrep "625622|625633"
xmpwotmqn 1120 root txt REG 253,2 625622 1519267 /usr/bin/xmpwotmqnr
xmpwotmqn 1120 1169 root txt REG 253,2 625622 1519267 /usr/bin/xmpwotmqnr
xmpwotmqn 1120 1170 root txt REG 253,2 625622 1519267 /usr/bin/xmpwotmqnr
xmpwotmqn 1120 1171 root txt REG 253,2 625622 1519267 /usr/bin/xmpwotmqnr

Смело удаляем /usr/bin/xmpwotmqnr, /usr/bin/lluoohrpal и, конечно, /lib/libudev.so.

Теперь уничтожаем процесс, который остановили ранее.

kill -9 `lsof -n | egrep "625622|625633" | awk '{print $2}' | uniq`

Далее стоит проверить содержимое /etc/init.d – там могут находится остатки вредоносного кода. Нам представляется, что они не представляют опасности, так как бинарные модули удалены. Вместе с тем, стоит удалить (или переместить для анализа) /etc/init.d/update и файлы, имя которых совпадает с именами бинарных модулей.

В проанализированных нами случаях размер файлов был равен 323 байта, например:

-rwxr-xr-x 1 root admin 323 апр 3 23:55 xbzrqmaaqo
-rwxr-xr-x 1 root admin 323 апр 3 23:55 xdphzejxlx
-rwxr-xr-x 1 root admin 323 апр 3 23:55 xdzluubldx
-rwxr-xr-x 1 root admin 323 апр 3 23:55 xgqggmacwf
-rwxr-xr-x 1 root root 323 апр 8 13:50 xmpwotmqnr

Если таких файлов много, их можно удалить с помощью find (будьте аккуратны с использованием find с ключем -delete, ошибка может привести к потере данных):

find /etc/init.d/ -type f -size 323c -delete

Поздравляю, Вы прибили на сервере Unix.Trojan.DDoS_XOR-1 (Linux/Xorddos).

Проверяем список процессов с помощью команд ps, lsof – подозрительной активности быть не должно.

Абсолютно не лишним будет просканировать систему при помощи антивируса Clam.

Установим антивирус – для Centos нужно выполнить yum install clamav, для Debian/Ubuntu – apt-get install clamav. Затем запустим сканирование –

clamscan -r -i /

В процессе сканирования могут возникать ошибки, следует обратить внимание на показатель Infected Files. Если онотличен нуля, необходимо найти и удалить вредоносные бинарные файлы.

Как не допустить подобных ситуаций?

Обновляйте Ваше ПО, используйте SSL, ограничьте доступ к интерфейсу управления панели и приложениям (FTP, webmail, «админки» CMS) – доступ должен быть только с доверенных IP.

И самое главное — делайте резервные копии.

Сделано в Одессе
Сайт находится в состоянии наполнения контентом, приносим свои извинения за временные неудобства.