Posta-zerbitzarietan Exim 4.87...4.91 bertsioak erabiltzen dituzten lankideek - premiazkoa eguneratzen dute 4.92 bertsiora, lehenik Exim bera geldituta CVE-2019-10149 bidez pirateatzea saihesteko.
Mundu osoko hainbat milioi zerbitzari potentzialki zaurgarriak dira, ahultasuna kritiko gisa baloratzen da (CVSS 3.0 oinarrizko puntuazioa = 9.8/10). Erasotzaileek komando arbitrarioak exekutatu ditzakete zure zerbitzarian, kasu askotan errotik.
Mesedez, ziurtatu bertsio finko bat (4.92) erabiltzen ari zarela edo dagoeneko adabakitutako bat.
Edo lehendik dagoena adabaki, ikusi haria .
Eguneratu ehunka 6: cm. β centos 7rako ere funtzionatzen du, oraindik epeletik zuzenean iritsi ez bada.
UPD: Ubuntu kaltetuta dago 18.04 eta 18.10, eguneraketa bat kaleratu zaie. 16.04 eta 19.04 bertsioek ez dute eraginik aukera pertsonalizatuak instalatu ez badira. Xehetasun gehiago .
Orain bertan deskribatutako arazoa aktiboki ustiatzen ari da (bot batek, ustez), infekzio bat nabaritu dut zerbitzari batzuetan (4.91-n exekutatzen ari dena).
Irakurketa gehiago dagoeneko "lortu" dutenentzat bakarrik da garrantzitsua - dena VPS garbi batera garraiatu behar duzu software berriarekin, edo irtenbide bat bilatu behar duzu. Saiatuko al gara? Idatzi norbaitek malware hau gaindi dezakeen.
Zuk, Exim erabiltzailea zarenez eta hau irakurtzen baduzu, oraindik eguneratu ez baduzu (ez baduzu ziurtatu 4.92 edo adabakitutako bertsio bat eskuragarri dagoenik), mesedez gelditu eta exekutatu eguneratzeko.
Dagoeneko iritsi direnentzat, jarrai dezagun...
UPS: eta aholku egokiak ematen ditu:
Malware askotariko bat egon daiteke. Okerreko sendagaia martxan jarriz eta ilara garbituz, erabiltzailea ez da sendatuko eta baliteke zertarako tratatu behar zaion ez jakitea.
Infekzioa honela nabaritzen da: [kthrotlds] prozesadorea kargatzen du; VDS ahul batean %100ean dago, zerbitzarietan ahulagoa baina nabaria da.
Infekzioaren ondoren, malwareak cron sarrerak ezabatzen ditu, bertan bakarrik erregistratuz 4 minuturo exekutatzeko, crontab fitxategia aldaezina egiten duen bitartean. Crontab -e ezin ditu aldaketak gorde, errore bat ematen du.
Aldaezina kendu daiteke, adibidez, honela, eta gero ezabatu komando-lerroa (1.5 kb):
chattr -i /var/spool/cron/root
crontab -e
Ondoren, crontab editorean (vim), ezabatu lerroa eta gorde:dd
:wq
Hala ere, prozesu aktibo batzuk berriro gainidazten ari dira, asmatzen ari naiz.
Aldi berean, wget (edo kizkur) aktibo mordoa daude instalatzailearen scripteko helbideetan zintzilik (ikus behean), oraingoz honela botatzen ari naiz, baina berriro hasten dira:
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}'`
Troiako instalatzailearen script-a hemen aurkitu dut (centos): /usr/local/bin/nptd... Ez dut argitaratzen saihesteko, baina inor kutsatuta badago eta shell scriptak ulertzen baditu, aztertu arretaz.
Informazioa eguneratzen den heinean gehituko dut.
UPD 1: Fitxategiak (aldez aurretiko chattr -i) ezabatzeak /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root ez zuen lagundu, ezta zerbitzua gelditzeak ere - egin behar izan nuen crontab guztiz erauzi ezazu (bin fitxategiari izena aldatu).
UPD 2: Troiako instalatzailea batzuetan beste leku batzuetan ere egon zen, tamainaren arabera bilaketak lagundu zuen:
aurkitu / -tamaina 19825c
3/XNUMX/XNUMXko eguneratua: Arreta! Selinux desgaitzeaz gain, troiarrak berea ere gehitzen du SSH gakoa ${sshdir}/authorized_keys-n! Eta eremu hauek aktibatzen ditu /etc/ssh/sshd_config-en, dagoeneko BAI moduan ezarri ez badira:
PermitRootLogin bai
RSAAuthentication bai
PubkeyAuthentication bai
echo Erabili PAM bai
Pasahitza autentifikazioa bai
UPD 4: Momentuz laburbiltzeko: desgaitu Exim, cron (erroekin), kendu urgentziaz Troiako gakoa ssh-tik eta editatu sshd konfigurazioa, berrabiarazi sshd! Eta oraindik ez dago argi honek lagunduko duenik, baina hori gabe arazo bat dago.
Informazio garrantzitsua adabaki/eguneratzeei buruzko iruzkinetatik oharren hasierara eraman nuen, irakurleak horrekin hasteko.
5/XNUMX/XNUMXko eguneratua: malwareak WordPress-en pasahitzak aldatu zituela.
6/XNUMX/XNUMXko eguneratua: , proba dezagun! Berrabiarazi edo itzali ondoren, sendagaia desagertzen dela dirudi, baina oraingoz behintzat hori da.
Irtenbide egonkor bat egiten (edo aurkitzen) duenak, idatzi mesedez, askori lagunduko diezu.
7/XNUMX/XNUMXko eguneratua: idazten du:
Exim-en bidali gabeko gutun bati esker birusa berpiztu dela esan ez baduzu, berriro gutuna bidaltzen saiatzen zarenean, leheneratu egiten da, begiratu /var/spool/exim4-n
Exim ilara osoa garbi dezakezu honela:
exipick -i | xargs exim -Mrm
Ilaran dauden sarrera kopurua egiaztatzea:
exim -bpc
UPD 8: Berriz ere : FirstVDS-k tratamenduaren gidoiaren bertsioa eskaini zuen, proba dezagun!
UPD 9: Badirudi obrak, eskerrik asko gidoiagatik!
Gauza nagusia ez da ahaztea zerbitzaria jada konprometituta zegoela eta erasotzaileek gauza gaizto atipikoago batzuk landatzea lortu zezaketela (tantaketan agertzen ez direnak).
Hori dela eta, hobe da guztiz instalatutako zerbitzari batera (vds) mugitzea edo, gutxienez, gaia kontrolatzen jarraitzea - ββezer berririk badago, idatzi iruzkinetan hemen, zeren Jakina denak ez dira instalazio berri batera mugituko...
UPD 10: Eskerrik asko berriro : zerbitzariak bakarrik kutsatuta daudela gogorarazten du, baita ere Raspberry Pi, eta era guztietako makina birtualak... Beraz, zerbitzariak gorde ondoren, ez ahaztu bideokontsolak, robotak, etab.
UPD 11: Noiztik Eskuzko sendatzaileentzako ohar garrantzitsua:
(malware honi aurre egiteko metodo bat edo beste erabili ondoren)
Zalantzarik gabe, berrabiarazi behar duzu - malwarea prozesu irekietan eta, ondorioz, memorian dago nonbait, eta bere burua berri bat idazten du 30 segundoro krosatzeko.
12/XNUMX/XNUMXko eguneratua: Exim-ek beste (?) malware bat dauka bere ilaran eta tratamendua hasi baino lehen zure arazo zehatza aztertzeko gomendatzen dizu.
13/XNUMX/XNUMXko eguneratua: aitzitik, sistema garbi batera mugitu eta fitxategiak oso kontu handiz transferitu, zeren Malwarea dagoeneko publikoki eskuragarri dago eta beste modu ez hain ageriko eta arriskutsuagoetan erabil daiteke.
UPD 14: pertsona adimentsuak ez direla errotik exekutatzen bermatzea - ββgauza bat gehiago :
Errotik funtzionatzen ez badu ere, hacking-a gertatzen da... Debian jessie UPD dut: nire OrangePi-n luzatu, Exim Debian-exim-etik exekutatzen ari da eta oraindik hacking-a gertatu da, koroak galdu, etab.
UPD 15: arriskutsutik zerbitzari garbi batera mugitzean, ez ahaztu higieneaz, :
Datuak transferitzean, erreparatu ez bakarrik exekutagarri edo konfigurazio fitxategiei, baita komando gaiztoak izan ditzakeen edozeri ere (adibidez, MySQL-n hau CREATE TRIGGER edo CREATE EVENT izan daiteke). Gainera, ez ahaztu .html, .js, .php, .py eta beste fitxategi publiko batzuez (egokiena, fitxategi hauek, beste datu batzuk bezala, tokiko biltegiratze lokal edo fidagarri batetik berrezarri behar dira).
16/XNUMX/XNUMXko eguneratua: ΠΈ : sistemak Exim-en bertsio bat zeukan instalatuta portuetan, baina errealitatean beste bat exekutatzen ari zen.
Beraz, denok eguneratu ondoren ziurtatu beharko zenuke bertsio berria erabiltzen ari zarela!
exim --versionHaien egoera zehatza elkarrekin zehaztu dugu.
Zerbitzariak DirectAdmin eta bere da_exim pakete zaharra erabiltzen zituen (bertsio zaharra, ahultasunik gabe).
Aldi berean, DirectAdmin-en custombuild paketeen kudeatzailearen laguntzarekin, hain zuzen ere, Exim-en bertsio berriagoa instalatu zen, jada zaurgarria zena.
Egoera zehatz honetan, custombuild bidez eguneratzeak ere lagundu zuen.
Ez ahaztu esperimentuen aurretik babeskopiak egitea, eta ziurtatu eguneratu aurretik/ondoren Exim prozesu guztiak bertsio zaharrekoak direla. eta ez memorian βtrabatutaβ.
Iturria: www.habr.com