Kollégák, akik az Exim 4.87…4.91 verzióit használják a levelező szervereiken – sürgősen frissítsenek a 4.92 verzióra, előtte azonban állítsák le az Eximet, hogy elkerüljék a CVE-2019-10149-en keresztüli behatolást.
Potenciálisan több millió szerver van kitéve a világ minden táján, a sebezhetőséget kritikusnak értékelik (CVSS 3.0 alap pontszám = 9.8/10). A támadók tetszőleges parancsokat futtathatnak a szerverén, sok esetben root jogosultsággal.
Kérjük, győződjön meg róla, hogy a javított verziót (4.92) használja, vagy már javított változattal rendelkezik.
Vagy patchelje a meglévőt, lásd a szálat .
Frissítés a centos 6: lásd. – centos 7-re is működik, ha az epel-ből közvetlenül még nem érkezett.
UPD: Az Ubuntuk érintettek 18.04 és 18.10, frissítés kiadásra került. A 16.04 és 19.04 verziók nem érintettek, kivéve ha egyedi változatokat telepítettek rájuk. További információ .
Jelenleg a leírt probléma aktívan kihasználásra kerül (valószínűleg bot által), észleltem néhány szerveremen (amik 4.91-en futottak) a fertőzés jeleit.
Tovább olvasni releváns csak azok számára, akik már »helyzetbe kerültek« – vagy át kellene költöztetni mindent egy tiszta VPS-re frissebb szoftverrel, vagy megoldást kell keresni. Próbáljuk meg? Írjon, ha valaki segíthet eltávolítani ezt a kártevőt.
Ha Ön Exim felhasználóként ezt olvasva még mindig nem frissült (nem győződött meg a 4.92 vagy javított verzió meglétéről), kérjük álljon meg és fussanak frissíteni.
A már érintetteknek – folytatjuk...
UPD: és helyes tanácsot ad:
A kártevőkből sokféle létezhet. Ha rossz gyógymódot futtatunk és megtisztítjuk a felhasználó sorát, az nem gyógyítja meg, és lehet, hogy észre sem veszi, hogy mivel kellene kezelnie.
A fertőzés a következőképpen észlelhető: [kthrotlds] terheli a processzort; egy gyenge VDS-en 100%-ig, gyengébb szervereken is észlelhető.
A fertőzés után a kártevő törli a cron bejegyzéseket, és csak saját magát írja be a 4 percenkénti indítással, miközben a crontab fájlt immutable-ra állítja. Crontab -e nem tudja menteni a változtatásokat, hibát ad.
Az immutable flag eltávolítható például így, ezután törölheti a parancssort (1.5kb):
chattr -i /var/spool/cron/root
crontab -e Ezután a crontab szerkesztőben (vim) eltávolítjuk a sort, és mentünk:dd
:wq
Azonban néhány aktív folyamat újra felülírja, most próbálkozom.
Közben sok aktív wget (vagy curl) fut a telepítő szkriptből származó címeken (lásd lentebb), jelenleg így állítom le őket, de újra elindulnak:
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}'`
A trójai telepítő szkript itt található (centos): \/usr\/local\/bin\/nptd… nem teszem közzé, hogy elkerüljem, de ha valaki meg van fertőzve és érti a shell szkripteket, kérem, nézze meg alaposabban.
Kiegészítem, amint friss információm lesz.
UPD 1: A fájlok törlése (először chattr -i használatával) \/etc\/cron.d\/root, \/etc\/crontab, rm -Rf \/var\/spool\/cron\/root nem segített, ahogy a szolgáltatás leállítása sem – végül teljesen ki kellett húznom a crontabot (a bin fájlt átnevezni).
UPD 2: A trójai telepítő néha más helyeken is megtalálható volt, a méret alapján történő keresés segített:
find \/ -size 19825c
UPD 3: Figyelem! A selinux letiltása mellett a trójai saját SSH-kulcsot hozzáad a ${sshdir}\/authorized_keys-hez! És aktiválja a következő mezőket \/etc\/ssh\/sshd_config fájlban, ha még nem lettek YES-ként bejegyezve:
PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes
echo UsePAM yes
PasswordAuthentication yes
UPD 4: Jelenleg összegezve: letiltjuk az exim-et, a cron-t (root-kal), sürgősen eltávolítjuk a trójai kulcsot az ssh-ból és javítjuk a sshd konfigurációt, újraindítjuk a sshd-t! És ezt sem biztos, hogy segít, de nélküle totális katasztrófa.
Fontos információkat a megjegyzésekből a javításokról/frissítésekről kiemeltem a jegyzet elejére, hogy akik arról olvasnak, azok ezzel kezdjék.
UPD 5: hogy a kártevő megváltoztatta a jelszavakat a WordPress-ben.
UPD 6: , teszteljük! Úgy tűnik, hogy újraindítás vagy a kezelés lekapcsolása után eltűnik, de legalább így működik.
Aki készít (vagy talál) stabil megoldást, kérem írjon, sokat segítene.
UPD 7: írja:
Ha még nem mondták, a vírus egy elküldetlen levél miatt tér vissza az exim-ben, a levél újbóli küldési próbálkozásával helyreáll.
Az exim teljes sorának törlése így lehetséges:
exipick -i | xargs exim -Mrm
A sorban lévő bejegyzések számának ellenőrzése:
exim -bpc
UPD 8: Ismét : A FirstVDS saját változatát ajánlotta a kezeléshez, nézzük meg, hogyan működik!
UPD 9: Úgy tűnik, hogy a űrlapokban., köszönöm a szkriptért!
A legfontosabb, hogy ne felejtsétek el, hogy a szerver már kompromittálva volt, és a rosszindulatú támadók esetleg még más típúsú kárt is beültettek (amelyek nincsenek leírva a droppereben).
Ezért jobb lenne átköltözni egy tisztán telepített szerverre (vds), vagy legalább folytatni a téma nyomon követését — ha új információ érkezik, írjatok ide a megjegyzésekbe, mert nyilvánvalóan nem mindenki fog átköltözni az új telepítésre...
UPD 10: Még egyszer köszönöm : emlékeztet arra, hogy nemcsak a szervereket támadják meg, hanem például Raspberry Pi, és mindenféle virtuális gépeket... Szóval, miután megmentetted a szervereket, ne felejtsd el megmenteni a játékkonzolokat, robotokat stb.
UPD 11: Től fontos megjegyzés a "kézi kezelőknek":
(valamelyik módszer alkalmazása után, amellyel harcolni próbálunk ezzel a kártevővel)
kötelmes újraindítani — a malware valahol az aktív folyamatokban lappang, tehát a memóriában, és újra beírja magát a cronba 30 másodpercenként
UPD 12: hogy a sorában van egy másik(?) kártevő az exim-ben, és azt tanácsolja, hogy először alaposan tanulmányozd a konkrét problémádat, mielőtt elkezded a kezelést.
UPD 13: jobb lenne átköltözni egy tiszta rendszerre, és a fájlokat nagyon óvatosan átkonvertálni, mivel a malware már nyilvánosan elérhető, és mások, kevésbé nyilvánvaló és veszélyes módon is felhasználhatják.
UPD 14: megnyugtatva magukat azzal, hogy az okos emberek nem indítanak rendszergazda alatt — még egy :
Akkor is, ha nem rendszergazda alatt fut, akkor is támadás érheti... Az OrangePi-n Debian Jessie van, UPD: Stretch, az exim Debian-exim alatt fut, és mégis történt egy támadás, eltüntette a cron-t és egyebeket.
UPD 15: tiszta szerverre való átköltözéskor a kompromittált rendszerből ne feledd a higiéniát, :
Az adatok áthelyezésekor ne csak a végrehajtható vagy konfigurációs fájlokra figyelj, hanem mindenre, ami tartalmazhat kártékony utasításokat (például a MySQL-ban lehet CREATE TRIGGER vagy CREATE EVENT). Ezenkívül ne feledd a .html, .js, .php, .py és más nyilvános fájlokat (ideálisan ezeket a fájlokat, mint a többi adatot, helyi vagy más megbízható tárolóból kellene helyreállítani).
UPD 16: és : a rendszerben az egyik exim verzió állt a portoknál, de valójában egy másik futott.
Tehát mindenkinek frissítés után érdemes megbizonyosodni hogy valóban az új verziót használod!
exim --versionKifejezetten az ő helyzetükkel közösen foglalkoztunk.
A szerveren a DirectAdmin volt használatban, és az ő régi da_exim csomagja (régi verzió, sebezhetőség nélkül) volt telepítve.
A DirectAdmin package manager custombuild was used to install a newer version of exim, which is already vulnerable.
In this specific situation, an update through custombuild was also helpful.
Don’t forget to make backups before such experiments, and ensure that all processes of the old version of exim were stopped before/after the update. and did not 'get stuck' in memory.
Forrás: habr.com
