Колеги, які використовують на своїх поштових серверах 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 так
RSAAuthentication yes
PubkeyAuthentication так
echo UsePAM 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: Від важлива примітка для тих, хто «лікує вручну»:
(після застосування того чи іншого методу боротьби з цим шкідником)
перезавантажуватися обов'язково треба — мальвар сидить десь у відкритих процесах і, відповідно, в пам'яті, і записує себе по новій у крон кожні секунди.
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