Kolegové, kteří na svých poštovních serverech používají Exim verze 4.87...4.91 – urychleně aktualizujte na verzi 4.92, protože předtím zastavili samotný Exim, aby se vyhnuli hackování prostřednictvím CVE-2019-10149.
Několik milionů serverů po celém světě je potenciálně zranitelných, zranitelnost je hodnocena jako kritická (základní skóre CVSS 3.0 = 9.8/10). Útočníci mohou na vašem serveru spouštět libovolné příkazy, v mnoha případech z rootu.
Ujistěte se prosím, že používáte pevnou verzi (4.92) nebo verzi, která již byla opravena.
Nebo opravte stávající, viz vlákno .
Aktualizace pro CentOS 6: cm. — pro centos 7 to také funguje, pokud ještě nedorazilo přímo z epelu.
UPD: Ubuntu je ovlivněno 18.04 a 18.10, byla pro ně vydána aktualizace. Verze 16.04 a 19.04 nejsou ovlivněny, pokud na ně nebyly nainstalovány vlastní volby. Více informací .
Nyní je zde popsaný problém aktivně využíván (pravděpodobně botem), zaznamenal jsem infekci na některých serverech (běžících na 4.91).
Další čtení je relevantní pouze pro ty, kteří to již „dostali“ - musíte buď vše přenést do čistého VPS s čerstvým softwarem, nebo hledat řešení. Zkusíme to? Napište, jestli někdo dokáže překonat tento malware.
Pokud jste uživatelem Eximu a čtete tento text, stále jste neaktualizovali (nezajistili jste, že je k dispozici verze 4.92 nebo opravená verze), zastavte se a spusťte aktualizaci.
Pro ty, kteří se tam již dostali, pokračujme...
UPD: a dává správnou radu:
Malware může být celá řada. Spuštěním léku na špatnou věc a vyklizením fronty se uživatel nevyléčí a nemusí vědět, co potřebuje léčit.
Infekce je patrná takto: [kthrotlds] zatěžuje procesor; na slabém VDS je 100%, na serverech je slabší, ale znatelný.
Po infekci malware smaže záznamy cron a zaregistruje se tam pouze pro spuštění každé 4 minuty, přičemž soubor crontab bude neměnný. Crontab -e nelze uložit změny, zobrazí chybu.
Immutable lze odstranit například takto a poté smazat příkazový řádek (1.5 kb):
chattr -i /var/spool/cron/root
crontab -e
Dále v editoru crontab (vim) odstraňte řádek a uložte:dd
:wq
Některé aktivní procesy se však znovu přepisují, zjišťuji to.
Zároveň na adresách z instalačního skriptu (viz níže) visí hromada aktivních wgetů (nebo kudrlinek), zatím je srážím takto, ale začínají znovu:
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 instalačního programu trojského koně jsem našel zde (centos): /usr/local/bin/nptd... Nezveřejňuji jej, abych se mu vyhnul, ale pokud je někdo infikován a rozumí skriptům shellu, prostudujte si jej prosím pečlivěji.
Doplním, jakmile budou informace aktualizovány.
UPD 1: Smazání souborů (s předběžným chattr -i) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root nepomohlo ani zastavení služby - musel jsem crontab ho prozatím úplně vytrhněte (přejmenujte soubor bin).
UPD 2: Instalační program trojského koně se někdy povaloval i na jiných místech, vyhledávání podle velikosti pomohlo:
najít / -velikost 19825c
UPD3: Varování! Kromě deaktivace selinuxu přidává Trojan také svůj vlastní SSH klíč v ${sshdir}/authorized_keys! A aktivuje následující pole v /etc/ssh/sshd_config, pokud již nebyla nastavena na ANO:
PermitRootLogin ano
RSAA autentizace ano
PubkeyAuthentication ano
echo UsePAM ano
PasswordAuthentication ano
UPD 4: Pro tuto chvíli shrnutí: deaktivujte Exim, cron (s kořeny), naléhavě odstraňte trojský klíč z ssh a upravte konfiguraci sshd, restartujte sshd! A ještě není jasné, že to pomůže, ale bez toho je problém.
Důležité informace z komentářů o záplatách/updatech jsem přesunul na začátek poznámky, aby jimi čtenáři začali.
UPD5: že malware změnil hesla ve WordPressu.
UPD6: , pojďme testovat! Po restartu nebo vypnutí se zdá, že lék zmizí, ale prozatím je to tak.
Kdo dělá (nebo najde) stabilní řešení, prosím napište, mnohým pomůžete.
UPD7: píše:
Pokud jste ještě neřekli, že virus je vzkříšen díky neodeslanému dopisu v Eximu, při pokusu o odeslání dopisu znovu je obnoven, podívejte se do /var/spool/exim4
Celou frontu Exim můžete vymazat takto:
exipick -i | xargs exim -Mrm
Kontrola počtu záznamů ve frontě:
exim -bpc
UPD 8: Znovu : FirstVDS nabídl svou verzi léčebného scénáře, pojďme ji otestovat!
UPD 9: Vypadá to práce, dík za scénář!
Hlavní je nezapomenout, že server už byl kompromitován a útočníkům se mohlo podařit zasadit ještě nějaké netypické ošklivé věci (neuvedené v dropperu).
Proto je lepší přejít na kompletně nainstalovaný server (vds), nebo alespoň pokračovat ve sledování tématu - pokud je něco nového, napište sem do komentářů, protože samozřejmě ne každý přejde na novou instalaci...
UPD 10: Ještě jednou díky : připomíná, že jsou infikovány nejen servery, ale také Raspberry Pi, a všemožné virtuální stroje... Takže po uložení serverů nezapomeňte uložit své video konzole, roboty atd.
UPD 11: Od Důležitá poznámka pro manuální léčitele:
(po použití jedné nebo druhé metody boje proti tomuto malwaru)
Rozhodně musíte restartovat - malware sedí někde v otevřených procesech, a tedy v paměti, a každých 30 sekund si zapisuje nový do cronu
UPD12: Exim má ve své frontě další (?) malware a radí, abyste si před zahájením léčby nejprve prostudovali svůj konkrétní problém.
UPD13: spíše přejděte na čistý systém a přenášejte soubory velmi opatrně, protože Malware je již veřejně dostupný a lze jej použít jinými, méně zřejmými a nebezpečnějšími způsoby.
UPD 14: ujišťujeme se, že chytří lidé neutíkají od roota – ještě jedna věc :
I když to nefunguje z rootu, dochází k hackování... Mám debian jessie UPD: natáhněte si můj OrangePi, Exim běží z Debian-exim a stále docházelo k hackování, ztracené koruny atd.
UPD 15: při přechodu na čistý server z kompromitovaného serveru nezapomeňte na hygienu, :
Při přenosu dat dávejte pozor nejen na spustitelné nebo konfigurační soubory, ale také na cokoli, co může obsahovat škodlivé příkazy (například v MySQL to může být CREATE TRIGGER nebo CREATE EVENT). Nezapomeňte také na soubory .html, .js, .php, .py a další veřejné soubory (ideálně by tyto soubory, stejně jako ostatní data, měly být obnoveny z místního nebo jiného důvěryhodného úložiště).
UPD16: и : systém měl v portech nainstalovanou jednu verzi Exim, ale ve skutečnosti na něm běžela jiná.
Takže všichni po aktualizaci byste se měli ujistit že používáte novou verzi!
exim --versionSpolečně jsme řešili jejich konkrétní situaci.
Server používal DirectAdmin a jeho starý balíček da_exim (stará verze, bez chyby zabezpečení).
Ve stejné době, s pomocí správce balíčků custombuild DirectAdmin, ve skutečnosti byla poté nainstalována novější verze Eximu, která již byla zranitelná.
V této konkrétní situaci pomohla i aktualizace přes custombuild.
Před takovými experimenty nezapomeňte provést zálohy a také se ujistěte, že před/po aktualizaci jsou všechny procesy Exim staré verze a ne „uvízl“ v paměti.
Zdroj: www.habr.com