Kolegové, kdo používá na svých poštovních serverech Exim verzí 4.87…4.91 — okamžitě aktualizujte na verzi 4.92, přičemž nejprve zastavte samotný Exim, abyste se vyhnuli hacknutí skrze CVE-2019-10149.
Potenciálně je ohroženo několik milionů serverů po celém světě, zranitelnost je hodnocena jako kritická (CVSS 3.0 základní skóre = 9.8/10). Útočníci mohou spouštět na vašem serveru libovolné příkazy, v mnoha případech jako root.
Prosím, ujistěte se, že používáte opravenou verzi (4.92) nebo již opravenou.
Nebo opravte stávající, viz vlákno .
Aktualizace pro centos 6: viz — pro centos 7 to také funguje, pokud to ještě nepřišlo přímo z epel.
UPD: Ubuntu jsou zasažena 18.04 a 18.10, aktualizace pro ně byla vydána. Verze 16.04 a 19.04 nejsou zasaženy, pokud na nich nebyly instalovány vlastní varianty. Více informací .
V současnosti je popsaná tam problém aktivně zneužívána (botem, dá se předpokládat), všiml jsem si toho na některých serverech (běžících na 4.91) infikovaných.
Pokračovat ve čtení je relevantní pouze pro ty, kdo už »trpí« — buď je třeba přenést vše na čistou VPS s novým softwarem, nebo hledat řešení. Zkusíme to? Napište, pokud někdo dokáže tuto malware překonat.
Pokud jste uživatel Exim a čtete toto, a stále jste se neaktualizovali (neujistili o existenci 4.92 nebo opravené verze), prosím zastavte se a běžte se aktualizovat.
Pro už zasažené — pokračujme…
UPD: a dává správnou radu:
Škodlivých kód může být nespočet. Pokud spustíte lék, který nebyl určen a vyčistíte frontu, uživatel se neuzdraví a možná ani nezjistí, co vlastně by měl léčit.
Infekce se projevuje takto: [kthrotlds] zatěžuje procesor; na slabé VDS na 100 %, na slabších serverech ale znatelně.
Po infekci škodlivý kód odstraňuje zápisy v cron, zapisuje tam pouze sebe s spuštěním každé 4 minuty, přičemž soubor crontabu dělá immutable. Crontab -e nemůže uložit změny, hlásí chybu.
Immutable lze odstranit například takto, poté smazat řádek příkazu (1.5kB):
chattr -i /var/spool/cron/root
crontab -e Dále tam v editoru crontab (vim) odstraníme řádek a uložíme:dd
:wq
Ale zřejmě nějaký z aktivních procesů znovu přepisuje, snažím se to vyřešit.
Přitom visí spousta aktivních wgetů (nebo curlů) na adresy ze skriptu instalátora (viz níže), zatím je takto přerušuju, ale znovu se spouštějí:
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}'`
Skript instalátoru trojského koně se našel zde (centos): \/usr\/local\/bin\/nptd… nepublikuji ho z obavy, ale pokud je někdo nakažen a rozumí shell skriptům, prosím, podívejte se na něj podrobněji.
Doplním, jak budu aktualizovat informace.
UPD 1: Odstranění souborů (s předchozím chattr -i) \/etc\/cron.d\/root, \/etc\/crontab, rm -Rf \/var\/spool\/cron\/root nepomohlo, stejně jako zastavení služby — bylo nutné krontab prozatím kompletně odstranit (binární soubor přejmenovat).
UPD 2: Instalátor trojského koně se občas nacházel i na jiných místech, pomohlo hledání podle velikosti:
find \/ -size 19825c
UPD 3: Pozor! Kromě vypnutí selinux trojan také přidává svůj SSH klíč do ${sshdir}\/authorized_keys! A aktivuje následující položky v \/etc\/ssh\/sshd_config, pokud ještě nebyly uvedeny jako YES:
PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes
echo UsePAM yes
PasswordAuthentication yes
UPD 4: Shrnutí k současnému stavu: vypínáme exim, cron (s rooty), urgentně odstraníme trojský klíč z ssh a upravíme konfiguraci sshd, restartujeme sshd! A i to není jisté, že pomůže, ale bez toho je to skutečná katastrofa.
Důležité informace z komentářů o patchech / aktualizacích jsem vyčlenil na začátek poznámky, aby ti, kdo čtou odtud, začínali.
UPD 5: , že malware změnil hesla ve WordPress.
UPD 6: , testujeme! Po restartu nebo vypnutí opravy se zdá, že to padá, ale zatím alespoň takto.
Kdo vytvoří (nebo najde) stabilní řešení, prosím, pište, mnoha lidem tím pomůžete.
UPD 7: píše:
Pokud ještě neřekli, virus se obnovuje díky neodeslanému e-mailu v eximu, při opakované pokusu o odeslání e-mailu se obnovuje, podívejte se do \/var\/spool\/exim4
Celou frontu exim lze vyčistit takto:
exipick -i | xargs exim -Mrm
Kontrola počtu záznamů ve frontě:
exim -bpc
UPD 8: Znovu : FirstVDS navrhli svou verzi skriptu pro opravu, pojďme to testovat!
UPD 9: Zdá se, že pracuje, děkuji za skript!
Hlavní je nezapomenout, že server již byl kompromitován a útočníci mohli stihnout ještě nějaké atypické škodlivosti (neuvedené v dropperu) vklouznout.
Protože je lepší přejít na čistě nainstalovaný server (vds), nebo alespoň nezapomínat sledovat téma – pokud se objeví něco nového, napište do komentářů zde, protože zřejmě ne všichni budou přecházet na novou instalaci…
UPD 10: Ještě jednou děkuji : připomíná, že ne pouze servery, ale například i Raspberry Pi, a všelijaké virtuálky… Takže po záchraně serverů nezapomeňte zachránit své herní konzole, roboty atd.
UPD 11: Od důležité upozornění pro „ruční léčitele“:
(po použití některé z metod boje s tímto malwarem)
je nutné se povinně restartovat – malware se ukrývá někde v otevřených procesech a tím pádem v paměti, a zaznamenává se znova do cronu každých 30 sekund
UPD 12: u sebe v queue exim jiný(?) malware a doporučuje nejprve prostudovat konkrétně svůj problém, před zahájením léčby.
UPD 13: co nejdříve přejít na čistý systém a soubory přenášet velmi opatrně, protože malware už je veřejně dostupný a může být použit jinými, méně zřejmými a nebezpečnějšími způsoby.
UPD 14: uklidňující se tím, že chytří lidé od roota nespouští – další :
I když to nefunguje pod rootem, může dojít k napadení… Mám na OrangePi debian jessie UPD: stretch, exim běžel od Debian-exim a stejně došlo k napadení, cron a další byly odstraněny.
UPD 15: při přechodu na čistý server z kompromitovaného nezapomínejte na hygienu, :
Při přenosu dat si dejte pozor nejen na spustitelné nebo konfigurační soubory, ale i na vše, co může obsahovat škodlivé příkazy (například v MySQL to může být CREATE TRIGGER nebo CREATE EVENT). Také nezapomeňte na .html, .js, .php, .py a další veřejné soubory (ideálně by tyto soubory, jako i další data, měly být obnoveny z lokálního nebo jiného důvěryhodného úložiště).
UPD 16: a : v systému na portech byla jedna verze exim, ale ve skutečnosti se vykonávala jiná.
Takže všichni po aktualizaci byste se měli ujistit že používáte opravdu novou verzi!
exim --versionS jejich situací jsme se společně vypořádali.
Na serveru byl použit DirectAdmin a byl nainstalován starý balíček da_exim (staré verze, bez zranitelnosti).
Při tom byla pomocí správy balíčků DirectAdmin Custombuild vlastně nainstalována novější verze Eximu, která je již zranitelná.
Konkrétně v této situaci pomohlo také aktualizaci přes Custombuild.
Nezapomínejte zálohovat před takovými experimenty a ujistěte se, že všechny procesy staré verze Eximu byli před/po aktualizaci zastaveny. a nezůstaly v paměti.
Zdroj: habr.com
