KolegĂ«t, kush pĂ«rdor versionet 4.87âŠ4.91 tĂ« Exim nĂ« serverat e tyre tĂ« postĂ«s elektronike â sigurohuni qĂ« tĂ« pĂ«rditĂ«soni menjĂ«herĂ« nĂ« versionin 4.92, pas ndalimit tĂ« Exim pĂ«r tĂ« shmangur sulmin pĂ«rmes CVE-2019-10149.
Potencialisht disa milion servera në të gjithë botën janë të rrezikuar, duke u vlerësuar si kritik (CVSS 3.0 base score = 9.8/10). Sulmuesit mund të ekzekutojnë komanda të rastësishme në serverin tuaj, shpesh prej administratori.
Ju lutemi sigurohuni që po përdorni versionin e riparuar (4.92) ose tashmë të patchuar.
Ose patchoni versionin ekzistues, shihni degën .
PĂ«rditĂ«simi pĂ«r centos 6: shihni. â pĂ«r centos 7 funksionon gjithashtu, nĂ«se nuk ka ardhur direkt nga epel.
UPD: Ubuntu është prekur 18.04 dhe 18.10, për ato është lëshuar një përditësim. Versionet 16.04 dhe 19.04 nuk janë prekur, nëse nuk janë instaluar versione të personalizuara mbi to. Më shumë detaje .
Aktualisht problemi i përshkruar aty po shfrytëzohet aktivisht (nga një bot, mendoj), e kam vënë re në disa nga serverat e mi (të cilët ishin në 4.91) infektimin.
Vazhdoni tĂ« lexoni vetĂ«m pĂ«r ata qĂ« tashmĂ« janĂ« "prekur" â duhen ose tĂ« zhvendosen nĂ« njĂ« VPS tĂ« pastĂ«r me softin e ri, ose tĂ« kĂ«rkojnĂ« zgjidhje. A do ta provojmĂ«? Shkruani, nĂ«se dikush mund tĂ« luftojĂ« malware-in.
Nëse ju, si përdorues i Exim dhe duke lexuar këtë, akoma nuk jeni përditësuar (nuk keni siguruar versionin 4.92 ose versionin e patchuar), ju lutem ndaloni dhe shkoni të përditësoheni.
PĂ«r ata qĂ« tashmĂ« janĂ« prekur â do tĂ« vazhdojmĂ«...
UPD: dhe jep një këshillë të drejtë:
Ka shumë lloje malware-it. Duke ekzekutuar një mjekim të gabuar dhe duke pastruar radhën, përdoruesi nuk do të shuhet dhe ndoshta nuk do të kuptojë se çfarë duhet të trajtojë.
Infektimi tregohet kështu: [kthrotlds] ngarkon procesorin; në një VDS të dobët deri në 100%, në serverë më të dobët, por ndjeshëm.
Pas infektimit, malware-i fshin regjistrimet në cron, duke shkruar vetëm veten për t'u nisur çdo 4 minuta, ndersa bën skedarin e crontab immutable. Crontab -e nuk mund të ruajë ndryshimet, jep një gabim.
Immutable mund të hiqet për shembull kështu, pas së cilës hiqni linjën e komandës (1.5kb):
chattr -i /var/spool/cron/root
crontab -e Më pas atje në redaktorin e crontab (vim) hiqni linjën dhe ruani:dd
:wq
Megjithatë, ndonjë nga proceset aktive e shkruan përsëri, po e shqyrtoj.
Megjithatë, ka shumë wget'ë (ose curl'ë) aktive në adresat e skenarikit të instaluesit (shih më poshtë), unë i ndërpres kështu, por ato rinisin sërish:
ps aux | grep wge[t]
ps aux | grep cur[l]
echo "Duke ndalur..."
kill -9 `ps aux | grep wge[t] | awk '{print $2}'`
kill -9 `ps aux | grep cur[l] | awk '{print $2}'`
Skripti i instaluesit të trojanit është gjetur këtu (centos): /usr/local/bin/nptd⊠nuk e publikoj për të shmangur, por nëse dikush është infektuar dhe kupton në skriptet e shell, ju lutem hidhni një sy më me kujdes.
Do ta plotësoj ndërsa përditësohet informacioni.
UPD 1: Fshirja e skedarĂ«ve (me chattr -i paraprakisht) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root nuk ndihmoi, as ndalimi i shĂ«rbimit â e kisha tĂ«rhequr krejtĂ«sisht crontab (pĂ«r tĂ« ndryshuar emrin e skedarĂ«ve).
UPD 2: Instaluesi i trojanit ndonjëherë ka qenë në vende të tjera, ndihmoi kërkimi sipas madhësisë:
find / -size 19825c
UPD 3: Kujdes! Përveç çaktivizimit të selinux, trojani gjithashtu shton çelësin e tij SSH në ${sshdir}/authorized_keys! Dhe aktivizon këto fusha në /etc/ssh/sshd_config, nëse ato nuk ishin shkruar më parë si YES:
PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes
echo UsePAM yes
PasswordAuthentication yes
UPD 4: Duke përmbledhur deri tani: çaktivizoni exim, cron (me privilegje administrative), hiqni menjëherë çelësin e trojanit nga ssh dhe rregulloni konfigurimin e sshd, rinitoni sshd! Dhe gjithashtu, deri tani nuk është e sigurt nëse kjo do ndihmojë, por pa këtë është ndihmë më e madhe.
Kam nxjerrë informacionin e rëndësishëm nga komentet mbi patch-et/aktualizimet në fillim të shënimeve, që ata që e lexojnë të nisin nga ajo.
UPD 5: se malware ka ndryshuar fjalëkalimet në WordPress.
UPD 6: , po testojmë! Pas rinizjes ose çaktivizimit të ilaçit, duket se zhduket, por për momentin edhe kështu.
Kush do ta bëjë (ose do ta gjejë) një zgjidhje stabile, ju lutem shkruani, do të ndihmoni shumë.
UPD 7: shkruan:
Nëse nuk e thonë ende, virusi rigjallërohet falë një mesazhi të pa dërguar në exim, gjatë një përpjekje të dytë për të dërguar mesazhin ai rikthehet, shikoni në /var/spool/exim4
Për të pastruar të gjithë radhën e exim mund të bëni kështu:
exipick -i | xargs exim -Mrm
Kontrolloni numrin e regjistrimeve në radhë:
exim -bpc
UPD 8: Sërish : FirstVDS ofruan versionin e tyre të skriptit për trajtim, le të testojmë!
UPD 9: Duket se po punon, faleminderit për skriptin!
E rëndësishme është të mos harroni se serveri tashmë ishte i komprometuar dhe sulmuesit mund të kenë vendosur edhe ndonjë gjë tjetër të çuditshme (jo të përmendur në dropper) për të.
Prandaj, Ă«shtĂ« mĂ« mirĂ« tĂ« kaloni nĂ« njĂ« server tĂ« instaluar nga e para (vds), ose tĂ« paktĂ«n tĂ« vazhdoni tĂ« ndjekni temĂ«n â nĂ«se ka ndonjĂ« lajm tĂ« ri, shkruani nĂ« komentet kĂ«tu, sepse Ă«shtĂ« e qartĂ« se jo tĂ« gjithĂ« do tĂ« kalojnĂ« nĂ« njĂ« instalim tĂ« ri...
UPD 10: Përsëri faleminderit : ai përkujton se infektohen jo vetëm serverat, por për shembull edhe Raspberry Pi, dhe çdo lloj virtualizimi⊠Pra, pas shpëtimit të serverëve mos harroni të shpëtoni konvertuesat tuaj të videove, robotët dhe të tjera.
UPD 11: Nga shënim i rëndësishëm për "shëruesit me dorë":
(pas përdorimit të metodave të ndryshme për të luftuar këtë malware)
pĂ«r t'u rinisur Ă«shtĂ« e domosdoshme â malware qĂ«ndron diku nĂ« proceset e hapura dhe, pĂ«r rrjedhojĂ«, nĂ« memorie, dhe regjistron veten pĂ«rsĂ«ri nĂ« cron çdo 30 sekonda
UPD 12: në radhën e tij exim një malware tjetër(?) dhe rekomandon më parë të studiojë problemin e tij specifik para fillimit të trajtimit.
UPD 13: të kaloni sa më parë në një sistem të pastër, dhe të transferoni skedarët me shumë kujdes, sepse malware është tashmë në dispozicion publik dhe mund të përdoret nga të tjerë, në mënyra më pak të duhura dhe më shumë të rrezikshme.
UPD 14: duke e qetësuar veten se si njerëz të mençur nuk e nisin nga rroot - një tjetër :
Edhe nëse punon jo nga rroot ndodhin thyerje⊠Unë kam në OrangePi Debian Jessie UPD: stretch, exim është nisur nga Debian-exim dhe përsëri ndodhi thyerja, përfundojnë cron dhe të tjera.
UPD 15: kur kaloni në një server të pastër nga një të komprometuar, mos harroni higjenën, :
Kur transferoni të dhëna, kushtojini vëmendje jo vetëm skedarëve të ekzekutueshëm ose të konfiguruar, por gjithashtu gjithçkaje që mund të përmbajë komanda të dëmshme (për shembull, në MySQL kjo mund të jetë CREATE TRIGGER ose CREATE EVENT). Gjithashtu, mos harroni për skedarët .html, .js, .php, .py dhe të tjerë publikë (idealisht këta skedarë, si dhe të dhëna të tjera, duhet të rikuperohen nga një ruajtje lokale ose të besueshme).
UPD 16: dhe : në sistem kishte një version të një eksimi në porte, por në të vërtetë ekzekutohej një tjetër.
Pra, të gjithë pas përditësimit duhet të siguroheni se po përdorni pikërisht versionin e ri!
exim --versionNe u mblodhëm dhe e zgjidhëm situatën specifike me ta.
Në server u përdor DirectAdmin dhe kishte paketën e tij të vjetër da_exim (në version të vjetër, pa dobësi).
Duke përdorim menaxherin e paketave të DirectAdmin, custombuild, u instalua një version më i ri i exim që është i ekspozuar ndaj sulmeve.
Në këtë rast, përditësimi nëpërmjet custombuild gjithashtu ndihmoi.
Mos harroni të bëni backup para eksperimenteve të tilla dhe sigurohuni që para/pas përditësimit, të gjitha proceset e exim të versionit të vjetër dhe të mos jenë "ngjitur" në memorie.
Burimi: habr.com
