Colegi, cine folosește servere de email Exim versiunile 4.87…4.91 — actualizați urgent la versiunea 4.92, oprind mai întâi Exim pentru a evita o posibilă compromitere prin CVE-2019-10149.
Pot fi vulnerabile mai multe milioane de servere din întreaga lume, vulnerabilitatea fiind evaluată ca critică (CVSS 3.0 base score = 9.8/10). Atacatorii pot executa comenzi arbitrare pe serverul vostru, în multe cazuri cu permisiuni de root.
Vă rog să vă asigurați că folosiți versiunea corectată (4.92) sau una deja patchuită.
Sau patchuiți versiunea existentă, vedeți firul .
Actualizarea pentru centos 6: vezi. — pentru centos 7 funcționează de asemenea, dacă nu a venit direct din EPEL.
UPD: Ubuntu este afectat 18.04 și 18.10, actualizarea pentru ele a fost lansată. Versiunile 16.04 și 19.04 nu sunt afectate, cu excepția cazului în care au fost instalate variante personalizate. Mai multe detalii .
Problema descrisă acolo este exploatată activ (presupun că de un bot), am observat la mine pe unele servere (care rulau pe 4.91) infecții.
Mai departe, acest conținut este relevant doar pentru cei care au fost deja "infectați" — trebuie să mutați totul pe o VPS curată cu software nou, sau să căutați o soluție. Încercăm? Scrieți, dacă cineva poate să combată acest malware.
Dacă sunteți utilizator Exim și citiți asta, dar nu ați actualizat încă (nu v-ați asigurat că aveți versiunea 4.92 sau o versiune patchuită), vă rog să vă opriți și să vă actualizați imediat.
Pentru cei care au fost deja afectați — să continuăm...
UPD: și oferă un sfat corect:
Există o mulțime de malware. Rulând un program care nu este destinat acestuia și curățând coada, utilizatorul nu va fi vindecat și probabil nu va ști ce ar trebui să trateze.
Infecția se observă astfel: [kthrotlds] încarcă procesorul; pe un VDS slab până la 100%, pe servere mai slabe, vizibil.
După infectare, malware-ul șterge înregistrările din cron, lăsându-se doar pe sine să ruleze la fiecare 4 minute, în același timp face fișierul crontab immutable. Crontab -e nu poate salva modificările, aruncând o eroare.
Puteți elimina imutabilitatea astfel, după care ștergeți linia comenzii (1.5kb):
chattr -i /var/spool/cron/root
crontab -e Apoi, în editorul crontab (vim), ștergem linia și salvăm:dd
:wq
Totuși, un proces activ rescrie din nou, investighez.
În același timp, există o mulțime de wget-uri (sau curl-uri) active pe adresele din scriptul de instalare (vezi mai jos), le opresc temporar, dar se relansează imediat:
ps aux | grep wge[t]
ps aux | grep cur[l]
echo "Oprire..."
kill -9 `ps aux | grep wge[t] | awk '{print $2}'`
kill -9 `ps aux | grep cur[l] | awk '{print $2}'`
Scriptul de instalare a troianului a fost găsit aici (centos): /usr/local/bin/nptd… nu-l public pentru a evita probleme, dar dacă cineva este infectat și se pricepe la scripturi shell, vă rog să-l studiați cu atenție.
Voi completa pe măsură ce voi actualiza informațiile.
UPD 1: Ștergerea fișierelor (după un chattr -i preliminar) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root nu a ajutat, la fel și oprirea serviciului — a fost necesar să șterg complet crontab-ul (să redenumesc fișierul bin).
UPD 2: Instalatorul troianului se găsea uneori și în alte locuri, am găsit folosind dimensiunea:
find / -size 19825c
UPD 3: Atenție! Pe lângă dezactivarea SELinux, troianul adaugă propriul său cheie SSH în ${sshdir}/authorized_keys! Și activează următoarele câmpuri în /etc/ssh/sshd_config, dacă nu au fost deja specificate ca YES:
PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes
echo UsePAM yes
PasswordAuthentication yes
UPD 4: Rezumând până în acest moment: dezactivăm exim, cron (cu privilegii de root), eliminăm urgent cheia troianului din ssh și corectăm configurația sshd, repornim sshd! Și, deocamdată, nu este clar dacă asta va ajuta, dar fără aceasta este cu adevărat grav.
Am extras informații importante din comentarii despre patch-uri/actualizări la începutul notei, astfel încât cititorii care o citesc să înceapă de acolo.
UPD 5: că malware-ul a schimbat parolele în WordPress.
UPD 6: , testăm! După reboot sau dezactivarea medicamentului, pare că dispare, dar până atunci funcționează.
Cine va implementa (sau va găsi) o soluție stabilă, vă rog, scrieți, veți ajuta mult.
UPD 7: scrie:
Dacă nu s-a mai spus, virusul revine datorită unei scrisori neexpediate în exim; la o nouă încercare de a trimite scrisoarea, acesta se restabilește, verificați în /var/spool/exim4.
Toată coada de exim poate fi golită astfel:
exipick -i | xargs exim -Mrm
Verificarea numărului de înregistrări din coadă:
exim -bpc
UPD 8: Din nou : FirstVDS a propus propria versiune a scriptului pentru tratament, haideți să testăm!
UPD 9: Se pare că lucrează, mulțumesc pentru script!
Cel mai important, nu uitați că serverul a fost deja compromis iar atacatorii ar fi putut introduce și alte probleme neobișnuite (neapărute în dropper).
De aceea, este mai bine să migrați pe un server proaspăt instalat (vds), sau cel puțin să continuați să urmăriți subiectul — dacă apare ceva nou, scrieți în comentarii aici, deoarece nu toată lumea va migra pe o instalare nouă...
UPD 10: Î încă o dată, mulțumesc : acesta amintește că nu doar serverele se infectează, ci și, de exemplu, Raspberry Pi, și diverse mașini virtuale... Așa că, după salvarea serverelor, nu uitați să salvați consolele de joc, roboții etc.
UPD 11: De la observație importantă pentru cei care „tratamente manuale”:
(după aplicarea uneia sau altei metode de combatere a acestui rău)
trebuie neapărat să reporniți — malware-ul se ascunde undeva în procesele deschise și, prin urmare, în memorie, și se recopiază în cron la fiecare 30 de secunde
UPD 12: în coada sa alte (?) malware și sfătuiește să studieze mai întâi problema specifică, înainte de a începe tratamentul.
UPD 13: să migreze mai degrabă pe un sistem curat, și să transfere fișierele cu mare prudență, deoarece malware-ul este deja accesibil publicului și poate fi utilizat de alții în moduri mai puțin evidente și mai periculoase.
UPD 14: liniștindu-se cu gândul că, fiind oameni înțelepți, nu rulează ca root — un alt :
Chiar și când nu se lucrează ca root, se poate întâmpla o compromitere... Am avut pe OrangePi Debian Jessie UPD: Stretch, exim rula de la Debian-exim și tot a avut loc o compromitere, cronul și alte lucruri au fost șterse.
UPD 15: când migrați pe un server curat dintr-unul compromis, nu uitați de igienă, :
Când transferați date, acordați atenție nu doar fișierelor executabile sau de configurare, ci și tot ce ar putea conține comenzi dăunătoare (de exemplu, în MySQL, acestea pot fi CREATE TRIGGER sau CREATE EVENT). De asemenea, nu uitați de fișierele .html, .js, .php, .py și alte fișiere publice (ideal, aceste fișiere, la fel ca alte date, ar trebui să fie recuperate dintr-un mediu local sau dintr-un alt loc de încredere).
UPD 16: și : în sistem, pe porturi se afla o versiune exim, iar în realitate rula alta.
Așadar, tuturor după actualizare, ar trebui să vă asigurați că folosiți exact noua versiune!
exim --versionSpecific, ne-am ajutat reciproc să ne clarificăm situația.
Pe server a fost folosit DirectAdmin și avea vechiul pachet da_exim (veche versiune, fără vulnerabilitate).
Prin această metodă, cu ajutorul managerului de pachete custombuild de la DirectAdmin, a fost instalată de fapt o versiune mai nouă a exim, care este deja vulnerabilă.
În această situație, actualizarea prin custombuild a fost de asemenea de ajutor.
Nu uitați să faceți copii de siguranță înainte de astfel de experimente și asigurați-vă că înainte/după actualizare toate procesele exim ale versiunii vechi și nu „s-au blocat” în memorie.
Sursa: habr.com
