Skubiai atnaujinkite Exim į 4.92 - yra aktyvi infekcija

Kolegos, kurie naudoja Exim 4.87...4.91 versijas savo pašto serveriuose – skubiai atnaujinkite į 4.92 versiją, prieš tai sustabdę patį Exim, kad išvengtumėte įsilaužimo per CVE-2019-10149.

Keli milijonai serverių visame pasaulyje yra potencialiai pažeidžiami, pažeidžiamumas įvertintas kaip kritinis (CVSS 3.0 bazinis balas = 9.8/10). Užpuolikai gali paleisti savavališkas komandas jūsų serveryje, daugeliu atvejų iš root.

Įsitikinkite, kad naudojate fiksuotą versiją (4.92) arba tą, kuri jau buvo pataisyta.
Arba pataisykite esamą, žiūrėkite giją nepriekaištingas komentaras.

Atnaujinimas skirtas centai 6: cm. Teodoro komentaras — už centos 7 taip pat veikia, jei dar neatkeliavo tiesiai iš epel.

UPD: paveiktas Ubuntu 18.04 ir 18.10, jiems buvo išleistas naujinimas. 16.04 ir 19.04 versijos neturi įtakos, nebent jose buvo įdiegtos tinkintos parinktys. Daugiau informacijos jų oficialioje svetainėje.

Informacija apie problemą „Opennet“.
Informacija Exim svetainėje

Dabar ten aprašyta problema yra aktyviai išnaudojama (tikėtina, kad robotas), kai kuriuose serveriuose pastebėjau infekciją (veikia 4.91).

Tolesnis skaitymas aktualus tik tiems, kurie jau „gavo“ - reikia arba gabenti viską į švarų VPS su nauja programine įranga, arba ieškoti sprendimo. Pabandysim? Parašykite, jei kas nors gali įveikti šią kenkėjišką programą.

Jei esate Exim vartotojas ir skaitote tai, kad vis dar neatnaujinote (neįsitikinote, kad yra 4.92 arba pataisyta versija), sustokite ir paleiskite naujinimą.

Tiems, kurie jau ten pateko, tęskime...

UPD: supersmile2009 rado kito tipo kenkėjiškų programų ir duoda teisingą patarimą:

Kenkėjiškų programų gali būti labai daug. Paleidus vaistą dėl netinkamo dalyko ir išvalius eilę, vartotojas nepagys ir gali nežinoti, nuo ko reikia gydytis.

Infekcija pastebima taip: [kthrotlds] įkelia procesorių; ant silpno VDS jis yra 100%, serveriuose jis yra silpnesnis, bet pastebimas.

Po užkrėtimo kenkėjiška programa ištrina cron įrašus, ten užregistruoja tik save, kad paleistų kas 4 minutes, o crontab failas tampa nekintamas. Crontab -e negali išsaugoti pakeitimų, pateikia klaidą.

Immutable galima pašalinti, pavyzdžiui, taip, tada ištrinti komandinę eilutę (1.5 kb):

chattr -i /var/spool/cron/root
crontab -e

Tada crontab redaktoriuje (vim) ištrinkite eilutę ir išsaugokite:dd
:wq

Tačiau kai kurie aktyvūs procesai vėl perrašomi, aš tai suprantu.

Tuo pačiu metu ant adresų iš diegimo programos scenarijaus kabo krūva aktyvių wget'ų (arba curlų) (žr. toliau), kol kas juos numušinėju taip, bet jie vėl prasideda:

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}'`

Trojan diegimo scenarijų radau čia (centos): /usr/local/bin/nptd... Skelbiu ne tam, kad to išvengčiau, bet jei kas yra užkrėstas ir supranta apvalkalo scenarijus, prašome jį atidžiau išstudijuoti.

Papildysiu, kai informacija bus atnaujinta.

UPD 1: Failų ištrynimas (su preliminariu chattr -i) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root nepadėjo ir paslaugos sustabdymas – turėjau crontab kol kas visiškai išplėškite (pervardykite bin failą).

UPD 2: Trojos arklys kartais taip pat gulėdavo kitose vietose, o paieška pagal dydį padėjo:
rasti / -dydis 19825c

UPD 3-XNUMX-XNUMX: Dėmesio! Be Selinux išjungimo, Trojos arklys taip pat prideda savo SSH raktas ${sshdir}/authorized_keys! Ir suaktyvina šiuos laukus /etc/ssh/sshd_config, jei jie dar nebuvo nustatyti į TAIP:
„PermitRootLogin“ taip
RSAA autentifikavimas taip
„PubkeyAuthentication“ taip
echo UsePAM taip
Slaptažodžio autentifikavimas taip

UPD 4: Apibendrinant dabar: išjunkite Exim, cron (su šaknimis), skubiai pašalinkite Trojos arklys iš ssh ir redaguokite sshd konfigūraciją, paleiskite sshd iš naujo! Ir dar neaišku, ar tai padės, bet be to yra problema.

Svarbią informaciją iš komentarų apie pataisas/atnaujinimus perkėliau į užrašo pradžią, kad skaitytojai pradėtų nuo jos.

UPD 5-XNUMX-XNUMX: KitasDenny rašo kad kenkėjiška programa pakeitė „WordPress“ slaptažodžius.

UPD 6-XNUMX-XNUMX: Paulmannas paruošė laikiną gydymą, isbandykime! Atrodo, kad po perkrovimo ar išjungimo vaistas dingsta, bet kol kas tai yra.

Kas padarys (ar randa) stabilų sprendimą, rašykite, daugeliui padėsite.

UPD 7-XNUMX-XNUMX: Vartotojo clsv rašo:

Jei dar nesakėte, kad virusas prisikėlė dėl neišsiųsto laiško Exim, bandant išsiųsti laišką dar kartą, jis atkuriamas, ieškokite /var/spool/exim4

Visą Exim eilę galite išvalyti taip:
exipick -i | xargs exim -Mrm
Patikrinkite įrašų skaičių eilėje:
exim -bpc

UPD 8: vėl ačiū už informaciją AnotherDenny: FirstVDS pasiūlė savo gydymo scenarijaus versiją, išbandykime!

UPD 9: atrodo kūryba, dėkoju Kirilas už scenarijų!

Svarbiausia nepamiršti, kad serveris jau buvo pažeistas ir užpuolikai galėjo pasodinti netipiškesnių bjaurių dalykų (neįrašytas dropperyje).

Todėl geriau pereiti prie pilnai įdiegto serverio (vds), arba bent jau toliau stebėti temą - jei kas naujo rašykite čia komentaruose, nes aišku ne visi pereis prie naujos instaliacijos...

UPD 10: Dar kartą ačiū clsv: primena, kad užkrėsti ne tik serveriai, bet ir Aviečių Pi, ir visokias virtualias mašinas... Taigi išsaugoję serverius nepamirškite išsaugoti vaizdo pultų, robotų ir t.t.

UPD 11: nuo gydymo scenarijaus autorius Svarbi pastaba rankiniams gydytojams:
(panaudojus vieną ar kitą kovos su šia kenkėjiška programa metodą)

Būtinai reikia paleisti iš naujo - kenkėjiška programa sėdi kažkur atviruose procesuose ir atitinkamai atmintyje ir kas 30 sekundžių įrašo naują, kad cron

UPD 12-XNUMX-XNUMX: supersmile2009 rasta „Exim“ savo eilėje turi kitą (?) kenkėjišką programą ir pataria prieš pradedant gydymą išnagrinėti konkrečią problemą.

UPD 13-XNUMX-XNUMX: lorkas pataria verčiau pereikite prie švarios sistemos ir itin atsargiai perkelkite failus, nes Kenkėjiška programa jau yra viešai prieinama ir gali būti naudojama kitais, mažiau akivaizdžiais ir pavojingesniais būdais.

UPD 14: nuraminti save, kad protingi žmonės nebėga nuo šaknų – dar vienas dalykas skubus pranešimas iš clsv:

Net jei jis neveikia iš root, įsilaužimas įvyksta... Turiu debian jessie UPD: patempkite ant mano OrangePi, Exim veikia iš Debian-exim ir vis tiek įvyko įsilaužimas, pamestos karūnos ir pan.

UPD 15: pereidami į švarų serverį iš pažeisto, nepamirškite apie higieną, naudingas priminimas iš w0den:

Perkeldami duomenis atkreipkite dėmesį ne tik į vykdomuosius ar konfigūracijos failus, bet ir į viską, kur gali būti kenkėjiškų komandų (pavyzdžiui, MySQL tai gali būti CREATE TRIGGER arba CREATE EVENT). Taip pat nepamirškite apie .html, .js, .php, .py ir kitus viešus failus (idealiu atveju šie failai, kaip ir kiti duomenys, turėtų būti atkurti iš vietinės ar kitos patikimos saugyklos).

UPD 16-XNUMX-XNUMX: daykkin и laukinis_aš susidūrė su kita problema: sistemoje prievaduose buvo įdiegta viena Exim versija, tačiau iš tikrųjų ji veikė kitą.

Taigi visi po atnaujinimo turėtumėte įsitikinti kad naudojate naują versiją!

exim --version

Mes kartu išsiaiškinome jų konkrečią situaciją.

Serveris naudojo „DirectAdmin“ ir seną „da_exim“ paketą (seną versiją, be pažeidžiamumo).

Tuo pačiu metu, naudojant „DirectAdmin“ individualizavimo paketų tvarkyklę, iš tikrųjų buvo įdiegta naujesnė „Exim“ versija, kuri jau buvo pažeidžiama.

Šioje konkrečioje situacijoje taip pat padėjo atnaujinimas naudojant custombuild.

Nepamirškite prieš tokius eksperimentus pasidaryti atsarginių kopijų, taip pat įsitikinkite, kad prieš/po atnaujinimo visi Exim procesai yra senos versijos. buvo sustabdyti ir „neįstrigęs“ atmintyje.

Šaltinis: www.habr.com