Kolleger, der bruger Exim version 4.87...4.91 på deres mailservere - opdater hurtigst muligt til version 4.92, efter først at have stoppet Exim selv for at undgå hacking gennem CVE-2019-10149.
Flere millioner servere rundt om i verden er potentielt sårbare, sårbarheden vurderes som kritisk (CVSS 3.0 basisscore = 9.8/10). Angribere kan køre vilkårlige kommandoer på din server, i mange tilfælde fra root.
Sørg for, at du bruger en fast version (4.92) eller en, der allerede er blevet rettet.
Eller patch den eksisterende, se tråden
Opdatering til centos 6: cm.
UPD: Ubuntu er påvirket 18.04 og 18.10, er der udgivet en opdatering til dem. Versioner 16.04 og 19.04 påvirkes ikke, medmindre brugerdefinerede optioner er installeret på dem. Flere detaljer
Nu bliver problemet beskrevet der aktivt udnyttet (formentlig af en bot), jeg bemærkede en infektion på nogle servere (kører på 4.91).
Yderligere læsning er kun relevant for dem, der allerede har "fået det" - du skal enten transportere alt til en ren VPS med frisk software eller lede efter en løsning. Skal vi prøve? Skriv hvis nogen kan overvinde denne malware.
Hvis du, som Exim-bruger og læser dette, stadig ikke har opdateret (ikke har sikret dig, at 4.92 eller en patchet version er tilgængelig), skal du stoppe og køre for at opdatere.
For dem, der allerede er nået dertil, lad os fortsætte...
UPS:
Der kan være et stort udvalg af malware. Ved at lancere medicinen for det forkerte og rydde køen, bliver brugeren ikke helbredt og ved måske ikke, hvad han skal behandles for.
Infektionen er mærkbar sådan: [kthrotlds] indlæser processoren; på en svag VDS er den 100%, på servere er den svagere men mærkbar.
Efter infektion sletter malwaren cron-indgange og registrerer kun sig selv der for at køre hvert 4. minut, mens crontab-filen bliver uforanderlig. Crontab -e kan ikke gemme ændringer, giver en fejl.
Immutable kan fjernes, for eksempel sådan her, og derefter slette kommandolinjen (1.5 kb):
chattr -i /var/spool/cron/root
crontab -e
Derefter skal du i crontab-editoren (vim) slette linjen og gemme:dd
:wq
Nogle af de aktive processer overskriver dog igen, det er jeg ved at finde ud af.
På samme tid hænger der en masse aktive wgets (eller krøller) på adresserne fra installationsscriptet (se nedenfor), jeg slår dem ned på denne måde for nu, men de starter igen:
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 fandt det trojanske installationsscript her (centos): /usr/local/bin/nptd... Jeg poster det ikke for at undgå det, men hvis nogen er inficeret og forstår shell-scripts, bedes du studere det mere omhyggeligt.
Jeg tilføjer efterhånden som oplysningerne er opdateret.
UPD 1: Sletning af filer (med foreløbig chattr -i) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root hjalp ikke, og det hjalp heller ikke at stoppe tjenesten - jeg var nødt til at crontab helt for nu riv den ud (omdøb bin-filen).
UPD 2: Det trojanske installationsprogram lå nogle gange også rundt andre steder, søgning efter størrelse hjalp:
find / -str. 19825c
UPD 3/XNUMX/XNUMX: Advarsel! Ud over at deaktivere selinux, tilføjer trojaneren også sin egen SSH nøgle i ${sshdir}/authorized_keys! Og aktiverer følgende felter i /etc/ssh/sshd_config, hvis de ikke allerede er sat til JA:
PermitRootLogin ja
RSAA-godkendelse ja
PubkeyAuthentication ja
echo UsePAM ja
PasswordAuthentication ja
UPD 4: For at opsummere i øjeblikket: deaktiver Exim, cron (med rødder), fjern omgående den trojanske nøgle fra ssh og rediger sshd-konfigurationen, genstart sshd! Og det er endnu ikke klart, at dette vil hjælpe, men uden det er der et problem.
Jeg flyttede vigtig information fra kommentarerne om patches/opdateringer til begyndelsen af noten, så læserne starter med den.
UPD 5/XNUMX/XNUMX:
UPD 6/XNUMX/XNUMX:
Enhver der laver (eller finder) en stabil løsning, så skriv venligst, du vil hjælpe mange.
UPD 7/XNUMX/XNUMX:
Hvis du ikke allerede har sagt, at virussen genopstår takket være et usendt brev i Exim, når du forsøger at sende brevet igen, er det gendannet, kig i /var/spool/exim4
Du kan rydde hele Exim-køen sådan her:
exipick -i | xargs exim -Mrm
Kontrol af antallet af poster i køen:
exim -bpc
UPD 8: Igen
UPD 9: Det ser ud til værker, tak
Det vigtigste er ikke at glemme, at serveren allerede var kompromitteret, og angriberne kunne have formået at plante nogle mere atypiske grimme ting (ikke anført i dropperen).
Derfor er det bedre at flytte til en komplet installeret server (vds), eller i det mindste fortsætte med at overvåge emnet – hvis der er nyt, så skriv i kommentarfeltet her, for åbenbart ikke alle vil flytte til en ny installation...
UPD 10: Tak igen
UPD 11: Fra
(efter at have brugt en eller anden metode til at bekæmpe denne malware)
Du skal helt sikkert genstarte - malwaren sidder et sted i åbne processer og følgelig i hukommelsen og skriver sig selv en ny til cron hvert 30. sekund
UPD 12/XNUMX/XNUMX:
UPD 13/XNUMX/XNUMX:
UPD 14: at forsikre os selv om, at smarte mennesker ikke løber fra roden - en ting mere
Selvom det ikke virker fra root, sker der hacking... Jeg har debian jessie UPD: stræk på min OrangePi, Exim kører fra Debian-exim og der skete stadig hacking, mistede kroner osv.
UPD 15: når du flytter til en ren server fra en kompromitteret server, så glem ikke hygiejnen,
Når du overfører data, skal du ikke kun være opmærksom på eksekverbare filer eller konfigurationsfiler, men også på alt, der kan indeholde ondsindede kommandoer (f.eks. i MySQL kunne dette være CREATE TRIGGER eller CREATE EVENT). Glem heller ikke .html, .js, .php, .py og andre offentlige filer (ideelt set bør disse filer, ligesom andre data, gendannes fra lokalt eller andet pålideligt lager).
UPD 16/XNUMX/XNUMX:
Så alle sammen efter opdateringen skal du sørge for at du bruger den nye version!
exim --version
Vi ordnede deres specifikke situation sammen.
Serveren brugte DirectAdmin og dens gamle da_exim-pakke (gammel version, uden sårbarhed).
Samtidig blev der ved hjælp af DirectAdmins custombuild-pakkemanager faktisk så installeret en nyere version af Exim, som allerede var sårbar.
I denne særlige situation hjalp opdatering via custombuild også.
Glem ikke at lave sikkerhedskopier før sådanne eksperimenter, og sørg også for, at alle Exim-processer før/efter opdateringen er af den gamle version
Kilde: www.habr.com