Työtoverit, jotka käyttävät Exim-versioita 4.87...4.91 sähköpostipalvelimillaan - päivitä kiireesti versioon 4.92, koska he ovat aiemmin pysäyttäneet itse Eximin CVE-2019-10149:n hakkeroinnin välttämiseksi.
Useat miljoonat palvelimet ympäri maailmaa ovat mahdollisesti haavoittuvia, haavoittuvuus luokitellaan kriittiseksi (CVSS 3.0:n peruspisteet = 9.8/10). Hyökkääjät voivat suorittaa mielivaltaisia komentoja palvelimellasi, monissa tapauksissa pääkäyttäjältä.
Varmista, että käytät kiinteää versiota (4.92) tai sellaista, joka on jo korjattu.
Tai korjaa olemassa oleva, katso säiettä .
Päivitys kohteelle CentOS 6: cm. - Centos 7:lle se toimii myös, jos se ei ole vielä saapunut suoraan epelistä.
UPD: Ubuntu vaikuttaa 18.04 ja 18.10, heille on julkaistu päivitys. Tämä ei vaikuta versioihin 16.04 ja 19.04, ellei niihin ole asennettu mukautettuja lisävarusteita. Lisätietoja .
Nyt siellä kuvattua ongelmaa hyödynnetään aktiivisesti (oletettavasti botin toimesta), huomasin tartunnan joissakin palvelimissa (ajoissa 4.91).
Lisälukeminen on merkityksellistä vain niille, jotka ovat jo "saaneet sen" - sinun on joko kuljetettava kaikki puhtaalle VPS:lle tuoreella ohjelmistolla tai etsittävä ratkaisu. Yritetäänkö? Kirjoita jos joku voi voittaa tämän haittaohjelman.
Jos olet Exim-käyttäjä ja luet tätä, et ole vieläkään päivittänyt (et ole varmistanut, että 4.92 tai korjattu versio on saatavilla), lopeta ja suorita päivitys.
Niille, jotka ovat jo päässeet sinne, jatketaan...
UPD: ja antaa oikean neuvon:
Haittaohjelmia voi olla monenlaisia. Lääke lanseeraamalla väärään asiaan ja tyhjentämällä jonon käyttäjä ei parane eikä välttämättä tiedä, mistä hän tarvitsee hoitoa.
Tartunta on havaittavissa seuraavasti: [kthrotlds] lataa prosessorin; heikolla VDS:llä se on 100%, palvelimilla se on heikompi, mutta havaittavissa.
Tartunnan jälkeen haittaohjelma poistaa cron-merkinnät ja rekisteröi vain itsensä siellä suoritettavaksi 4 minuutin välein ja tekee crontab-tiedostosta muuttumattoman. Crontab -e ei voi tallentaa muutoksia, antaa virheilmoituksen.
Immutable voidaan poistaa esimerkiksi näin ja poistaa sitten komentorivi (1.5 kt):
chattr -i /var/spool/cron/root
crontab -e
Poista seuraavaksi rivi crontab-editorissa (vim) ja tallenna:dd
:wq
Jotkut aktiivisista prosesseista kuitenkin korvaavat jälleen, olen selvittänyt sen.
Samaan aikaan asennusohjelman osoitteissa roikkuu joukko aktiivisia wgetejä (tai curl-tiedostoja) (katso alla), kaadun ne toistaiseksi näin, mutta ne alkavat taas:
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}'`
Löysin troijalaisen asennusohjelman täältä (centos): /usr/local/bin/nptd... En julkaise sitä välttääkseni sitä, mutta jos joku on saanut tartunnan ja ymmärtää shell-skriptit, tutki sitä tarkemmin.
Lisään sitä mukaa kun tiedot päivittyvät.
UPD 1: Tiedostojen poistaminen (alkuperäisellä chattr -i -komennolla) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root ei auttanut, eikä palvelun pysäyttäminen - minun piti crontab toistaiseksi revi se kokonaan pois (nimeä bin-tiedosto uudelleen).
UPD 2: Troijalainen asennusohjelma makasi joskus myös muissa paikoissa, koon mukaan haku auttoi:
löytää / -koko 19825c
UPD3: Varoitus! Selinuxin poistamisen lisäksi troijalainen lisää myös omansa SSH-avain kohteessa ${sshdir}/authorized_keys! Ja aktivoi seuraavat kentät tiedostossa /etc/ssh/sshd_config, jos niille ei ole jo asetettu YES:
PermitRootLogin kyllä
RSAA-todennus kyllä
PubkeyAuthentication kyllä
echo UsePAM kyllä
Salasanan todennus kyllä
UPD 4: Yhteenvetona toistaiseksi: poista Exim, cron (juuret), poista Troijan avain kiireesti ssh:sta ja muokkaa sshd-asetusta, käynnistä sshd uudelleen! Ja ei ole vielä selvää, auttaako tämä, mutta ilman sitä on ongelma.
Siirsin tärkeät tiedot korjauspäivityksiä koskevista kommenteista muistiinpanon alkuun, jotta lukijat aloittavat siitä.
UPD5: että haittaohjelma vaihtoi salasanat WordPressissä.
UPD6: , testataan! Uudelleenkäynnistyksen tai sammutuksen jälkeen lääke näyttää katoavan, mutta ainakin toistaiseksi se on siinä.
Jokainen, joka tekee (tai löytää) vakaan ratkaisun, kirjoita, autat monia.
UPD7: kirjoittaa:
Jos et ole jo sanonut, että virus on herännyt henkiin Eximissä lähettämättömän kirjeen ansiosta, kun yrität lähettää kirjeen uudelleen, se palautuu, katso hakemistosta /var/spool/exim4
Voit tyhjentää koko Exim-jonon seuraavasti:
exipick -i | xargs exim -Mrm
Jonon merkintöjen määrän tarkistaminen:
exim -bpc
UPD 8: Jälleen : FirstVDS tarjosi oman versionsa hoitoskriptistä, testataan!
UPD 9: Näyttää siltä työt, Kiitos käsikirjoituksen vuoksi!
Tärkeintä ei ole unohtaa, että palvelin oli jo vaarantunut ja hyökkääjät olisivat onnistuneet istuttamaan epätyypillisempiä ilkeitä asioita (ei listattu dropperissa).
Siksi on parempi siirtyä kokonaan asennetulle palvelimelle (vds) tai ainakin jatkaa aiheen seurantaa - jos on jotain uutta, kirjoita tänne kommentteihin, koska kaikki eivät tietenkään siirry uuteen asennukseen...
UPD 10: Kiitos vielä kerran : se muistuttaa, että palvelimet eivät ole saastuneet, vaan myös Raspberry Pi, ja kaikenlaisia virtuaalikoneita... Muista siis tallentaa palvelimet, videokonsolit, robotit jne.
UPD 11: Alkaen Tärkeä huomautus manuaalisille parantajille:
(kun olet käyttänyt yhtä tai toista menetelmää tämän haittaohjelman torjuntaan)
Sinun on ehdottomasti käynnistettävä uudelleen - haittaohjelma istuu jossain avoimissa prosesseissa ja vastaavasti muistissa ja kirjoittaa itselleen uuden croniksi 30 sekunnin välein
UPD12: Eximillä on jonossa toinen(?) haittaohjelma, ja se neuvoo tutkimaan omaa ongelmaasi ennen hoidon aloittamista.
UPD13: sen sijaan siirry puhtaaseen järjestelmään ja siirrä tiedostoja erittäin huolellisesti, koska Haittaohjelma on jo julkisesti saatavilla ja sitä voidaan käyttää muilla, vähemmän ilmeisillä ja vaarallisemmilla tavoilla.
UPD 14: vakuuttaa itsellemme, että älykkäät ihmiset eivät juokse juurista – vielä yksi asia :
Vaikka se ei toimi root-päästä, tapahtuu hakkerointia... Minulla on debian jessie UPD: venytä OrangePi:ssäni, Exim on käynnissä Debian-eximistä ja silti tapahtui hakkerointia, kadonneita kruunuja jne.
UPD 15: kun siirryt puhtaalle palvelimelle vaarantuneelta palvelimelta, älä unohda hygieniaa, :
Kun siirrät tietoja, kiinnitä huomiota suoritettavien tai asetustiedostojen lisäksi kaikkeen, joka saattaa sisältää haitallisia komentoja (esimerkiksi MySQL:ssä tämä voi olla CREATE TRIGGER tai CREATE EVENT). Älä myöskään unohda .html-, .js-, .php-, .py- ja muita julkisia tiedostoja (ihannetapauksessa nämä tiedostot, kuten muut tiedot, pitäisi palauttaa paikallisesta tai muusta luotetusta tallennustilasta).
UPD16: и : järjestelmässä oli yksi Exim-versio asennettuna portteihin, mutta todellisuudessa se käytti toista.
Kaikki siis päivityksen jälkeen kannattaa varmistaa että käytät uutta versiota!
exim --versionSelvitimme heidän erityistilanteensa yhdessä.
Palvelin käytti DirectAdminia ja sen vanhaa da_exim-pakettia (vanha versio, ilman haavoittuvuutta).
Samanaikaisesti DirectAdminin custombuild-pakettienhallinnan avulla itse asiassa asennettiin Eximin uudempi versio, joka oli jo haavoittuvainen.
Tässä tilanteessa auttoi myös päivittäminen custombuildin kautta.
Älä unohda tehdä varmuuskopioita ennen tällaisia kokeiluja ja varmista myös, että ennen/jälkeen päivitystä kaikki Exim-prosessit ovat vanhaa versiota. eikä "jäänyt" muistiin.
Lähde: will.com