Azok a kollégák, akik az Exim 4.87...4.91-es verzióit használják levelezőszervereiken – sürgősen frissítsenek a 4.92-es verzióra, miután először magát az Exim-et leállították a CVE-2019-10149 feltörésének elkerülése érdekében.
Világszerte több millió szerver potenciálisan sebezhető, a sérülékenység kritikusnak minősül (CVSS 3.0 alappontszám = 9.8/10). A támadók tetszőleges parancsokat futtathatnak a szerveren, sok esetben a root-ból.
Kérjük, győződjön meg arról, hogy javított (4.92) vagy már javított verziót használ.
Vagy javítsa meg a meglévőt, lásd a szálat .
Frissítés ehhez cent 6: cm. - centos 7-hez is működik, ha még nem érkezett meg közvetlenül az epeltől.
UPD: Az Ubuntu érintett 18.04 és 18.10, frissítést adtak ki számukra. A 16.04-es és 19.04-es verziókat ez nem érinti, kivéve, ha egyedi opciókat telepítettek rájuk. További részletek .
Most az ott leírt problémát aktívan kihasználják (feltehetően egy bot), fertőzést észleltem néhány szerveren (4.91-en fut).
A további olvasmányok csak azok számára relevánsak, akik már „megszerették” - vagy mindent egy tiszta VPS-re kell szállítani friss szoftverrel, vagy megoldást kell keresni. Megpróbáljuk? Írjon, ha valaki le tudja győzni ezt a kártevőt.
Ha Ön, mint Exim felhasználó, és ezt olvassa, még mindig nem frissített (nem győződjön meg arról, hogy elérhető-e a 4.92 vagy javított verzió), kérjük, álljon meg, és futtassa a frissítést.
Akik már eljutottak, folytassuk...
UPS: és ad megfelelő tanácsot:
Nagyon sokféle rosszindulatú program lehet. Ha rossz dolog miatt indítják el a gyógyszert, és törlik a sorban állást, a felhasználó nem gyógyul meg, és nem biztos, hogy tudja, mi miatt kell kezelni.
A fertőzés így észrevehető: [kthrotlds] betölti a processzort; gyenge VDS-en 100%, szervereken gyengébb, de észrevehető.
A fertőzés után a kártevő törli a cron bejegyzéseket, és csak magát regisztrálja ott, hogy 4 percenként futhasson, miközben a crontab fájlt megváltoztathatatlanná teszi. Crontab -e nem tudja menteni a változtatásokat, hibát jelez.
Az immutable eltávolítható például így, majd törölje a parancssort (1.5 kb):
chattr -i /var/spool/cron/root
crontab -e
Ezután a crontab szerkesztőben (vim) törölje a sort, és mentse:dd
:wq
Az aktív folyamatok egy része azonban megint felülír, kitalálom.
Ugyanakkor egy rakás aktív wget (vagy curl) lóg a címeken a telepítő szkriptből (lásd lent), ezeket egyelőre így lekopogom, de újraindulnak:
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ő szkriptjét itt találtam (centos): /usr/local/bin/nptd... Nem azért teszem közzé, hogy elkerüljem, de ha valaki fertőzött és érti a shell szkripteket, kérem tanulmányozza át alaposabban.
Hozzáteszem, amint frissül az információ.
UPD 1: A fájlok törlése (előzetes chattr -i paranccsal) /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 – muszáj volt crontab egyelőre teljesen tépd ki (nevezd át a bin fájlt).
UPD 2: A trójai telepítő néha más helyeken is hevert, a méret szerinti keresés segített:
megtalál / -méret 19825c
UPD3: Figyelem! A selinux letiltása mellett a trójai sajátjait is hozzáadja SSH kulcs itt: ${sshdir}/authorized_keys! És aktiválja a következő mezőket az /etc/ssh/sshd_config fájlban, ha még nem a YES értékre lettek állítva:
PermitRootLogin igen
RSAA-hitelesítés igen
PubkeyAuthentication igen
echo UsePAM igen
Jelszóhitelesítés igen
UPD 4: Összefoglalva egyelőre: tiltsa le az Exim-et, cront (gyökerekkel), sürgősen távolítsa el a trójai kulcsot az ssh-ból és szerkessze az sshd konfigurációt, indítsa újra az sshd-t! És még nem világos, hogy ez segíteni fog, de enélkül probléma van.
A javításokkal/frissítésekkel kapcsolatos megjegyzések közül a fontos információkat áthelyeztem a jegyzet elejére, hogy az olvasók ezzel kezdjék.
UPD5: hogy a kártevő megváltoztatta a jelszavakat a WordPressben.
UPD6: , teszteljük! Újraindítás vagy leállítás után úgy tűnik, hogy a gyógyszer eltűnik, de most legalább ennyi.
Aki csinál (vagy talál) stabil megoldást írjon, sokaknak segít.
UPD7: írja:
Ha még nem mondtad, hogy a vírus feltámadt egy el nem küldött levélnek köszönhetően az Eximben, amikor újra megpróbálod elküldeni a levelet, az visszaáll, nézd meg a /var/spool/exim4 mappában.
A teljes Exim-sort így törölheti:
exipick -i | xargs exim -Mrm
A sorban lévő bejegyzések számának ellenőrzése:
exim -bpc
UPD 8: Megint : A FirstVDS felajánlotta a kezelési szkript saját verzióját, teszteljük!
UPD 9: Úgy néz ki művek, Kösz a forgatókönyvért!
A lényeg az, hogy ne felejtsük el, hogy a szerver már kompromittálódott, és a támadóknak sikerült volna néhány atipikusabb csúnya dolgot beültetniük (a dropperben nem szerepel).
Ezért érdemes egy teljesen telepített szerverre (vds) áttérni, vagy legalább továbbra is figyelni a témát – ha van valami újdonság, írjátok meg ide kommentben, mert nyilván nem mindenki költözik új telepítésre...
UPD 10: Még egyszer köszönöm : emlékeztet arra, hogy nem csak a szerverek fertőzöttek, hanem Raspberry Pi, és mindenféle virtuális gépek... Szóval a szerverek mentése után ne felejtsd el menteni a videókonzolokat, robotokat stb.
UPD 11: Kezdő Fontos megjegyzés manuális gyógyítók számára:
(miután egy vagy másik módszert használtak a kártevő elleni küzdelemben)
Mindenképpen újra kell indítania - a rosszindulatú program valahol a nyitott folyamatokban és ennek megfelelően a memóriában található, és 30 másodpercenként ír magának egy újat, hogy cron
UPD12: Az Exim egy másik(?) rosszindulatú program is van a sorban, és azt tanácsolja, hogy a kezelés megkezdése előtt tanulmányozza át a konkrét problémát.
UPD13: inkább térjen át egy tiszta rendszerre, és rendkívül óvatosan vigye át a fájlokat, mert A rosszindulatú program már nyilvánosan elérhető, és más, kevésbé nyilvánvaló és veszélyesebb módokon is használható.
UPD 14: megnyugtatni magunkat, hogy az okos emberek nem a gyökérből futnak – még egy dolog :
Még ha nem is működik root-ból, feltörés történik... Debian jessie UPD-m van: nyúlj az OrangePi-m, az Exim Debian-eximről fut és még mindig történt feltörés, elveszett koronák stb.
UPD 15: amikor egy feltört szerverről tiszta szerverre költözik, ne feledkezzen meg a higiéniáról, :
Adatátvitelkor ne csak a végrehajtható vagy konfigurációs fájlokra figyeljen, hanem mindenre, ami rosszindulatú parancsokat tartalmazhat (például a MySQL-ben ez lehet CREATE TRIGGER vagy CREATE EVENT). Ne feledkezzünk meg a .html, .js, .php, .py és más nyilvános fájlokról sem (ideális esetben ezeket a fájlokat, más adatokhoz hasonlóan, helyi vagy más megbízható tárhelyről kell visszaállítani).
UPD16: и : a rendszer az Exim egyik verzióját telepítette a portokra, de valójában egy másikat futtatott.
Szóval mindenki a frissítés után meg kell győződnie arról hogy az új verziót használja!
exim --versionEgyütt rendeztük a konkrét helyzetüket.
A szerver a DirectAdmint és annak régi da_exim csomagját használta (régi verzió, sebezhetőség nélkül).
Ugyanakkor a DirectAdmin custombuild csomagkezelőjének segítségével valójában ekkor került az Exim újabb verziója, amely már sérülékeny volt.
Ebben a konkrét helyzetben a custombuild segítségével történő frissítés is segített.
Ne felejtsen el biztonsági másolatot készíteni az ilyen kísérletek előtt, és győződjön meg arról is, hogy a frissítés előtt/után minden Exim folyamat a régi verzióból áll. és nem „ragadt” az emlékezetben.
Forrás: will.com