Colleagues, those using Exim versions 4.87 to 4.91 on their mail servers — please urgently upgrade to version 4.92, stopping Exim beforehand to prevent exploitation via CVE-2019-10149.
Several million servers worldwide are potentially vulnerable, with the vulnerability rated as critical (CVSS 3.0 base score = 9.8/10). Attackers can execute arbitrary commands on your server, often with root privileges.
Please ensure you are using the patched version (4.92) or a previously patched one.
Or patch the existing one, see thread .
Update for CentOS 6: see — it also works for CentOS 7, if it hasn't been fetched directly from EPEL yet.
UPD: Ubuntu affected 18.04 and 18.10, an update has been released for them. Versions 16.04 and 19.04 are not affected, unless custom variants have been installed. More details .
The problem described there is currently being actively exploited (likely by a bot), I've noticed infections on some of my servers that were running 4.91.
Further reading is only relevant for those who have already been 'hit' — you either need to move everything to a clean VPS with fresh software or find a solution. Shall we try? Write if anyone can combat this malware.
If you, as an Exim user, are reading this and have still not updated (not confirmed the presence of version 4.92 or a patched version), please stop and go update.
For those already infected — let's continue...
UPD: and gives sound advice:
There can be a multitude of malware types. Running the wrong remedy and cleaning the queue will not heal the user, and they may not even realize what they need to treat.
Infection can be noticed as follows: [kthrotlds] overloads the CPU; on a weak VDS at 100%, on weaker servers it’s noticeable but less severe.
After infection, the malware deletes entries in cron, adding only itself to run every 4 minutes, while making the crontab file immutable. Crontab -e cannot save changes, throwing an error.
The immutable flag can be removed like this, after which the command line can be deleted (1.5kb):
chattr -i /var/spool/cron/root
crontab -e Then, in the crontab editor (vim), we delete the line and save it:dd
:wq
Avšak niektorý z aktívnych procesov to znovu prepisuje, rozoberám sa.
Medzitým visí hromada aktívnych wget’ov (alebo curl’ov) na adresy zo inštalačného skriptu (pozri nižšie), zatiaľ ich takto zhadzujem, ale znovu sa spúšťajú:
ps aux | grep wge[t]
ps aux | grep cur[l]
echo "Zastavujem..."
kill -9 `ps aux | grep wge[t] | awk '{print $2}'`
kill -9 `ps aux | grep cur[l] | awk '{print $2}'`
Inštalačný skript trójskeho koňa som našiel tu (centos): /usr/local/bin/nptd… nezverejňujem pre bezpečnosť, ale ak je niekto infikovaný a rozumie shell skriptom, prosím, venujte tomu pozornosť.
Doplním, akonáhle budem mať nové informácie.
UPD 1: Zmazanie súborov (s predchádzajúcim chattr -i) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root nepomohlo, rovnako ako zastavenie služby — musel som krontab úplne odstrániť (prerobiť bin-súbor).
UPD 2: Inštalačný skript trójskeho koňa sa niekedy nachádzal aj na iných miestach, pomohol hľadanie podľa veľkosti:
find / -size 19825c
UPD 3: Pozor! Okrem vypnutia selinuxu trójan tiež pridáva svoj SSH kľúč do ${sshdir}/authorized_keys! A aktivuje nasledujúce polia v /etc/ssh/sshd_config, ak ešte neboli zapísané ako YES:
PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes
echo UsePAM yes
PasswordAuthentication yes
UPD 4: Na základe súčasných informácií: vypíname exim, cron (s právami superužívateľa), okamžite odstraňujeme trójske kľúč zo ssh a upravujeme konfiguračný súbor sshd, reštartujeme sshd! A aj to zatiaľ nie je isté, či to pomôže, ale bez toho je to naozaj zlé.
Dôležité informácie z komentárov o patchoch/aktualizáciách som presunul na začiatok poznámky, aby tí, ktorí ju čítajú, začínali odtiaľ.
UPD 5: že malware zmenil heslá vo WordPresse.
UPD 6: , testujeme! Po reštartovaní alebo vypnutí lieku sa zdá, že zmizne, ale zatiaľ aspoň takto.
Kto vypracuje (alebo nájde) stabilné riešenie, prosím, napíšte, mnohým pomôžete.
UPD 7: píše:
Ak ešte nebolo povedané, vírus sa obnovuje vďaka neodoslanému emailu v exim, pri pokuse o opätovné odoslanie e-mailu sa znovu obnovuje, pozrite sa do /var/spool/exim4
Celú radu exim môžete vyčistiť takto:
exipick -i | xargs exim -Mrm
Kontrola počtu záznamov v rade:
exim -bpc
UPD 8: Znovu : FirstVDS ponúkli svoju verziu skriptu na liečenie, poďme testovať!
UPD 9: Zdá sa, že pracuje, ďakujem za skript!
Hlavné je nezabudnúť, že server už bol skompromitovaný a útočníci mohli nastoliť aj iné netypické nepríjemnosti (nie uvedené v droppery).
Preto je lepšie presťahovať sa na čisto nainštalovaný server (vds), alebo aspoň pokračovať v sledovaní témy — ak sa objaví niečo nové, píšte sem do komentárov, pretože jasne nie všetci budú presúvať na novú inštaláciu…
UPD 10: Ešte raz ďakujem : pripomína, že sa infikujú nielen servery, ale aj Raspberry Pi, a rôzne virtuálne stroje… Takže po záchrane serverov nezabudnite zachrániť svoje herné konzoly, roboty atď.
UPD 11: Od dôležité upozornenie pre 'ručne liečiacich':
(po použití tejto alebo inej metódy boja s týmto malwarem)
reštartovať sa určite treba — malware sedí niekde v otvorených procesoch a v súlade s tým aj v pamäti, a zapisuje sa znova do cronu každých 30 sekúnd
UPD 12: u seba v poradí exim iného(?) malware a odporúča najprv preskúmať konkrétne svoj problém pred začatím liečby.
UPD 13: skôr presunúť na čistý systém a súbory prenášať veľmi opatrne, pretože malware je už verejne dostupný a môžu ho používať iní, menej zjavnými a nebezpečnejšími spôsobmi.
UPD 14: upokojujúc seba tým, že rozumní ľudia z roota nespúšťajú — ďalšia :
Aj keď to nefunguje z roota, dochádza k hacku… Mám na OrangePi nainštalovaný debian jessie UPD: stretch, exim beží od Debian-exim a aj tak došlo k hacku, vymazal cron a ďalšie.
UPD 15: pri presune na čistý server zo skompromitovaného nezabúdajte na hygienu, :
Pri prenose dát dávajte pozor nielen na spustiteľné alebo konfiguračné súbory, ale aj na všetko, čo môže obsahovať škodlivé príkazy (napríklad v MySQL to môže byť CREATE TRIGGER alebo CREATE EVENT). Tiež nezabudnite na .html, .js, .php, .py a iné verejné súbory (ideálne by tieto súbory, ako aj ďalšie dáta, mali byť obnovené z lokálneho alebo iného dôveryhodného úložiska).
UPD 16: a : v systéme bola jedna verzia exim, ale v skutočnosti sa vykonávala iná.
Takže všetci po aktualizácii by ste sa mali uistiť že používate skutočne novú verziu!
exim --versionK konkrétnej situácii sme sa spoločne dostali.
Na serveri bol použitý DirectAdmin a bol tam jeho starý balík da_exim (staršej verzie, bez zraniteľnosti).
Pomocou správy balíkov DirectAdmin custombuild bola nainštalovaná novšia verzia eximu, ktorá už obsahuje zraniteľnosť.
V tejto konkrétnej situácii tiež pomohlo aktualizovanie cez custombuild.
Nezabúdajte robiť zálohy pred takými experimentmi a uistite sa, že všetky procesy staršej verzie exim sú pred/po aktualizácii a nezostali "zaseknuté" v pamäti.
Zdroj: habr.com
