Kollegas wat Exim-weergawes 4.87...4.91 op hul e-posbedieners gebruik - werk dringend op na weergawe 4.92, nadat hulle eers Exim self gestop het om inbraak deur CVE-2019-10149 te vermy.
Verskeie miljoen bedieners regoor die wêreld is potensieel kwesbaar, die kwesbaarheid word as krities gegradeer (CVSS 3.0 basistelling = 9.8/10). Aanvallers kan arbitrêre opdragte op jou bediener uitvoer, in baie gevalle vanaf root.
Maak asseblief seker dat jy 'n vaste weergawe (4.92) gebruik of een wat reeds reggemaak is.
Of pleister die bestaande een, sien draad
Opdatering vir 6: cm.
UPD: Ubuntu word geraak 18.04 en 18.10, 'n opdatering is vir hulle vrygestel. Weergawes 16.04 en 19.04 word nie geraak nie, tensy persoonlike opsies daarop geïnstalleer is. Meer besonderhede
Nou word die probleem wat daar beskryf word, aktief uitgebuit (vermoedelik deur 'n bot), ek het 'n infeksie op sommige bedieners opgemerk (wat op 4.91 loop).
Verdere leeswerk is slegs relevant vir diegene wat dit reeds "gekry" het - jy moet óf alles na 'n skoon VPS vervoer met vars sagteware, óf na 'n oplossing soek. Sal ons probeer? Skryf of iemand hierdie wanware kan oorkom.
As jy, as jy 'n Exim-gebruiker is en dit lees, steeds nie opgedateer het nie (nie seker gemaak het dat 4.92 of 'n reggemaakte weergawe beskikbaar is nie), stop asseblief en hardloop om op te dateer.
Vir diegene wat reeds daar aangekom het, kom ons gaan voort...
UPS:
Daar kan 'n groot verskeidenheid wanware wees. Deur die medisyne vir die verkeerde ding bekend te stel en die tou skoon te maak, sal die gebruiker nie genees word nie en dalk nie weet waarvoor hy behandel moet word nie.
Die infeksie is so merkbaar: [kthrotlds] laai die verwerker; op 'n swak VDS is dit 100%, op bedieners is dit swakker maar opvallend.
Na infeksie vee die wanware cron-inskrywings uit, en registreer net homself daar om elke 4 minute te hardloop, terwyl die crontab-lêer onveranderlik gemaak word. Crontab -e kan nie veranderinge stoor nie, gee 'n fout.
Onveranderlike kan byvoorbeeld so verwyder word en dan die opdragreël (1.5kb) uitvee:
chattr -i /var/spool/cron/root
crontab -e
Vee dan die reël uit in die crontab-redigeerder (vim) en stoor:dd
:wq
Sommige van die aktiewe prosesse oorskryf egter weer, ek is besig om dit uit te vind.
Terselfdertyd is daar 'n klomp aktiewe wgets (of krulle) wat op die adresse van die installeerder script hang (sien hieronder), ek slaan hulle vir eers so af, maar hulle begin weer:
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}'`
Ek het die Trojaanse installeerder script hier gevind (centos): /usr/local/bin/nptd... Ek plaas dit nie om dit te vermy nie, maar as iemand besmet is en dop skrifte verstaan, bestudeer dit asseblief noukeuriger.
Ek sal byvoeg soos inligting opgedateer word.
UPD 1: Die verwydering van lêers (met voorlopige chattr -i) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root het nie gehelp nie, en ook nie om die diens te stop nie - ek moes crontab heeltemal vir nou skeur dit uit (hernoem die bin lêer).
UPD 2: Die Trojaanse installeerder het soms ook op ander plekke rondgelê, soek volgens grootte het gehelp:
vind / -grootte 19825c
UPD 3/XNUMX/XNUMX: Внимание! Benewens die deaktivering van selinux, voeg die Trojaan ook sy eie by SSH sleutel in ${sshdir}/authorized_keys! En aktiveer die volgende velde in /etc/ssh/sshd_config, as hulle nie reeds op JA gestel is nie:
PermitRootLogin ja
RSAA-verifikasie ja
Pubkey Verifikasie ja
eggo UsePAM ja
Wagwoordverifikasie ja
UPD 4: Om vir eers op te som: deaktiveer Exim, cron (met wortels), verwyder dringend die Trojaanse sleutel van ssh en wysig die sshd-konfigurasie, herbegin sshd! En dit is nog nie duidelik dat dit sal help nie, maar daarsonder is daar 'n probleem.
Ek het belangrike inligting van die opmerkings oor pleisters/opdaterings na die begin van die nota geskuif, sodat lesers daarmee begin.
UPD 5/XNUMX/XNUMX:
UPD 6/XNUMX/XNUMX:
Enigiemand wat 'n stabiele oplossing maak (of vind), skryf asseblief, jy sal baie help.
UPD 7/XNUMX/XNUMX:
As jy nog nie gesê het dat die virus opgewek is danksy 'n ongestuurde brief in Exim nie, wanneer jy probeer om die brief weer te stuur, is dit herstel, kyk in /var/spool/exim4
Jy kan die hele Exim-waglys soos volg uitvee:
exipick -i | xargs exim -Mnr
Kontroleer die aantal inskrywings in die tou:
exim -bpc
UPD 8: Weereens
UPD 9: Dit lyk soos werk, dankie
Die belangrikste ding is om nie te vergeet dat die bediener reeds gekompromitteer is nie en die aanvallers kon daarin geslaag het om 'n paar meer atipiese nare dinge te plant (nie in die drupper gelys nie).
Daarom is dit beter om na 'n volledig geïnstalleerde bediener (vds) te skuif, of ten minste voort te gaan om die onderwerp te monitor - as daar iets nuuts is, skryf in die kommentaar hier, want natuurlik sal nie almal na 'n nuwe installasie oorgaan nie ...
UPD 10: Weereens dankie
UPD 11: Van
(nadat jy een of ander metode gebruik het om hierdie wanware te bestry)
Jy moet beslis herselflaai - die wanware sit iewers in oop prosesse en dienooreenkomstig in die geheue, en skryf vir homself 'n nuwe een om elke 30 sekondes te kroon
UPD 12/XNUMX/XNUMX:
UPD 13/XNUMX/XNUMX:
UPD 14: om onsself te verseker dat slim mense nie van die wortel af hardloop nie - nog een ding
Selfs al werk dit nie van root af nie, vind inbraak plaas... Ek het debian jessie UPD: strek op my OrangePi, Exim loop van Debian-exim af en steeds het inbraak gebeur, krone verloor, ens.
UPD 15: wanneer jy na 'n skoon bediener beweeg vanaf 'n gekompromitteerde een, moenie van higiëne vergeet nie,
Wanneer u data oordra, let nie net op uitvoerbare of konfigurasielêers nie, maar ook aan enigiets wat kwaadwillige opdragte kan bevat (byvoorbeeld, in MySQL kan dit CREATE TRIGGER of CREATE EVENT wees). Moet ook nie van .html, .js, .php, .py en ander publieke lêers vergeet nie (ideaal gesproke moet hierdie lêers, soos ander data, vanaf plaaslike of ander vertroude berging herstel word).
UPD 16/XNUMX/XNUMX:
So almal na die opdatering moet jy seker maak dat jy die nuwe weergawe gebruik!
exim --version
Ons het hul spesifieke situasie saam uitgesorteer.
Die bediener het DirectAdmin en sy ou da_exim-pakket gebruik (ou weergawe, sonder kwesbaarheid).
Terselfdertyd, met behulp van DirectAdmin se pasgemaakte pakketbestuurder, is in werklikheid 'n nuwer weergawe van Exim geïnstalleer, wat reeds kwesbaar was.
In hierdie spesifieke situasie het opdatering via pasgemaakte ook gehelp.
Moenie vergeet om rugsteun te maak voor sulke eksperimente nie, en maak ook seker dat voor/na die opdatering alle Exim-prosesse van die ou weergawe is
Bron: will.com