Итно ажурирајте го Exim на 4.92 - има активна инфекција

Колеги кои користат Exim верзии 4.87...4.91 на нивните сервери за пошта - итно ажурирајте ја на верзијата 4.92, откако прво го прекинаа самиот Exim за да избегнат хакирање преку CVE-2019-10149.

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

Проверете дали користите фиксна верзија (4.92) или веќе закрпена.
Или закрпи го постоечкиот, види тема беспрекорен коментар.

Ажурирање за центос 6: цм. коментар на Теодор — за centos 7 исто така работи, ако сè уште не е пристигнат директно од epel.

UPD: Убунту е засегнат 18.04 и 18.10, за нив е објавено ажурирање. Верзиите 16.04 и 19.04 не се засегнати освен ако на нив не се инсталирани сопствени опции. Повеќе детали на нивната официјална веб-страница.

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

Сега проблемот опишан таму активно се експлоатира (најверојатно од бот), забележав инфекција на некои сервери (работи на 4.91).

Понатамошното читање е релевантно само за оние кои веќе го „добија“ - треба или да пренесете сè на чист VPS со свеж софтвер или да барате решение. Да се ​​обидеме? Напиши дали некој може да го надмине овој малициозен софтвер.

Ако вие, како корисник на Exim и го читате ова, сè уште не сте ажурирани (не сте се увериле дека е достапна 4.92 или закрпена верзија), застанете и стартувајте за ажурирање.

За оние кои веќе стигнаа таму, да продолжиме...

UPD: supersmile2009 најде друг вид на малициозен софтвер и го дава вистинскиот совет:

Може да има голема разновидност на малициозен софтвер. Со лансирање на лекот за погрешна работа и чистење на редот, корисникот нема да се излечи и можеби нема да знае од што треба да се лекува.

Инфекцијата е забележлива вака: [kthrotlds] го вчитува процесорот; на слаб VDS е 100%, на сервери е послаб но забележлив.

По инфекцијата, малициозниот софтвер ги брише записите на cron, регистрирајќи се само себеси таму за да се извршува на секои 4 минути, додека ја прави датотеката crontab непроменлива. Кронтаб -е не може да ги зачува промените, дава грешка.

Immutable може да се отстрани, на пример, вака, а потоа да се избрише командната линија (1.5 kb):

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

УПД 3: Предупредување! Покрај оневозможувањето на selinux, тројанецот додава и свој SSH клуч во ${sshdir}/authorized_keys! И ги активира следните полиња во /etc/ssh/sshd_config, доколку тие веќе не се поставени на ДА:
PermitRootLogin да
RSAA автентикација да
Автентикација да
ехо UsePAM да
PasswordAuthentication да

UPD 4: Да резимираме за сега: оневозможи Exim, cron (со корени), итно отстранете го тројанскиот клуч од ssh и уредете ја конфигурацијата sshd, рестартирајте го sshd! И сè уште не е јасно дали ова ќе помогне, но без него има проблем.

Ги префрлив важните информации од коментарите за закрпи/надградби на почетокот на белешката, за читателите да започнат со неа.

УПД 5: Пишува AnotherDenny дека малициозниот софтвер ги сменил лозинките во WordPress.

УПД 6: Полман подготви привремен лек, ајде да тестираме! По рестартирање или исклучување, лекот се чини дека исчезнува, но засега барем тоа е тоа.

Секој што ќе направи (или најде) стабилно решение нека пише, ќе им помогнете на многумина.

УПД 7: Корисник clsv пишува:

Ако веќе не сте кажале дека вирусот воскреснува благодарение на неиспратено писмо во Exim, кога ќе се обидете повторно да го испратите писмото, тоа е вратено, погледнете во /var/spool/exim4

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

UPD 8: Повторно благодарам за информацијата AnotherDenny: FirstVDS ја понуди својата верзија на скриптата за третман, ајде да ја тестираме!

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

Главната работа е да не заборавиме дека серверот веќе бил компромитиран и напаѓачите можеле да успеат да постават некои повеќе нетипични непријатни работи (не наведени во капакот).

Затоа, подобро е да се префрлите на целосно инсталиран сервер (vds), или барем да продолжите да ја следите темата - ако има нешто ново, пишете во коментарите овде, бидејќи очигледно нема сите да се префрлат на нова инсталација...

UPD 10: Ви благодариме повторно clsv: потсетува дека не се заразени само серверите, туку и Малина Пи, и секакви виртуелни машини... Затоа, откако ќе ги зачувате серверите, не заборавајте да ги зачувате вашите видео конзоли, роботи итн.

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

Дефинитивно треба да се рестартирате - малициозен софтвер седи некаде во отворени процеси и, соодветно, во меморијата, и сам запишува нов за кроење на секои 30 секунди

УПД 12: Пронајден е суперсмајл2009 Exim има друг(?) малициозен софтвер во својата редица и ве советува прво да го проучите вашиот специфичен проблем пред да започнете со лекување.

УПД 13: Лорк советува туку префрлете се на чист систем и префрлете ги датотеките исклучително внимателно, бидејќи Малициозен софтвер е веќе јавно достапен и може да се користи на други, помалку очигледни и поопасни начини.

UPD 14: уверување дека паметните луѓе не бегаат од корен - уште една работа итна порака од clsv:

Дури и ако не работи од root, се случува хакирање... Имам debian jessie UPD: растегнете се на мојот OrangePi, Exim работи од Debian-exim и сепак се случи хакирање, изгубени круни итн.

UPD 15: кога се префрлате на чист сервер од компромитиран, не заборавајте за хигиена, корисен потсетник од w0den:

Кога пренесувате податоци, обрнете внимание не само на извршните или конфигурациските датотеки, туку и на сè што може да содржи злонамерни команди (на пример, во MySQL ова може да биде CREATE TRIGGER или CREATE EVENT). Исто така, не заборавајте за .html, .js, .php, .py и други јавни датотеки (идеално овие датотеки, како и другите податоци, треба да се обноват од локално или друго доверливо складирање).

УПД 16: daykkin и savage_me наиде на друг проблем: системот имаше една верзија на Exim инсталирана во пристаништата, но во реалноста друга верзија работеше.

Значи сите по ажурирањето треба да се уверите дека ја користите новата верзија!

exim --version

Заедно ја средивме нивната специфична ситуација.

Серверот користеше DirectAdmin и неговиот стар пакет da_exim (стара верзија, без ранливост).

Во исто време, користејќи го менаџерот на пакети прилагодено на DirectAdmin, всушност, тогаш беше инсталирана понова верзија на Exim, која веќе беше ранлива.

Во оваа конкретна ситуација, ажурирањето преку custombuild исто така помогна.

Не заборавајте да направите резервни копии пред таквите експерименти, а исто така бидете сигурни дека пред/по ажурирањето сите процеси на Exim се од старата верзија беа запрени а не „заглавени“ во меморијата.

Извор: www.habr.com