Возможная уязвимость в Vesta и способ лечения от Trojan.DDoS_XOR
На протяжении последних дней появились сообщения о взломах серверов, где установлена панель управления Vesta. Далее мы опишем, каким образом можно проверить свой сервер, как защитить его и что делать, если VDS или выделенный сервер взломаны.
На момент написания данной заметки основным источником информации и обсуждения является форум VestaCP, мы рекомендуем обращаться к первоисточнику за обновлениями информации.
Что известно в данный момент? Производились автоматизированные взломы с конца марта, операционные системы — различные (Centos, Debian, Ubuntu различных версий). Далее, после получения доступа к операционной системе, загружался и запускался вредоносный комплекс Trojan.DDoS_XOR. Подробнее об этом семействе вредоносного ПО см. документ от CheckPoint. Проникновения не связаны с вашими паролями, CMS или настройками — были зафиксированы взломы виртуальных серверов, где отсутствовали сайты, а была установлена только панель управления Vesta в стандартной конфигурации.
Если кратко, то этот вредоносный комплекс используется для DDoS-атак удаленных узлов. По команде из командного центра (C&C — command and control center) начинает производится атака (syn-флуд, udp-флуд и т.п.) IP-адреса, который был получен из центра управления. Так как используются все доступные ресурсы, в случае подобной атаки IP-адрес отправителя (то есть — зараженного сервера или VDS) достаточно легко и в большинстве случаев автоматически может быть определен и заблокирован либо провайдером услуг, либо оператором связи.
Таким образом, если ваш сервер или VDS в течение последних 2-3 суток был недоступен какое-то время (или генерировал необычно много трафика) и вы используете Vesta — очень вероятно, что речь идет о том, что ваша система заражена. Вместе с тем, мы настоятельно рекомендуем проверить свои ОС всем пользователям, которые используют Vesta.
Как определить, взломана ли система? Давайте проверим. Авторизуйтесь с помощью ssh и выполните команду:
|
1 |
find /etc -name gcc.sh -print |
Если результатом работы команды будет /etc/cron.hourly/gcc.sh — у вас есть на сервере или VDS загруженный троянский код. Паниковать не стоит — избавиться от трояна достаточно просто. Вы можете сделать это сами, можете обратиться в поддержку вашего провайдера или к своему системному администратору.
Расскажем, как это сделать самостоятельно и проверить затем результаты лечения.
Самое главное — не спешите, не нервничайте и сделайте резервную копию своих данных и настроек. Резервную копию нужно держать отдельно от сайтов — на другой VDS, на сетевом хранилище, на Dropbox или Google Drive и т.д.
Приступим. Блокируем gcc.sh:
|
1 |
chmod 0 /etc/cron.hourly/gcc.sh; chattr +ia /etc/cron.hourly/gcc.sh; chattr +i /etc/crontab |
Далее ищем работающего трояна в памяти. Есть два его варианта — один называется update, второй (обновленный) имеет сгенерированное имя (ahzihydns, rangqpbjp). В списке процессов не всегда можно бегло видеть эти модули, потому что они меняют имя процесса на что-то похожее на работу стандартных утилит. Мы попробуем по-другому.
Для начала найдем первый вариант, используя lsof:
|
1 2 3 4 5 |
# 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 — это идентификатор процесса. Остановим процесс:
|
1 |
kill -STOP 31116 |
Удалим файл —
|
1 |
rm /tmp/update |
Теперь уничтожаем процесс:
|
1 |
kill -9 31116 |
Проверим с помощью lsof -n |grep /tmp/update — как правило, все проходит гладко и в памяти вредоносного кода не остается. Далее следует удалить файл /etc/init.d/update, если такой существует.
Затем удаляем /lib/libudev.so:
|
1 |
rm /lib/libudev.so |
Второй вариант зловреда остановить чуть сложнее. Проверим, есть ли подозрительные файлы в /usr/bin:
|
1 2 3 4 5 |
# 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.
|
1 |
kill -STOP `lsof -n | egrep "625622|625633" | grep -v deleted| awk '{print $2}' | uniq` |
Смотрим список файлов, которые нужно удалить:
|
1 2 3 4 5 |
# 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.
Теперь уничтожаем процесс, который остановили ранее.
|
1 |
kill -9 `lsof -n | egrep "625622|625633" | awk '{print $2}' | uniq` |
Далее стоит проверить содержимое /etc/init.d — там могут находится остатки вредоносного кода. Нам представляется, что они не представляют опасности, так как бинарные модули удалены. Вместе с тем, стоит удалить (или переместить для анализа) /etc/init.d/update и файлы, имя которых совпадает с именами бинарных модулей.
В проанализированных нами случаях размер файлов был равен 323 байта, например:
|
1 2 3 4 5 |
-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, ошибка может привести к потере данных):
|
1 |
find /etc/init.d/ -type f -size 323c -delete |
На этом все, мы убрали с сервера вредонос Unix.Trojan.DDoS_XOR-1 (Linux/Xorddos). Проверяем список процессов с помощью команд ps, lsof — не должно быть подозрительной активности.
Не лишним будет также проверить систему с помощью clamav. Установим антивирус — для Centos нужно выполнить yum install clamav, для Debian/Ubuntu — apt-get install clamav. Затем запустим сканирование —
|
1 |
clamscan -r -i / |
В процессе сканирования могут быть ошибки, однако следует обратить внимание на показательно Infected Files. Если он более нуля, нужно найти и удалить вредоносные бинарные файлы.
Как защититься от подобных ситуаций? Обновляйте ваше программное обеспечение, ограничьте доступ к панели и служебным приложениям (FTP, webmail, административные панели CMS) — доступ должен быть только с доверенных IP. Если работаете с разных мест, разных провайдеров — используйте VPN для работы. И, конечно, делайте резервные копии.