Колеги, които използват Exim версии 4.87…4.91 на своите пощенски сървъри — спешно обновете до версия 4.92, след като предварително спрете самия Exim, за да избегнете хакерски атаки чрез CVE-2019-10149.
Потенциално уязвими са няколко милиона сървъри по целия свят, уязвимостта е оценена като критична (CVSS 3.0 base score = 9.8/10). Злоумишлениците могат да стартират произволни команди на Вашия сървър, в много случаи с права на root.
Моля, уверете се, че използвате коригираната версия (4.92) или вече пропатчена.
Или пропатчете съществуващата, вижте темата .
Актуализация за centos 6: вижте. — за centos 7 също работи, ако не е дошло директно от epel.
UPD: Ubuntu са засегнати 18.04 и 18.10, актуализация за тях е издадена. Версии 16.04 и 19.04 не са засегнати, освен ако не са инсталирани персонализирани варианти. Повече информация .
Сега описаната там проблема активно се експлоатира (от бот, предполагам), забелязах я на някои сървъри при мен (работещи на 4.91) като инфекция.
По-нататък четенето е актуално само за тези, които вече са "попаднали" — трябва или да прехвърлят всичко на чиста VPS със свеж софтуер, или да търсят решение. Да опитаме? Пишете, ако някой може да се справи с тази зловредна програма.
Ако сте потребител на Exim и четете това, и все още не сте обновили (не сте се уверили, че имате версия 4.92 или пропатчена версия), моля, спрете и бягайте да се обновите.
За вече попадналите — ще продължим...
UPD: и дава правилен съвет:
Зловредите могат да бъдат безброй. Стартирайки лекарство, което не е предназначено за конкретно, потребителят не само че няма да се излекува, но и може да не разбере от какво трябва да се лекува.
Инфекцията се забелязва по следния начин: [kthrotlds] натоварва процесора; на слаб VDS на 100%, на сървъри с по-слаби ресурси, но все пак забележимо.
След инфекцията зловредът изтрива записи в cron, оставяйки само себе си за стартиране на всеки 4 минути, като прави файла на crontab неизменяем. Crontab -e не може да запази промените, дава грешка.
Неизменяемостта може да се премахне например така, след което да изтриете реда с командата (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 "Спирам..."
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 не помогна, както и спирането на услугата — трябваше напълно да премахна crontab (да преименувам 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
