Colegii care folosesc versiunile Exim 4.87...4.91 pe serverele lor de e-mail - se actualizează urgent la versiunea 4.92, care au oprit anterior Exim pentru a evita piratarea prin CVE-2019-10149.
Câteva milioane de servere din întreaga lume sunt potențial vulnerabile, vulnerabilitatea este evaluată drept critică (scor de bază CVSS 3.0 = 9.8/10). Atacatorii pot executa comenzi arbitrare pe serverul dvs., în multe cazuri de la root.
Vă rugăm să vă asigurați că utilizați o versiune fixă (4.92) sau una care a fost deja corectată.
Sau corectează-l pe cel existent, vezi firul .
Actualizare pentru cenți 6: cm. — pentru centos 7 funcționează și dacă nu a sosit încă direct de la epel.
UPD: Ubuntu este afectat 18.04 și 18.10, a fost lansată o actualizare pentru ei. Versiunile 16.04 și 19.04 nu sunt afectate decât dacă au fost instalate opțiuni personalizate pe ele. Mai multe detalii .
Acum problema descrisă acolo este exploatată activ (de un bot, probabil), am observat o infecție pe unele servere (care rulează pe 4.91).
Citirea ulterioară este relevantă numai pentru cei care au „obținut” deja - trebuie fie să transportați totul la un VPS curat cu software proaspăt, fie să căutați o soluție. Să încercăm? Scrieți dacă cineva poate depăși acest malware.
Dacă dumneavoastră, fiind utilizator Exim și citind acest lucru, încă nu v-ați actualizat (nu v-ați asigurat că este disponibilă 4.92 sau o versiune corectată), vă rugăm să opriți și să rulați pentru a actualiza.
Pentru cei care au ajuns deja acolo, să continuăm...
UPD: și oferă sfatul potrivit:
Poate exista o mare varietate de programe malware. Lansând medicamentul pentru un lucru greșit și curățând coada, utilizatorul nu se va vindeca și poate să nu știe pentru ce trebuie să fie tratat.
Infecția este vizibilă astfel: [kthrotlds] încarcă procesorul; pe un VDS slab este 100%, pe servere este mai slab, dar vizibil.
După infectare, malware-ul șterge intrările cron, înregistrându-se doar acolo pentru a rula la fiecare 4 minute, făcând în același timp imuabil fișierul crontab. Crontab -e nu poate salva modificările, dă o eroare.
Imuabilul poate fi eliminat, de exemplu, astfel, și apoi șterge linia de comandă (1.5 kb):
chattr -i /var/spool/cron/root
crontab -e
Apoi, în editorul crontab (vim), ștergeți linia și salvați:dd
:wq
Cu toate acestea, unele dintre procesele active se suprascriu din nou, îmi dau seama.
În același timp, există o grămadă de wgets (sau bucle) active agățate de adresele din scriptul de instalare (vezi mai jos), le dobor astfel deocamdată, dar încep din nou:
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}'`
Am găsit aici scriptul de instalare troian (centos): /usr/local/bin/nptd... Nu îl postez pentru a-l evita, dar dacă cineva este infectat și înțelege scripturile shell, vă rugăm să-l studiați cu mai multă atenție.
Voi adăuga pe măsură ce informațiile sunt actualizate.
UPD 1: Ștergerea fișierelor (cu chattr preliminar -i) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root nu a ajutat și nici oprirea serviciului - a trebuit să crontab complet deocamdată smulgeți-l (redenumiți fișierul bin).
UPD 2: Programul de instalare troian zăcea uneori și în alte locuri, căutarea după dimensiune a ajutat:
găsi / -mărimea 19825c
UPD3: Atenție! Pe lângă dezactivarea selinux, troianul își adaugă și 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 setate la YES:
PermitRootLogin da
Autentificare RSA da
PubkeyAuthentication da
echo UsePAM da
PasswordAuthentication da
UPD 4: Pentru a rezuma deocamdată: dezactivați Exim, cron (cu rădăcini), eliminați urgent cheia troiană din ssh și editați configurația sshd, reporniți sshd! Și încă nu este clar că acest lucru va ajuta, dar fără el există o problemă.
Am mutat informații importante din comentariile despre patch-uri/actualizări la începutul notei, astfel încât cititorii să înceapă cu ea.
UPD5: că malware-ul a schimbat parolele în WordPress.
UPD6: , hai să testăm! După o repornire sau oprire, medicamentul pare să dispară, dar deocamdată cel puțin asta este.
Oricine face (sau găsește) o soluție stabilă, vă rog să scrieți, îi veți ajuta pe mulți.
UPD7: scrie:
Dacă nu ați spus deja că virusul a reînviat datorită unei scrisori netrimise în Exim, atunci când încercați să trimiteți din nou scrisoarea, aceasta este restaurată, căutați în /var/spool/exim4
Puteți șterge întreaga coadă Exim astfel:
exipick -i | xargs exim -Mrm
Verificarea numărului de intrări în coadă:
exim -bpc
UPD 8: Din nou : FirstVDS a oferit versiunea lor a scriptului de tratament, haideți să-l testăm!
UPD 9: Se pare că fabrică, Mulțumiri pentru scenariu!
Principalul lucru este să nu uităm că serverul era deja compromis și atacatorii ar fi putut reuși să planteze niște lucruri mai urâte atipice (nu sunt enumerate în dropper).
Prin urmare, este mai bine să treceți la un server complet instalat (vds) sau cel puțin să continuați să monitorizați subiectul - dacă există ceva nou, scrieți în comentarii aici, deoarece evident, nu toată lumea se va muta la o nouă instalare...
UPD 10: Mulțumesc din nou : reamintește că nu numai serverele sunt infectate, ci și Raspberry Pi, și tot felul de mașini virtuale... Deci, după salvarea serverelor, nu uitați să vă salvați consolele video, roboții etc.
UPD 11: De la Notă importantă pentru vindecătorii manuali:
(după ce ați folosit una sau alta metodă de combatere a acestui malware)
Trebuie neapărat să reporniți - malware-ul se află undeva în procesele deschise și, în consecință, în memorie și își scrie unul nou pentru a crona la fiecare 30 de secunde
UPD12: Exim are un alt (?) malware în coadă și vă sfătuiește să vă studiați mai întâi problema specifică înainte de a începe tratamentul.
UPD13: mai degrabă, treceți la un sistem curat și transferați fișierele extrem de atent, deoarece Malware-ul este deja disponibil public și poate fi utilizat în alte moduri, mai puțin evidente și mai periculoase.
UPD 14: să ne asigurăm că oamenii inteligenți nu fug de la rădăcină - încă ceva :
Chiar dacă nu funcționează de la rădăcină, apare hacking... Am debian jessie UPD: stretch pe OrangePi meu, Exim rulează de la Debian-exim și tot s-a întâmplat hacking, pierderea coroanelor etc.
UPD 15: atunci când treceți pe un server curat de la unul compromis, nu uitați de igiena, :
Când transferați date, acordați atenție nu numai la fișierele executabile sau de configurare, ci și la orice ar putea conține comenzi rău intenționate (de exemplu, în MySQL, aceasta ar putea fi CREATE TRIGGER sau CREATE EVENT). De asemenea, nu uitați de .html, .js, .php, .py și alte fișiere publice (în mod ideal, aceste fișiere, ca și alte date, ar trebui restaurate din stocare locală sau de încredere).
UPD16: и : sistemul avea o versiune de Exim instalată în porturi, dar în realitate rula alta.
Deci toată lumea după actualizare ar trebui să vă asigurați că folosești noua versiune!
exim --versionAm rezolvat împreună situația lor specifică.
Serverul a folosit DirectAdmin și vechiul său pachet da_exim (versiunea veche, fără vulnerabilitate).
În același timp, cu ajutorul managerului de pachete personalizate de la DirectAdmin, de fapt, a fost apoi instalată o versiune mai nouă a Exim, care era deja vulnerabilă.
În această situație particulară, actualizarea prin custombuild a ajutat și el.
Nu uitați să faceți copii de siguranță înainte de astfel de experimente și, de asemenea, asigurați-vă că înainte/după actualizare toate procesele Exim sunt de versiunea veche și nu „blocat” în memorie.
Sursa: www.habr.com