Kolegët që përdorin versionet e Exim 4.87...4.91 në serverët e tyre të postës - përditësoni urgjentisht në versionin 4.92, pasi e kishin ndaluar më parë vetë Exim për të shmangur hakerimin përmes CVE-2019-10149.
Disa milionë serverë në mbarë botën janë potencialisht të cenueshëm, dobësia vlerësohet si kritike (rezultati bazë CVSS 3.0 = 9.8/10). Sulmuesit mund të ekzekutojnë komanda arbitrare në serverin tuaj, në shumë raste nga root.
Ju lutemi sigurohuni që jeni duke përdorur një version fiks (4.92) ose një që tashmë është korrigjuar.
Ose patch ekzistuesin, shiko thread .
Përditëso për cent 6: cm. - për centos 7 funksionon gjithashtu, nëse nuk ka ardhur ende direkt nga epel.
UPD: Ubuntu është prekur 18.04 dhe 18.10, për ta është lëshuar një përditësim. Versionet 16.04 dhe 19.04 nuk preken nëse nuk janë instaluar opsione të personalizuara në to. Më shumë detaje .
Tani problemi i përshkruar atje është duke u shfrytëzuar në mënyrë aktive (nga një bot, me sa duket), vura re një infeksion në disa serverë (që funksionojnë në 4.91).
Leximi i mëtejshëm është i rëndësishëm vetëm për ata që tashmë e kanë "marrë atë" - duhet ose të transportoni gjithçka në një VPS të pastër me softuer të freskët, ose të kërkoni një zgjidhje. Të provojmë? Shkruani nëse dikush mund ta kapërcejë këtë malware.
Nëse ju, duke qenë përdorues i Exim dhe e lexoni këtë, ende nuk e keni përditësuar (nuk jeni siguruar që versioni 4.92 ose i korrigjuar është i disponueshëm), ju lutemi ndaloni dhe ekzekutoni për të përditësuar.
Për ata që tashmë kanë arritur atje, le të vazhdojmë...
UPD: dhe jep këshillat e duhura:
Mund të ketë një larmi të madhe malware. Duke hedhur në treg ilaçin për gjënë e gabuar dhe duke pastruar radhën, përdoruesi nuk do të shërohet dhe mund të mos dijë se për çfarë duhet të trajtohet.
Infeksioni është i dukshëm si ky: [kthrotlds] ngarkon procesorin; në një VDS të dobët është 100%, në serverë është më i dobët por i dukshëm.
Pas infektimit, malware fshin hyrjet e cron, duke regjistruar vetëm veten atje për të ekzekutuar çdo 4 minuta, duke e bërë skedarin crontab të pandryshueshëm. Crontab -e nuk mund të ruaj ndryshimet, jep një gabim.
Immutable mund të hiqet, për shembull, si kjo, dhe më pas të fshihet rreshti i komandës (1.5 kb):
chattr -i /var/spool/cron/root
crontab -e
Tjetra, në redaktorin crontab (vim), fshini rreshtin dhe ruani:dd
:wq
Sidoqoftë, disa nga proceset aktive po rishkruhen përsëri, unë po e kuptoj.
Në të njëjtën kohë, ka një mori wgets (ose kaçurrela) aktive që varen në adresat nga skripti i instaluesit (shih më poshtë), unë po i rrëzoj si kjo tani për tani, por ato fillojnë përsëri:
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}'`
E gjeta skriptin e instaluesit të Trojanit këtu (centos): /usr/local/bin/nptd... Nuk po e postoj për ta shmangur, por nëse dikush është i infektuar dhe i kupton skriptet e guaskës, ju lutemi ta studioni më me kujdes.
Do të shtoj pasi informacioni përditësohet.
UPD 1: Fshirja e skedarëve (me chattr -i paraprak) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root nuk ndihmoi, as ndalimi i shërbimit - më duhej të crontab plotësisht tani për tani gris atë (riemërto skedarin bin).
UPD 2: Instaluesi i Trojanit ndonjëherë ndodhej gjithashtu i shtrirë në vende të tjera, kërkimi sipas madhësisë ndihmoi:
gjeni / -madhësia 19825c
UPD 3/XNUMX/XNUMX: Kujdes! Përveç çaktivizimit të selinux-it, Trojani shton edhe të vetin Çelësi SSH në ${sshdir}/authorized_keys! Dhe aktivizon fushat e mëposhtme në /etc/ssh/sshd_config, nëse ato nuk janë vendosur tashmë në YES:
PermitRootLogin po
Autentifikimi RSAA po
BubkeyAutentikimi po
echo UsePAM po
Vërtetimi i fjalëkalimit po
UPD 4: Për ta përmbledhur tani për tani: çaktivizoni Exim, cron (me rrënjë), hiqni urgjentisht çelësin Trojan nga ssh dhe modifikoni konfigurimin sshd, rinisni sshd! Dhe nuk është ende e qartë se kjo do të ndihmojë, por pa të ka një problem.
Kam zhvendosur informacione të rëndësishme nga komentet rreth arnimeve/përditësimeve në fillim të shënimit, në mënyrë që lexuesit të fillojnë me të.
UPD 5/XNUMX/XNUMX: se malware ka ndryshuar fjalëkalimet në WordPress.
UPD 6/XNUMX/XNUMX: , le të testojmë! Pas një rindezjeje ose mbylljeje, ilaçi duket se zhduket, por tani për tani të paktën kaq.
Kushdo që bën (ose gjen) një zgjidhje të qëndrueshme, ju lutemi të shkruani, do të ndihmoni shumë.
UPD 7/XNUMX/XNUMX: shkruan:
Nëse nuk e keni thënë tashmë që virusi është ringjallur falë një letre të padërguar në Exim, kur përpiqeni ta dërgoni përsëri letrën, ajo rikthehet, shikoni në /var/spool/exim4
Ju mund të pastroni të gjithë radhën e Exim si kjo:
ekzipik -i | xargs exim -Mrm
Kontrollimi i numrit të hyrjeve në radhë:
exim -bpc
UPD 8: Përsëri : FirstVDS ofroi versionin e tyre të skenarit të trajtimit, le ta testojmë atë!
UPD 9: Duket si po punon, Faleminderit për skenarin!
Gjëja kryesore është të mos harrojmë se serveri tashmë ishte i komprometuar dhe sulmuesit mund të kishin arritur të vendosnin disa gjëra më të këqija atipike (jo të listuara në pikatore).
Prandaj, është më mirë të kaloni në një server të instaluar plotësisht (vds), ose të paktën të vazhdoni të monitoroni temën - nëse ka ndonjë të re, shkruani në komentet këtu, sepse Natyrisht jo të gjithë do të kalojnë në një instalim të ri...
UPD 10: Faleminderit përsëri : kujton se jo vetëm serverët janë të infektuar, por edhe Mjedër Pi, dhe të gjitha llojet e makinave virtuale... Kështu që pasi të keni ruajtur serverët, mos harroni të ruani konzolat tuaja video, robotët, etj.
UPD 11: Nga Shënim i rëndësishëm për shëruesit manualë:
(pas përdorimit të një ose një metode tjetër për të luftuar këtë malware)
Ju patjetër duhet të rindizni - malware qëndron diku në procese të hapura dhe, në përputhje me rrethanat, në memorie, dhe shkruan një të re për t'u rikthyer çdo 30 sekonda
UPD 12/XNUMX/XNUMX: Exim ka një tjetër malware (?) në radhë dhe ju këshillon që së pari të studioni problemin tuaj specifik përpara se të filloni trajtimin.
UPD 13/XNUMX/XNUMX: përkundrazi, kaloni në një sistem të pastër dhe transferoni skedarët me shumë kujdes, sepse Malware tashmë është i disponueshëm publikisht dhe mund të përdoret në mënyra të tjera, më pak të dukshme dhe më të rrezikshme.
UPD 14: të sigurojmë veten se njerëzit e zgjuar nuk ikin nga rrënjët - edhe një gjë :
Edhe nëse nuk funksionon nga rrënjët, ndodh hakimi... Unë kam debian jessie UPD: shtrirje në OrangePi tim, Exim po funksionon nga Debian-exim dhe ende ka ndodhur hakimi, ka humbur kurorat, etj.
UPD 15: kur kaloni në një server të pastër nga një i komprometuar, mos harroni për higjienën, :
Kur transferoni të dhëna, kushtojini vëmendje jo vetëm skedarëve të ekzekutueshëm ose të konfigurimit, por edhe çdo gjëje që mund të përmbajë komanda me qëllim të keq (për shembull, në MySQL kjo mund të jetë CREATE TRIGGER ose CREATE EVENT). Gjithashtu, mos harroni për .html, .js, .php, .py dhe skedarë të tjerë publikë (në mënyrë ideale, këta skedarë, si të dhënat e tjera, duhet të restaurohen nga memoria lokale ose nga një ruajtje tjetër e besuar).
UPD 16/XNUMX/XNUMX: и : sistemi kishte një version të Exim të instaluar në porte, por në realitet po ekzekutonte një tjetër.
Pra të gjithë pas përditësimit duhet të siguroheni se po përdorni versionin e ri!
exim --versionSë bashku e zgjidhëm situatën e tyre specifike.
Serveri përdorte DirectAdmin dhe paketën e tij të vjetër da_exim (versioni i vjetër, pa cenueshmëri).
Në të njëjtën kohë, me ndihmën e menaxherit të paketave custombuild të DirectAdmin, në fakt, më pas u instalua një version më i ri i Exim, i cili tashmë ishte i cenueshëm.
Në këtë situatë të veçantë, përditësimi nëpërmjet custombuild gjithashtu ndihmoi.
Mos harroni të bëni kopje rezervë përpara eksperimenteve të tilla dhe gjithashtu sigurohuni që para/pas përditësimit të gjitha proceset Exim janë të versionit të vjetër dhe jo “të ngecur” në kujtesë.
Burimi: www.habr.com