Калегі, хто выкарыстоўвае на сваіх паштовых серверах 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 і XNUMX/XNUMX не закрануты, калі толькі кастамныя варыянты на іх не ставілі. Больш падрабязна .
Цяпер апісаная там праблема актыўна эксплуатуецца (ботам, трэба меркаваць), заўважыў у сябе на некаторых серверах (якія бегалі на 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: Ад важная нататка для «якія лечаць уручную»:
(пасля прымянення таго ці іншага метаду барацьбы з гэтым зловредом)
перазагружацца абавязкова трэба - малвар сядзіць дзесьці ў адкрытых працэсах і, адпаведна, у памяці, і запісвае сябе па новай у крон кожныя секунд 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