Oppdater Exim snarest til 4.92 - det er en aktiv infeksjon

Kolleger som bruker Exim versjoner 4.87...4.91 på e-postserverne deres - oppdater snarest til versjon 4.92, etter å ha stoppet Exim selv for å unngå hacking gjennom CVE-2019-10149.

Flere millioner servere rundt om i verden er potensielt sårbare, sårbarheten er vurdert som kritisk (CVSS 3.0 base score = 9.8/10). Angripere kan kjøre vilkårlige kommandoer på serveren din, i mange tilfeller fra root.

Sørg for at du bruker en fast versjon (4.92) eller en som allerede er oppdatering.
Eller lapp den eksisterende, se tråden plettfri kommentar.

Oppdatering for CentOS 6: cm. kommentar av Theodor — for centos 7 fungerer det også, hvis det ikke har kommet direkte fra epel ennå.

UPD: Ubuntu er berørt 18.04 og 18.10, en oppdatering er gitt ut for dem. Versjon 16.04 og 19.04 påvirkes ikke med mindre tilpassede alternativer ble installert på dem. Mer informasjon på deres offisielle hjemmeside.

Informasjon om problemet på Opennet
Informasjon på nettsiden til Exim

Nå problemet beskrevet der blir aktivt utnyttet (av en bot, antagelig), jeg la merke til en infeksjon på noen servere (kjører på 4.91).

Videre lesing er bare relevant for de som allerede har "fått det" - du må enten transportere alt til en ren VPS med fersk programvare, eller se etter en løsning. Skal vi prøve? Skriv om noen kan overvinne denne skadelige programvaren.

Hvis du, som er Exim-bruker og leser dette, fortsatt ikke har oppdatert (ikke har forsikret deg om at 4.92 eller en oppdatert versjon er tilgjengelig), vennligst stopp og kjør for å oppdatere.

For de som allerede har kommet dit, la oss fortsette...

OPP: supersmile2009 fant en annen type skadelig programvare og gir riktige råd:

Det kan være et stort utvalg av skadelig programvare. Ved å lansere medisinen for feil ting og tømme køen vil ikke brukeren bli kurert og kanskje ikke vite hva han må behandles for.

Infeksjonen er merkbar slik: [kthrotlds] laster prosessoren; på en svak VDS er den 100 %, på servere er den svakere, men merkbar.

Etter infeksjon sletter skadelig programvare cron-oppføringer, og registrerer kun seg selv der for å kjøre hvert 4. minutt, samtidig som crontab-filen blir uforanderlig. Crontab -e kan ikke lagre endringer, gir en feilmelding.

Immutable kan fjernes, for eksempel slik, og deretter slette kommandolinjen (1.5 kb):

chattr -i /var/spool/cron/root
crontab -e

Deretter, i crontab-editoren (vim), slett linjen og lagre:dd
:wq

Noen av de aktive prosessene overskriver imidlertid igjen, jeg finner ut av det.

Samtidig er det en haug med aktive wgets (eller krøller) som henger på adressene fra installasjonsskriptet (se nedenfor), jeg slår dem ned slik for nå, men de starter på nytt:

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}'`

Jeg fant det trojanske installasjonsskriptet her (centos): /usr/local/bin/nptd... Jeg legger det ikke ut for å unngå det, men hvis noen er infisert og forstår skallskript, vennligst studer det mer nøye.

Jeg legger til etter hvert som informasjonen er oppdatert.

UPD 1: Sletting av filer (med foreløpig chattr -i) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root hjalp ikke, og det hjalp heller ikke å stoppe tjenesten - jeg måtte crontab fullstendig for nå riv den ut (gi nytt navn til bin-filen).

UPD 2: Det trojanske installasjonsprogrammet ble noen ganger også liggende andre steder, søk etter størrelse hjalp:
finn / -str. 19825c

UPD 3: Advarsel! I tillegg til å deaktivere selinux, legger trojaneren også til sin egen SSH-nøkkel i ${sshdir}/authorized_keys! Og aktiverer følgende felt i /etc/ssh/sshd_config, hvis de ikke allerede er satt til JA:
PermitRootLogin ja
RSAAautentisering ja
PubkeyAuthentication ja
echo UsePAM ja
PasswordAuthentication ja

UPD 4: For å oppsummere for nå: deaktiver Exim, cron (med røtter), fjern den trojanske nøkkelen fra ssh og rediger sshd-konfigurasjonen, start sshd på nytt! Og det er ennå ikke klart at dette vil hjelpe, men uten det er det et problem.

Jeg flyttet viktig informasjon fra kommentarene om patcher/oppdateringer til begynnelsen av notatet, slik at leserne starter med det.

UPD 5: En annen skriver Denny at skadevaren endret passord i WordPress.

UPD 6: Paulmann forberedte en midlertidig kur, la oss teste! Etter en omstart eller nedleggelse ser det ut til at medisinen forsvinner, men foreløpig er det i det minste det.

Alle som lager (eller finner) en stabil løsning, vennligst skriv, du vil hjelpe mange.

UPD 7: Bruker clsv skriver:

Hvis du ikke allerede har sagt at viruset gjenoppstår takket være et usendt brev i Exim, når du prøver å sende brevet på nytt, blir det gjenopprettet, se i /var/spool/exim4

Du kan tømme hele Exim-køen slik:
exipick -i | xargs exim -Mrm
Sjekke antall oppføringer i køen:
exim -bpc

UPD 8: Igjen takk for informasjonen AnotherDenny: FirstVDS tilbød sin versjon av behandlingsskriptet, la oss teste det!

UPD 9: Det ser ut som verker, Takk Kirill for manuset!

Det viktigste er ikke å glemme at serveren allerede var kompromittert og angriperne kunne ha klart å plante noen mer atypiske ekle ting (ikke oppført i dropperen).

Derfor er det bedre å flytte til en fullstendig installert server (vds), eller i det minste fortsette å overvåke emnet - hvis det er noe nytt, skriv i kommentarfeltet her, fordi åpenbart ikke alle vil flytte til en ny installasjon...

UPD 10: Takk igjen clsv: det minner om at ikke bare servere er infisert, men også Raspberry Pi, og alle slags virtuelle maskiner... Så etter å ha lagret serverne, ikke glem å lagre videokonsoller, roboter osv.

UPD 11: Fra forfatter av det helbredende manuset Viktig merknad for manuelle healere:
(etter å ha brukt en eller annen metode for å bekjempe denne skadelige programvaren)

Du må definitivt starte på nytt - skadelig programvare sitter et sted i åpne prosesser og følgelig i minnet, og skriver selv en ny for å cron hvert 30. sekund

UPD 12: supersmile2009 funnet Exim har en annen(?) skadelig programvare i køen og råder deg til først å studere det spesifikke problemet ditt før du starter behandlingen.

UPD 13: lorc råder heller, flytt til et rent system, og overfør filer ekstremt forsiktig, fordi Skadevaren er allerede offentlig tilgjengelig og kan brukes på andre, mindre åpenbare og farligere måter.

UPD 14: å forsikre oss om at smarte mennesker ikke løper fra roten - en ting til hastemelding fra clsv:

Selv om det ikke fungerer fra root, skjer det hacking... Jeg har debian jessie UPD: strekk på OrangePi, Exim kjører fra Debian-exim og fortsatt har hacking skjedd, tapte kroner osv.

UPD 15: når du flytter til en ren server fra en kompromittert server, ikke glem hygiene, nyttig påminnelse fra w0den:

Når du overfører data, vær oppmerksom ikke bare på kjørbare filer eller konfigurasjonsfiler, men også til alt som kan inneholde ondsinnede kommandoer (for eksempel i MySQL kan dette være CREATE TRIGGER eller CREATE EVENT). Ikke glem .html, .js, .php, .py og andre offentlige filer (ideelt sett bør disse filene, som andre data, gjenopprettes fra lokal eller annen pålitelig lagring).

UPD 16: daykkin и savage_me støtt på et annet problem: systemet hadde én versjon av Exim installert i portene, men i virkeligheten kjørte det en annen.

Så alle sammen etter oppdateringen bør du sørge for at du bruker den nye versjonen!

exim --version

Vi ordnet deres spesifikke situasjon sammen.

Serveren brukte DirectAdmin og dens gamle da_exim-pakke (gammel versjon, uten sårbarhet).

På samme tid, ved å bruke DirectAdmins custombuild-pakkebehandling, ble faktisk en nyere versjon av Exim installert, som allerede var sårbar.

I denne spesielle situasjonen hjalp oppdatering via custombuild også.

Ikke glem å ta sikkerhetskopier før slike eksperimenter, og sørg også for at alle Exim-prosesser før/etter oppdateringen er av den gamle versjonen ble stoppet og ikke "fast" i minnet.

Kilde: www.habr.com