KollegĂ«t, ata qĂ« pĂ«rdorin nĂ« serverat e tyre tĂ« postĂ«s Exim versionet 4.87âŠ4.91 - rregulloni menjĂ«herĂ« nĂ« versionin 4.92, duke e ndaluar mĂ« parĂ« vetĂ« Exim-in pĂ«r tĂ« shmangur hakerimin pĂ«rmes CVE-2019-10149.
Potencialisht të prekura janë disa milion servera në të gjithë botën, vulnerabiliteti është klasifikuar si kritik (CVSS 3.0 base score = 9.8/10). Hakerët mund të ekzekutojnë komanda të rastësishme në serverin tuaj, në shumë raste nga përdoruesi root.
Ju lutemi sigurohuni që po përdorni versionin e korrigjuar (4.92) ose tashmë të patch-uar.
Ose patch-oni ekzistuesin, shihni degën .
Përditësimi për centos 6: shihni - për centos 7 funksionon gjithashtu, nëse nga epel nuk ka ardhur ende.
UPD: Ubuntu të prekur 18.04 dhe 18.10, përditësimi për ta është lëshuar. Versionet 16.04 dhe 19.04 nuk janë të prekur, përveç nëse variantet e personalizuara janë instaluar mbi to. Më shumë informacion .
Aktualisht problemi i përshkruar atje po eksplotohet aktivisht (nga një bot, supozohet), e kam vënë re në disa servera të mi (që kanë funksionuar në 4.91) infektimin.
Vijoni Ă«shtĂ« veçanĂ«risht aktual pĂ«r ata qĂ« tashmĂ« janĂ« "kapur" â duhet ose tĂ« transferoni gjithçka nĂ« njĂ« VPS tĂ« pastĂ«r me softverin mĂ« tĂ« ri, ose tĂ« kĂ«rkoni njĂ« zgjidhje. A po e provojmĂ«? Na shkruani nĂ«se ndonjĂ« dikush mund tĂ« luftojĂ« kĂ«tĂ« malware.
Nëse ju, si përdorues i Exim dhe duke e lexuar këtë, ende nuk jeni azhurnuar (nuk keni verifikuar se keni versionin 4.92 ose versionin e patchuar), ju lutem ndaloni dhe shkoni të azhurnoni.
PĂ«r ata qĂ« tashmĂ« janĂ« kapur â le tĂ« vazhdojmĂ«...
UPD: dhe jep një këshillë të saktë:
Ka shumë lloje të malware. Duke aktivizuar një ilaç që nuk është i duhuri dhe duke pastruar radhën, përdoruesi nuk do të shërohet ndoshta dhe nuk do të dijë se çfarë duhet të trajtojë.
Infektimi është i dukshëm kështu: [kthrotlds] ngarkon procesorin; në një VDS të dobët në 100%, në serverat më të dobët, por dukshëm.
Pas infektimit, malware e fshin regjistrimet në crontab, duke e regjistruar vetëm veten për ta aktivizuar çdo 4 minuta, duke bërë që skedari i crontabit të bëhet immutable. Crontab -e nuk mund të ruajë ndryshimet, jep një gabim.
Mutable mund të hiqet kështu, pas së cilës mund të hiqni linjën e komandës (1.5kb):
chattr -i /var/spool/cron/root
crontab -e Pastaj në redaktorin e crontab (vim) hiqni linjën dhe ruani:dd
:wq
Megjithatë, njëri nga proceset aktive po e shkruan përsëri, jam duke e shqyrtuar.
NĂ« kĂ«tĂ« mĂ«nyrĂ«, ka njĂ« sasi tĂ« madhe wgetâash (ose curlâash) qĂ« janĂ« nĂ« adresat e skriptit tĂ« instaluesit (shih mĂ« poshtĂ«), pĂ«r tani i ndaloj kĂ«shtu, por ata fillojnĂ« pĂ«rsĂ«ri:
ps aux | grep wge[t]
ps aux | grep cur[l]
echo "Ndalimi..."
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 e gjeta këtu (centos): /usr/local/bin/nptd⊠nuk e publikoj për shkak të sigurisë, por nëse dikush është infektuar dhe di diçka për skriptet shell, ju lutem studiojeni më me kujdes.
Do ta plotësoj me informacionin e përditësuar.
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 edhe ndalimi i shĂ«rbimit â duhej ta hiqja krejtĂ«sisht crontab (kur tĂ« vendosni emrin e bin-failit).
UPD 2: Instaluesi i trojanit ndonjëherë ndodhej edhe në vende të tjera, ndihmoi kërkimi sipas madhësisë:
find / -size 19825c
UPD 3: Kujdes! Përveç ndalimit të selinux, trojani gjithashtu shton çelësin e tij SSH në ${sshdir}/authorized_keys! Dhe aktivizon fushat e mëposhtme në /etc/ssh/sshd_config, nëse ato nuk ishin regjistruar si PO:
PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes
echo UsePAM yes
PasswordAuthentication yes
UPD 4: Deri për momentin: çaktivizoni exim, cron (me rrënjë), urgjent hiqni çelësin trojan nga ssh dhe rregulloni konfigurimin e sshd, rindezni sshd! Edhe pse nuk është e sigurt se kjo do të ndihmojë, por pa këtë është një katastrofë.
Kam sjellë informacion të rëndësishëm nga komentet për patch/azhurimet në fillim të shënimeve, në mënyrë që ata që e lexojnë të fillojnë nga aty.
UPD 5: se malware ka ndryshuar fjalëkalimet në WordPress.
UPD 6: , po e testojmë! Pas rinisjes ose çaktivizimit të ilaçit, duket se ndalon, por tani është kështu.
Kush do të bëjë (apo gjejë) një zgjidhje stabile, ju lutem shkruani, do të ndihmoni shumë.
UPD 7: shkruan:
Nëse nuk e kanë thënë ende, virusi ringjallet përmes një email-i të papërfunduar në exim, me përpjekjen e përsëritur për ta dërguar email-in, ai rikuperohet, shikoni në /var/spool/exim4
Të gjithë radhët e exim mund të pastrohen 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 funksionon, faleminderit për skriptin!
Kryesore, mos harroni se serveri është komprometuar tashmë dhe keqbërësit mund të kenë futur disa gjëra të tjera atipike (jo të shkruara në droppër).
Prandaj, Ă«shtĂ« mĂ« mirĂ« tĂ« kaloni nĂ« njĂ« server tĂ« instaluar nga e para (vds), ose tĂ« paktĂ«n tĂ« vazhdoni tĂ« monitoroni situatĂ«n â nĂ«se ka ndonjĂ« gjĂ« tĂ« re, shkruani nĂ« komente kĂ«tu, sepse dukshĂ«m jo tĂ« gjithĂ« do tĂ« kalojnĂ« nĂ« njĂ« instalim tĂ« ri...
UPD 10: Faleminderit përsëri : ai kujton se infektohen jo vetëm serverët, por për shembull edhe Raspberry Pi, dhe çdo lloj virtualizimi... Prandaj, pas shpëtimit të serverëve, mos harroni të shpëtoni edhe konsolat e lojërave, robotët dhe tjerë.
UPD 11: Nga një shënim i rëndësishëm për "ata që shërojnë manualisht":
(pas aplikimit të ndonjë metode për të luftuar këtë malware)
duhet patjetĂ«r tĂ« rindizni â malware qĂ«ndron diku nĂ« proceset e hapura dhe, pĂ«r rrjedhojĂ«, nĂ« memorje, dhe e regjistron veten pĂ«rsĂ«ri nĂ« cron çdo 30 sekonda
UPD 12: në radhën e tij një malware tjetër(?) exim dhe sugjeron së pari të studioni problemin tuaj specifik përpara se të filloni trajtimin.
UPD 13: më mirë të kaloni në një sistem të pastër, dhe të transferoni skedarët me shumë kujdes, pasi malware tashmë është në dispozicion publik dhe mund të përdoret nga të tjerë në mënyra më të fshehta dhe më të rrezikshme.
UPD 14: duke u qetĂ«suar duke menduar se si njerĂ«zit e zgjuar nuk e aktivizojnĂ« nga rrenja â njĂ« tjetĂ«r :
Edhe nëse nuk punon nën rrenjë, ndodhin thyerje... Unë kam një OrangePi me debian jessie UPD: stretch, exim i nisur nga Debian-exim dhe megjithatë ndodhi thyerja, fshihet krona dhe gjëra të tjera.
UPD 15: kur kaloni në një server të pastër nga ai i kompromituar, mos harroni të ruani higjienën, :
Kur transferoni të dhëna, kushtoni vëmendje jo vetëm skedarëve ekzekutivë ose konfigurues, por gjithçkaje që mund të përmbajë komanda keqdashëse (për shembull, në MySQL mund të jetë CREATE TRIGGER ose CREATE EVENT). Gjithashtu, mos harroni për skedarët .html, .js, .php, .py dhe skedarët e tjerë publikë (idealisht këta skedarë, si dhe të dhëna të tjera, duhet të rikuperohen nga një depo lokal ose të besueshme).
UPD 16: dhe : në sistem kishte një version të exim në porte, por në të vërtetë po ekzekutohej një tjetër.
Kështu që të gjithëve pas pas përmirësimit, është e rëndësishme të siguroheni se po përdorni versionin e ri!
exim --versionNe e zgjidhëm situatën e tyre së bashku.
Në server u përdor DirectAdmin dhe ishte instaluar paketa e saj e vjetër da_exim (versioni i vjetër, pa dobësi).
Megjithatë, me ndihmën e menaxherit të paketave të DirectAdmin-it custombuild, në fakt u instalua një version më i ri exim, tashmë i prekur.
Në këtë situatë, gjithashtu ndihmoi përmirësimi përmes custombuild.
Mos harroni të bëni backup para eksperimentimeve të tilla, dhe gjithashtu sigurohuni që para/pas përmirësimit të gjitha proceset e exim të versionit të vjetër dhe nuk ishin 'ngjitur' në memorie.
Burimi: habr.com
