Актуализирайте спешно Exim до 4.92 - има активна инфекция

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

Няколко милиона сървъра по света са потенциално уязвими, уязвимостта е оценена като критична (основен резултат CVSS 3.0 = 9.8/10). Нападателите могат да изпълняват произволни команди на вашия сървър, в много случаи от root.

Моля, уверете се, че използвате фиксирана версия (4.92) или такава, която вече е коригирана.
Или закърпете съществуващия, вижте темата безупречен коментар.

Актуализация за CentOS 6: см. коментар на Теодор — за centos 7 също работи, ако все още не е пристигнал директно от epel.

UPD: Ubuntu е засегнат 18.04 и 18.10, е пусната актуализация за тях. Версии 16.04 и 19.04 не са засегнати, освен ако на тях не са инсталирани персонализирани опции. Повече информация на официалния им уебсайт.

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

Сега описаният там проблем се използва активно (предполага се от бот), забелязах инфекция на някои сървъри (работещи на 4.91).

Допълнителното четене е от значение само за тези, които вече са го „разбрали“ - трябва или да пренесете всичко на чист VPS с нов софтуер, или да потърсите решение. да пробваме ли Пишете дали някой може да преодолее този зловреден софтуер.

Ако вие, като потребител на Exim и четете това, все още не сте актуализирали (не сте се уверили, че 4.92 или версия с корекция е налична), моля, спрете и стартирайте, за да актуализирате.

За тези, които вече са стигнали до там, нека продължим...

UPS: supersmile2009 откри друг тип зловреден софтуер и дава правилния съвет:

Може да има голямо разнообразие от зловреден софтуер. Чрез пускане на лекарството за грешното нещо и изчистване на опашката, потребителят няма да бъде излекуван и може да не знае от какво трябва да се лекува.

Инфекцията се забелязва по следния начин: [kthrotlds] натоварва процесора; на слаб VDS е 100%, на сървъри е по-слаб, но се забелязва.

След заразяването злонамереният софтуер изтрива cron записи, като се регистрира само себе си там, за да се изпълнява на всеки 4 минути, като същевременно прави файла crontab неизменен. Кронтаб -е не може да запази промените, дава грешка.

Неизменният може да бъде премахнат, например, по този начин и след това да изтриете командния ред (1.5kb):

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

След това в редактора на crontab (vim) изтрийте реда и запазете:dd
:wq

Въпреки това, някои от активните процеси отново се презаписват, разбрах го.

В същото време има куп активни wgets (или къдрици), висящи на адресите от инсталационния скрипт (вижте по-долу), засега ги събарям така, но те започват отново:

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... Не го публикувам, за да го избегна, но ако някой е заразен и разбира шел скриптове, моля, проучете го по-внимателно.

Ще добавя, когато информацията се актуализира.

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

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

UPD 3 г.: Внимание! В допълнение към деактивирането на selinux, троянският кон добавя и своя собствена SSH ключ в ${sshdir}/authorized_keys! И активира следните полета в /etc/ssh/sshd_config, ако вече не са зададени на YES:
PermitRootLogin да
RSAAудостоверяване да
PubkeyAuthentication да
echo UsePAM да
PasswordAuthentication да

UPD 4: За да обобщим засега: деактивирайте Exim, cron (с корени), спешно премахнете троянския ключ от ssh и редактирайте sshd конфигурацията, рестартирайте sshd! И все още не е ясно дали това ще помогне, но без него има проблем.

Преместих важна информация от коментарите за корекции/актуализации в началото на бележката, така че читателите да започнат с нея.

UPD 5 г.: Друг Дени пише че зловредният софтуер е променил паролите в WordPress.

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

Който направи (или намери) стабилно решение, моля да пише, ще помогнете на мнозина.

UPD 7 г.: Потребител clsv пише:

Ако още не сте казали, че вирусът е възкресен благодарение на неизпратено писмо в Exim, когато се опитате да изпратите писмото отново, то се възстановява, погледнете в /var/spool/exim4

Можете да изчистите цялата опашка на Exim по следния начин:
exipick -i | xargs exim -Mrm
Проверка на броя на записите в опашката:
exim -bpc

UPD 8: Отново благодаря за информацията AnotherDenny: FirstVDS предложи своя версия на скрипта за лечение, нека го тестваме!

UPD 9: Изглежда работи, Благодаря Кирил за сценария!

Основното нещо е да не забравяме, че сървърът вече е компрометиран и нападателите можеха да успеят да подложат някои по-нетипични неприятни неща (които не са изброени в dropper).

Затова е по-добре да преминете към напълно инсталиран сървър (vds) или поне да продължите да следите темата - ако има нещо ново, пишете в коментарите тук, т.к. явно не всеки ще мине на нова инсталация...

UPD 10: Благодаря отново clsv: напомня, че не само сървърите са заразени, но и Raspberry Pi, и всякакви виртуални машини... Така че след като запазите сървърите, не забравяйте да запазите вашите видео конзоли, роботи и т.н.

UPD 11: От автор на лечебния сценарий Важна забележка за ръчните лечители:
(след използване на един или друг метод за борба с този зловреден софтуер)

Определено трябва да рестартирате - зловредният софтуер седи някъде в отворени процеси и съответно в паметта и си пише нов за cron на всеки 30 секунди

UPD 12 г.: supersmile2009 намерен Exim има друг (?) злонамерен софтуер в своята опашка и ви съветва първо да проучите специфичния си проблем, преди да започнете лечение.

UPD 13 г.: lorc съветва по-скоро преминете към чиста система и прехвърляйте файлове изключително внимателно, защото Зловреден софтуер вече е публично достъпен и може да се използва по други, по-малко очевидни и по-опасни начини.

UPD 14: да се уверим, че умните хора не бягат от root - още нещо спешно съобщение от clsv:

Дори и да не работи от root, възниква хакване... Имам debian jessie UPD: stretch на моя OrangePi, 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 (стара версия, без уязвимост).

В същото време, с помощта на мениджъра на пакети custombuild на DirectAdmin, всъщност беше инсталирана по-нова версия на Exim, която вече беше уязвима.

В тази конкретна ситуация актуализацията чрез custombuild също помогна.

Не забравяйте да направите резервни копия преди такива експерименти и също така се уверете, че преди/след актуализацията всички процеси на Exim са от старата версия бяха спрени а не „заседнали“ в паметта.

Източник: www.habr.com