Коллеги, кто использует на своих почтовых серверах Exim версий 4.87…4.91 — срочно обновляйтесь до версии 4.92, предварительно остановив сам Exim во избежание взлома через CVE-2019-10149.
Потенциально уязвимы несколько миллионов серверов по всему миру, уязвимость оценивается как критическая (CVSS 3.0 base score = 9.8/10). Злоумышленники могут запускать на Вашем сервере произвольные команды, во многих случаях от рута.
Пожалуйста, убедитесь что Вы используете исправленную версию (4.92) либо уже пропатченную.
Либо пропатчите существующую, см. ветку .
Обновление для centos 6: см. — для centos 7 оно тоже работает, если из epel напрямую еще не прилетело.
UPD: Убунту затронуты 18.04 и 18.10, обновление для них выпущено. Версии 16.04 и 19.04 не затронуты, если только кастомные варианты на них не ставили. Подробнее .
Сейчас описанная там проблема активно эксплуатируется (ботом, надо полагать), заметил у себя на некоторых серверах (бегавших на 4.91) заражение.
Далее читать актуально только для тех, кто уже «попал» — надо или перевозить всё на чистую VPS со свежим софтом, или искать решение. Попробуем? Пишите, если кто-то сможет побороть малварь эту.
Если Вы, являясь пользователем Exim и читая это, всё ещё не обновились (не убедились в наличии 4.92 или пропатченной версии), пожалуйста остановитесь и бегите обновляться.
Для уже попавших — продолжим…
UPD: и даёт правильный совет:
Зловредов может быть великое множество. Запустив лекарство не от того и почистив очередь пользователь и не вылечится и возможно не узнает от чего ему лечиться нужно.
Заражение заметно так: [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: что малварь поменяла пароли в WordPress.
UPD 6: , тестируем! После перезагрузки или отключения лекарства вроде как слетает, но пока хоть так.
Кто сделает (или найдёт) стабильное решение, пожалуйста пишите, многим поможете.
UPD 7: пишет:
Если еще не сказали то вирус воскрешается благодаря неотправленному письму в exim, при повторной попытке отправить письмо он восстанавливается, гляньте в /var/spool/exim4
Очистить всю очередь exim можно так:
exipick -i | xargs exim -Mrm
Проверка количества записей в очереди:
exim -bpc
UPD 8: Снова : FirstVDS предложили свою версию скрипта для лечения, давайте тестировать!
UPD 9: Похоже что работает, спасибо за скрипт!
Главное не забудьте что сервер уже был скомпрометирован и злоумышленники могли успеть ещё каких-то нетиповых гадостей (не прописанных в дроппере) подсадить.
Поэтому лучше переехать на начисто установленный сервер (vds), или хотя бы продолжить отслеживать тему — если что-то будет новое, пишите в комменты здесь, т.к. явно не все будут переезжать на свежую установку…
UPD 10: Ещё раз спасибо : он напоминает что заражаются не только серверы, но например и Raspberry Pi, и виртуалки всякие… Так что после спасения серверов не забудьте спасти свои видеоприставки, роботов и тд.
UPD 11: От важное примечание для «лечащих вручную»:
(после применения того или иного метода борьбы с этим зловредом)
перезагружаться обязательно надо — малварь сидит где-то в открытых процессах и, соответственно, в памяти, и записывает себя по новой в крон каждые секунд 30
UPD 12: у себя в очереди exim другой(?) зловред и советует сначала изучить конкретно свою проблему, до начала лечения.
UPD 13: скорее переезжать на чистую систему, и файлы переносить крайне осторожно, т.к. малварь уже в публичном доступе и её использовать могут другими, менее очевидными и более опасными способами.
UPD 14: успокаивающих себя тем что как люди умные от рута не запускают — ещё одно :
Даже если работает не из под рута происходит взлом… У меня на OrangePi стоит debian jessie UPD: stretch, exim запущен от Debian-exim и все равно случился взлом, потерло крон и прочее.
UPD 15: при переезде на чистый сервер со скомпрометированного не забывайте про гигиену, :
При переносе данных обратите внимание не только на исполняемые или конфигурационные файлы, но и всё что может содержать вредоносные команды (например, в MySQL это может быть CREATE TRIGGER или CREATE EVENT). Также, не забывайте о .html, .js, .php, .py и других публичных файлах (в идеале эти файлы, как и другие данные, должны быть восстановлены из локального или другого доверенного хранилища).
UPD 16: и : в системе в портах стояла одна версия exim, а на деле выполнялась другая.
Так что всем после обновления стоит убедиться что используете именно новую версию!
exim --versionКонкретно с их ситуацией мы сообща разобрались.
На сервере использовался DirectAdmin и стоял его старый пакет da_exim (старой версии, без уязвимости).
При этом с помощью DirectAdmin’овского менеджера пакетов custombuild по факту потом была установлена более новая версия exim, уже уязвимая.
Конкретно в этой ситуации помогло также обновление через custombuild.
Не забывайте делать бэкапы до таких экспериментов, а также убедитесь что до/после обновления все процессы exim старой версии и не «застряли» в памяти.
Источник: habr.com