Срочно обновляйте exim до 4.92 — идёт активное заражение

Коллеги, кто использует на своих почтовых серверах Exim версий 4.87…4.91 — срочно обновляйтесь до версии 4.92, предварительно остановив сам Exim во избежание взлома через CVE-2019-10149.

Потенциально уязвимы несколько миллионов серверов по всему миру, уязвимость оценивается как критическая (CVSS 3.0 base score = 9.8/10). Злоумышленники могут запускать на Вашем сервере произвольные команды, во многих случаях от рута.

Пожалуйста, убедитесь что Вы используете исправленную версию (4.92) либо уже пропатченную.
Либо пропатчите существующую, см. ветку комментария immaculate.

Обновление для centos 6: см. комментарий Theodor — для centos 7 оно тоже работает, если из epel напрямую еще не прилетело.

UPD: Убунту затронуты 18.04 и 18.10, обновление для них выпущено. Версии 16.04 и 19.04 не затронуты, если только кастомные варианты на них не ставили. Подробнее на их официальном сайте.

Информация о проблеме на Opennet
Информация на сайте Exim

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

Далее читать актуально только для тех, кто уже «попал» — надо или перевозить всё на чистую VPS со свежим софтом, или искать решение. Попробуем? Пишите, если кто-то сможет побороть малварь эту.

Если Вы, являясь пользователем Exim и читая это, всё ещё не обновились (не убедились в наличии 4.92 или пропатченной версии), пожалуйста остановитесь и бегите обновляться.

Для уже попавших — продолжим…

UPD: supersmile2009 нашел у себя другую разновидность зловреда и даёт правильный совет:

Зловредов может быть великое множество. Запустив лекарство не от того и почистив очередь пользователь и не вылечится и возможно не узнает от чего ему лечиться нужно.

Заражение заметно так: [kthrotlds] грузит процессор; на слабой VDS на 100%, на серваках слабее но заметно.

После заражения зловред удаляет записи в крон, прописывая там только себя в запуском каждые 4 минуты, при этом файл кронтаба делает immutable. Crontab -e не может сохранить изменения, выдаёт ошибку.

Immutable можно снять например так, после чего удалить строку команды (1.5кб):

chattr -i /var/spool/cron/root
crontab -e

Далее там в редакторе crontab (vim) удаляем строку и сохраняем:dd
:wq

Однако какой-то из активных процессов перезаписывает снова, разбираюсь.

При этом висит куча активных wget’ов (либо curl’ов) на адреса из скрипта инсталлятора (см. ниже), я их пока сбиваю так, но они снова запускаются:

ps aux | grep wge[t]
ps aux | grep cur[l]
echo "Stopping..."
kill -9 `ps aux | grep wge[t] | awk '{print $2}'`
kill -9 `ps aux | grep cur[l] | awk '{print $2}'`

Скрипт инсталлятора трояна нашел тут (centos): /usr/local/bin/nptd… не выкладываю во избежание, но если кто заражен и разбирается в shell скриптах, пожалуйста изучите внимательнее.

Дополню по мере обновления информации.

UPD 1: Снос файлов (с предварительным chattr -i) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root не помог, равно как и остановка службы — пришлось кронтаб пока полностью выдрать (bin-файл переименовать).

UPD 2: Инсталлятор трояна иногда валялся также в других местах, помог поиск по размеру:
find / -size 19825c

UPD 3: Внимание! Помимо отключения selinux троян также добавляет свой SSH-ключ в ${sshdir}/authorized_keys! И активирует следующие поля в /etc/ssh/sshd_config, если они ещё не были прописаны как YES:
PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes
echo UsePAM yes
PasswordAuthentication yes

UPD 4: Резюмируя на данный момент: отключаем exim, cron (с корнями), срочно убираем троянов ключ из ssh и правим конфиг sshd, перезапускаем sshd! И то пока не точно что это поможет, но без этого вообще беда.

Важную информацию из комментариев про патчи/апдейты вынес в начало заметки, чтобы читающие с неё начинали.

UPD 5: AnotherDenni пишет что малварь поменяла пароли в WordPress.

UPD 6: Paulmann подготовил временное лекарство, тестируем! После перезагрузки или отключения лекарства вроде как слетает, но пока хоть так.

Кто сделает (или найдёт) стабильное решение, пожалуйста пишите, многим поможете.

UPD 7: Пользователь clsv пишет:

Если еще не сказали то вирус воскрешается благодаря неотправленному письму в exim, при повторной попытке отправить письмо он восстанавливается, гляньте в /var/spool/exim4

Очистить всю очередь exim можно так:
exipick -i | xargs exim -Mrm
Проверка количества записей в очереди:
exim -bpc

UPD 8: Снова спасибо за информацию AnotherDenni: FirstVDS предложили свою версию скрипта для лечения, давайте тестировать!

UPD 9: Похоже что работает, спасибо Кириллу за скрипт!

Главное не забудьте что сервер уже был скомпрометирован и злоумышленники могли успеть ещё каких-то нетиповых гадостей (не прописанных в дроппере) подсадить.

Поэтому лучше переехать на начисто установленный сервер (vds), или хотя бы продолжить отслеживать тему — если что-то будет новое, пишите в комменты здесь, т.к. явно не все будут переезжать на свежую установку…

UPD 10: Ещё раз спасибо clsv: он напоминает что заражаются не только серверы, но например и Raspberry Pi, и виртуалки всякие… Так что после спасения серверов не забудьте спасти свои видеоприставки, роботов и тд.

UPD 11: От автора целебного скрипта важное примечание для «лечащих вручную»:
(после применения того или иного метода борьбы с этим зловредом)

перезагружаться обязательно надо — малварь сидит где-то в открытых процессах и, соответственно, в памяти, и записывает себя по новой в крон каждые секунд 30

UPD 12: supersmile2009 нашел у себя в очереди exim другой(?) зловред и советует сначала изучить конкретно свою проблему, до начала лечения.

UPD 13: lorc советует скорее переезжать на чистую систему, и файлы переносить крайне осторожно, т.к. малварь уже в публичном доступе и её использовать могут другими, менее очевидными и более опасными способами.

UPD 14: успокаивающих себя тем что как люди умные от рута не запускают — ещё одно срочное сообщение от clsv:

Даже если работает не из под рута происходит взлом… У меня на OrangePi стоит debian jessie UPD: stretch, exim запущен от Debian-exim и все равно случился взлом, потерло крон и прочее.

UPD 15: при переезде на чистый сервер со скомпрометированного не забывайте про гигиену, полезное напоминание от w0den:

При переносе данных обратите внимание не только на исполняемые или конфигурационные файлы, но и всё что может содержать вредоносные команды (например, в MySQL это может быть CREATE TRIGGER или CREATE EVENT). Также, не забывайте о .html, .js, .php, .py и других публичных файлах (в идеале эти файлы, как и другие данные, должны быть восстановлены из локального или другого доверенного хранилища).

UPD 16: daykkin и savage_me столкнулись с другой проблемой: в системе в портах стояла одна версия exim, а на деле выполнялась другая.

Так что всем после обновления стоит убедиться что используете именно новую версию!

exim --version

Конкретно с их ситуацией мы сообща разобрались.

На сервере использовался DirectAdmin и стоял его старый пакет da_exim (старой версии, без уязвимости).

При этом с помощью DirectAdmin’овского менеджера пакетов custombuild по факту потом была установлена более новая версия exim, уже уязвимая.

Конкретно в этой ситуации помогло также обновление через custombuild.

Не забывайте делать бэкапы до таких экспериментов, а также убедитесь что до/после обновления все процессы exim старой версии были остановлены и не «застряли» в памяти.

Источник: habr.com