Kolegoj, kiuj uzas Exim-versiojn 4.87...4.91 sur siaj poŝtserviloj - urĝe ĝisdatigas al versio 4.92, antaŭe ĉesiginte Exim mem por eviti hakadon per CVE-2019-10149.
Pluraj milionoj da serviloj tra la mondo estas eble vundeblaj, la vundebleco estas taksita kiel kritika (CVSS 3.0 baza poentaro = 9.8/10). Atakantoj povas ruli arbitrajn komandojn sur via servilo, en multaj kazoj de radiko.
Bonvolu certigi, ke vi uzas fiksan version (4.92) aŭ jam flikitan.
Aŭ fliki la ekzistantan, vidu fadenon .
Ĝisdatigo por centoj 6: cm. — por centos 7 ankaŭ funkcias, se ĝi ankoraŭ ne alvenis rekte de epel.
UPD: Ubuntu estas tuŝita 18.04 kaj 18.10, ĝisdatigo estis publikigita por ili. Versioj 16.04 kaj 19.04 ne estas tuŝitaj krom se kutimaj opcioj estis instalitaj sur ili. Pli da detaloj .
Nun la problemo tie priskribita estas aktive ekspluatata (per bot, supozeble), mi rimarkis infekton ĉe iuj serviloj (funkciantaj sur 4.91).
Plia legado gravas nur por tiuj, kiuj jam "akiris ĝin" - vi devas aŭ transporti ĉion al pura VPS kun freŝa programaro, aŭ serĉi solvon. Ĉu ni provu? Skribu se iu povas venki ĉi tiun malware.
Se vi, estante Exim-uzanto kaj legante ĉi tion, ankoraŭ ne ĝisdatigis (ne certigis ke 4.92 aŭ flikita versio estas disponebla), bonvolu halti kaj kuri por ĝisdatigi.
Por tiuj, kiuj jam alvenis tien, ni daŭrigu...
UPS: kaj donas la ĝustajn konsilojn:
Povas ekzisti granda vario de malware. Lanĉante la medikamenton por la malĝusta afero kaj malplenigante la atendovicon, la uzanto ne resaniĝos kaj eble ne scias, por kio li devas esti traktita.
La infekto estas rimarkebla tiel: [kthrotlds] ŝarĝas la procesoron; sur malforta VDS ĝi estas 100%, ĉe serviloj ĝi estas pli malforta sed rimarkebla.
Post infekto, la malware forigas cron-enirojn, registrante nur sin tie por funkcii ĉiujn 4 minutojn, dum igas la crontab-dosieron neŝanĝebla. Crontab -e ne povas konservi ŝanĝojn, donas eraron.
Neŝanĝebla povas esti forigita, ekzemple, tiel, kaj poste forigi la komandlinion (1.5kb):
chattr -i /var/spool/cron/root
crontab -e
Poste, en la crontab-redaktilo (vim), forigu la linion kaj konservu:dd
:wq
Tamen, iuj el la aktivaj procezoj denove superskribas, mi eltrovas ĝin.
Samtempe, estas amaso da aktivaj wgets (aŭ bukloj) pendantaj sur la adresoj de la instalila skripto (vidu sube), mi nun faligas ilin tiel, sed ili rekomencas:
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}'`
Mi trovis la trojan instalilon ĉi tie (centos): /usr/local/bin/nptd... Mi ne afiŝas ĝin por eviti ĝin, sed se iu estas infektita kaj komprenas ŝelajn skriptojn, bonvolu studi ĝin pli atente.
Mi aldonos kiel informoj estas ĝisdatigitaj.
UPD 1: Forigo de dosieroj (kun prepara chattr -i) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root ne helpis, nek ĉesigi la servon - mi devis crontab tute nuntempe elŝiru ĝin (alinomi la bin-dosieron).
UPD 2: La troja instalilo foje kuŝis ankaŭ en aliaj lokoj, serĉado laŭ grandeco helpis:
trovi / -size 19825c
UPD 3/XNUMX/XNUMX: Singardemo Krom malŝalti selinux, la trojano ankaŭ aldonas sian propran SSH-ŝlosilo en ${sshdir}/authorized_keys! Kaj aktivigas la sekvajn kampojn en /etc/ssh/sshd_config, se ili ne jam estis agordita al JES:
PermitRootLogin jes
RSAaŭtentigo jes
PubkeyAuthentication jes
echo UsePAM jes
Pasvorta aŭtentigo jes
UPD 4: Por resumi nuntempe: malŝaltu Exim, cron (kun radikoj), urĝe forigu la trojan ŝlosilon de ssh kaj redaktu la sshd-agordon, rekomencu sshd! Kaj ankoraŭ ne estas klare, ke ĉi tio helpos, sed sen ĝi estas problemo.
Mi movis gravajn informojn de la komentoj pri flikoj/ĝisdatigoj al la komenco de la noto, por ke legantoj komencu per ĝi.
UPD 5/XNUMX/XNUMX: ke la malbon-programo ŝanĝis pasvortojn en WordPress.
UPD 6/XNUMX/XNUMX: , ni provu! Post rekomenco aŭ malŝalto, la medikamento ŝajnas malaperi, sed nuntempe almenaŭ tio estas.
Ĉiu, kiu faras (aŭ trovas) stabilan solvon, bonvolu skribi, vi helpos multajn.
UPD 7/XNUMX/XNUMX: skribas:
Se vi ne jam diris, ke la viruso reviviĝas danke al nesendita letero en Exim, kiam vi provas sendi la leteron denove, ĝi estas restarigita, rigardu en /var/spool/exim4.
Vi povas forigi la tutan Exim-vicon tiel:
exipick -i | xargs exim -Sinjoro
Kontrolante la nombron da eniroj en la vico:
exim -bpc
UPD 8: Denove : FirstVDS proponis sian version de la trakta skripto, ni provu ĝin!
UPD 9: Ŝajnas laboras, Dankon por la skripto!
La ĉefa afero estas ne forgesi, ke la servilo jam estis kompromitita kaj la atakantoj povus esti sukcesintaj planti kelkajn pli maltipajn malbonajn aferojn (ne listigitajn en la guto).
Tial, estas pli bone moviĝi al tute instalita servilo (vds), aŭ almenaŭ daŭrigi monitori la temon - se estas io nova, skribu en la komentoj ĉi tie, ĉar evidente ne ĉiuj moviĝos al freŝa instalado...
UPD 10: Dankon denove : ĝi memorigas, ke ne nur serviloj estas infektitaj, sed ankaŭ Frambo Pi, kaj ĉiaj virtualaj maŝinoj... Do post savo de la serviloj, ne forgesu konservi viajn videokonzolojn, robotojn, ktp.
UPD 11: De Grava noto por manaj resanigantoj:
(post uzado de unu aŭ alia metodo por kontraŭbatali ĉi tiun malware)
Vi certe devas rekomenci - la malbon-programo sidas ie en malfermitaj procezoj kaj, sekve, en memoro, kaj skribas al si novan por kroni ĉiujn 30 sekundojn.
UPD 12/XNUMX/XNUMX: Exim havas alian(?) malware en sia vico kaj konsilas vin unue studi vian specifan problemon antaŭ ol komenci kuracadon.
UPD 13/XNUMX/XNUMX: prefere, movu al pura sistemo, kaj translokigu dosierojn ege zorge, ĉar La malbon-varo jam estas publike havebla kaj povas esti uzata en aliaj, malpli evidentaj kaj pli danĝeraj manieroj.
UPD 14: trankviligi nin, ke inteligentaj homoj ne kuras de radiko - ankoraŭ unu afero :
Eĉ se ĝi ne funkcias de radiko, hakado okazas... Mi havas debian jessie UPD: streĉu sur mia OrangePi, Exim funkcias de Debian-exim kaj ankoraŭ okazis hakado, perditaj kronoj ktp.
UPD 15: kiam vi translokiĝas al pura servilo de kompromitita, ne forgesu pri higieno, :
Dum transdono de datumoj, atentu ne nur al ruleblaj aŭ agordaj dosieroj, sed ankaŭ al ĉio, kio povas enhavi malicajn komandojn (ekzemple, en MySQL tio povus esti CREATE TRIGGER aŭ CREATE EVENT). Ankaŭ, ne forgesu pri .html, .js, .php, .py kaj aliaj publikaj dosieroj (ideale ĉi tiuj dosieroj, kiel aliaj datumoj, estu restaŭrigitaj el loka aŭ alia fidinda stokado).
UPD 16/XNUMX/XNUMX: и : la sistemo havis unu version de Exim instalita en la havenoj, sed fakte ĝi funkciis alian.
Do ĉiuj post la ĝisdatigo vi devus certigi ke vi uzas la novan version!
exim --versionNi kune aranĝis ilian specifan situacion.
La servilo uzis DirectAdmin kaj ĝian malnovan pakon da_exim (malnova versio, sen vundebleco).
Samtempe, kun la helpo de la personkonstrua pakaĵmanaĝero de DirectAdmin, fakte, pli nova versio de Exim estis tiam instalita, kiu jam estis vundebla.
En ĉi tiu aparta situacio, ĝisdatigo per custombuild ankaŭ helpis.
Ne forgesu fari sekurkopiojn antaŭ tiaj eksperimentoj, kaj ankaŭ certigu, ke antaŭ/post la ĝisdatigo ĉiuj Exim-procezoj estas de la malnova versio. kaj ne "algluiĝis" en memoro.
fonto: www.habr.com