Колеги, които използват Exim версии 4.87…4.91 на своите пощенски сървъри, моля, актуализирайте незабавно до версия 4.92, след като предварително спрете самия Exim, за да избегнете хакване чрез CVE-2019-10149.
Потенциално уязвими са няколко милиона сървъри по целия свят, уязвимостта е оценена като критична (CVSS 3.0 базова оценка = 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 (стара версия, без уязвимост).
Въпреки това, с помощта на мениджъра за пакети custombuild на DirectAdmin всъщност беше инсталирана по-нова версия на exim, която вече е уязвима.
Конкретно в тази ситуация обновлението чрез custombuild също помогна.
Не забравяйте да правите резервни копия преди такива експерименти, както и да се уверите, че преди/след обновлението всички процеси на старата версия на exim и не са "застряли" в паметта.
Източник: habr.com
