Kolegovia, ktorí na svojich poštových serveroch používajú Exim verzie 4.87...4.91 – urýchlene aktualizujte na verziu 4.92, pretože predtým zastavili samotný Exim, aby sa vyhli hackovaniu cez CVE-2019-10149.
Niekoľko miliónov serverov na celom svete je potenciálne zraniteľných, zraniteľnosť je hodnotená ako kritická (základné skóre CVSS 3.0 = 9.8/10). Útočníci môžu na vašom serveri spúšťať ľubovoľné príkazy, v mnohých prípadoch z root.
Uistite sa, že používate pevnú verziu (4.92) alebo verziu, ktorá už bola opravená.
Alebo opravte existujúcu, viď vlákno .
Aktualizácia pre centov 6: cm. — pre centos 7 to tiež funguje, ak ešte neprišiel priamo z epelu.
UPD: Ubuntu je ovplyvnené 18.04 a 18.10, bola pre ne vydaná aktualizácia. Verzie 16.04 a 19.04 nie sú ovplyvnené, pokiaľ na ne neboli nainštalované vlastné voľby. Viac informácií .
Teraz je tu popísaný problém aktívne využívaný (pravdepodobne botom), všimol som si infekciu na niektorých serveroch (bežiacich na 4.91).
Ďalšie čítanie je relevantné iba pre tých, ktorí to už „dostali“ - musíte buď všetko preniesť do čistého VPS s čerstvým softvérom, alebo hľadať riešenie. Skúsime? Napíšte, či niekto dokáže prekonať tento malvér.
Ak ste používateľom Exim a čítate toto, stále ste neaktualizovali (neuistili ste sa, že je k dispozícii verzia 4.92 alebo opravená verzia), zastavte sa a spustite aktualizáciu.
Pre tých, ktorí sa tam už dostali, pokračujme...
UPS: a dáva správnu radu:
Môže existovať veľké množstvo škodlivého softvéru. Spustením lieku na nesprávnu vec a vyčistením frontu sa používateľ nevylieči a nemusí vedieť, na čo sa musí liečiť.
Infekcia je zrejmá takto: [kthrotlds] načíta procesor; na slabom VDS je to 100%, na serveroch je to slabsie ale citelne.
Po infekcii malvér vymaže záznamy cron, zaregistruje sa tam iba sám, aby sa spustil každé 4 minúty, pričom súbor crontab urobí nemenným. Crontab -e nemôže uložiť zmeny, zobrazí chybu.
Immutable je možné odstrániť napríklad takto a potom vymazať príkazový riadok (1.5 kb):
chattr -i /var/spool/cron/root
crontab -e
Ďalej v editore crontab (vim) odstráňte riadok a uložte:dd
:wq
Niektoré aktívne procesy sa však opäť prepisujú, prichádzam na to.
Zároveň na adresách z inštalačného skriptu (pozri nižšie) visí veľa aktívnych wgetov (alebo kučier), zatiaľ ich takto zrážam, ale začínajú znova:
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}'`
Inštalačný skript pre trójske kone som našiel tu (centos): /usr/local/bin/nptd... Neuverejňujem ho, aby som sa mu vyhol, ale ak je niekto infikovaný a rozumie skriptom shellu, pozornejšie si ho preštudujte.
Doplním podľa aktualizácie informácií.
UPD 1: Odstránenie súborov (s predbežným chattr -i) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root nepomohlo ani zastavenie služby - musel som crontab ho zatiaľ úplne vytrhnite (premenujte súbor bin).
UPD 2: Inštalátor trójskeho koňa sa niekedy povaľoval aj na iných miestach, vyhľadávanie podľa veľkosti pomohlo:
nájsť / -veľkosť 19825c
UPD 3: Varovanie! Okrem deaktivácie selinuxu pridáva aj trójsky kôň svoj vlastný SSH kľúč v ${sshdir}/authorized_keys! A aktivuje nasledujúce polia v /etc/ssh/sshd_config, ak ešte neboli nastavené na ÁNO:
PermitRootLogin áno
RSAA autentifikácia áno
PubkeyAuthentication áno
echo UsePAM áno
Overenie hesla áno
UPD 4: Ak to teraz zhrnieme: vypnite Exim, cron (s koreňmi), urýchlene odstráňte kľúč Trojan z ssh a upravte konfiguráciu sshd, reštartujte sshd! A ešte nie je jasné, že to pomôže, ale bez toho je problém.
Dôležité informácie z komentárov o záplatách/aktualizáciách som presunul na začiatok poznámky, aby s nimi čitatelia začali.
UPD 5: že malvér zmenil heslá vo WordPresse.
UPD 6: , poďme testovať! Po reštarte alebo vypnutí sa zdá, že liek zmizne, ale zatiaľ je to aspoň tak.
Kto vyrobí (alebo nájde) stabilné riešenie, prosím napíšte, mnohým pomôžete.
UPD 7: píše:
Ak ste ešte nepovedali, že vírus je vzkriesený vďaka neodoslanému listu v Exime, pri opätovnom pokuse o odoslanie listu sa obnoví, pozrite sa do /var/spool/exim4
Celý front Exim môžete vymazať takto:
exipick -i | xargs exim -Mrm
Kontrola počtu záznamov vo fronte:
exim -bpc
UPD 8: Opäť : FirstVDS ponúkla svoju verziu liečebného scenára, poďme to otestovať!
UPD 9: Vyzerá to tak práce, Vďaka za scenár!
Hlavná vec je nezabudnúť, že server už bol kompromitovaný a útočníkom sa mohlo podariť nasadiť nejaké netypické škaredé veci (neuvedené v dropperi).
Preto je lepšie prejsť na úplne nainštalovaný server (vds), alebo aspoň pokračovať v sledovaní témy - ak je niečo nové, napíšte sem do komentárov, pretože očividne nie každý prejde na novú inštaláciu...
UPD 10: Ešte raz ďakujem : pripomína, že infikované sú nielen servery, ale aj Raspberry Pi, a všetky druhy virtuálnych strojov... Takže po uložení serverov si nezabudnite uložiť svoje video konzoly, roboty atď.
UPD 11: Od Dôležitá poznámka pre manuálnych liečiteľov:
(po použití jednej alebo druhej metódy boja proti tomuto škodlivému softvéru)
Určite musíte reštartovať - malvér sedí niekde v otvorených procesoch, a teda v pamäti, a každých 30 sekúnd zapisuje nový do cronu
UPD 12: Exim má vo svojom rade ďalší (?) malvér a odporúča vám, aby ste si pred začatím liečby najprv preštudovali váš konkrétny problém.
UPD 13: radšej prejdite na čistý systém a prenášajte súbory mimoriadne opatrne, pretože Malvér je už verejne dostupný a dá sa použiť aj inými, menej zrejmými a nebezpečnejšími spôsobmi.
UPD 14: uisťujeme sa, že inteligentní ľudia neutekajú od koreňa – ešte jedna vec :
Aj keď to nefunguje z root, hackovanie sa vyskytuje... Mám debian jessie UPD: natiahnite si OrangePi, Exim beží z Debian-exim a stále sa hackuje, stratil som koruny atď.
UPD 15: pri prechode na čistý server z napadnutého servera nezabúdajte na hygienu, :
Pri prenose údajov dávajte pozor nielen na spustiteľné alebo konfiguračné súbory, ale aj na čokoľvek, čo môže obsahovať škodlivé príkazy (napríklad v MySQL to môže byť CREATE TRIGGER alebo CREATE EVENT). Nezabudnite tiež na súbory .html, .js, .php, .py a iné verejné súbory (ideálne by tieto súbory, podobne ako iné údaje, mali byť obnovené z lokálneho alebo iného dôveryhodného úložiska).
UPD 16: и : systém mal v portoch nainštalovanú jednu verziu Eximu, no v skutočnosti na ňom bežala iná.
Takže všetci po aktualizácii by ste sa mali uistiť že používate novú verziu!
exim --versionSpoločne sme riešili ich konkrétnu situáciu.
Server používal DirectAdmin a jeho starý balík da_exim (stará verzia, bez zraniteľnosti).
Zároveň s pomocou správcu balíkov custombuild DirectAdmin sa v skutočnosti potom nainštalovala novšia verzia Exim, ktorá už bola zraniteľná.
V tejto konkrétnej situácii pomohla aj aktualizácia cez custombuild.
Nezabudnite si pred takýmito experimentmi urobiť zálohy a tiež sa uistite, že pred/po aktualizácii sú všetky procesy Exim starej verzie a nie „uviaznutý“ v pamäti.
Zdroj: hab.com