Uppdatera snabbt exim till 4.92 — det pågår en aktiv infektion

Kollegor, som använder Exim-versioner 4.87…4.91 på sina e-postservrar - se till att uppdatera till version 4.92, efter att ha stoppat Exim för att förhindra intrång via CVE-2019-10149.

Flera miljoner servrar världen över kan vara sårbara, och sårbarheten bedöms som kritisk (CVSS 3.0-baserat poäng = 9.8/10). Angripare kan köra godtyckliga kommandon på din server, ofta som root.

Vänligen se till att du använder den korrigerade versionen (4.92) eller redan har installerat en patch.
Eller patcha din befintliga, se tråden kommentaren immaculate.

Uppdatering för centos 6: se. kommentaren Theodor — för centos 7 fungerar det också, om det inte har kommit direkt från epel.

UPD: Ubuntu berörs 18.04 och 18.10, uppdateringar för dem har släppts. Versioner 16.04 och 19.04 är inte drabbade, såvida inte anpassade varianter har installerats. Mer info på deras officiella webbplats.

Information om problemet på Opennet
Information på Exims webbplats

Problemet som beskrivs där utnyttjas aktivt just nu (av en bot, bör påpekas), jag har observerat infektion på några av mina servrar (som körde på 4.91).

Fortsättningen är endast relevant för dem som redan har "drabbats" - man måste antingen flytta allt till en ren VPS med färsk mjukvara, eller leta efter en lösning. Ska vi försöka? Skriv om någon kan bekämpa denna skadlig programvara.

Om du är en Exim-användare och fortfarande inte har uppdaterat (inte verifierat att du har 4.92 eller en patchad version), stopp och spring och uppdatera.

För dem som redan drabbats - vi fortsätter...

UPD: supersmile2009 hittade en annan variant av skadlig programvara och ger ett korrekt råd:

Det finns en enorm mängd skadlig programvara. Genom att köra ett medel som inte är avsett kan användaren varken rengöra sin kö eller förstå vad som behöver behandlas.

Infektionen märks så här: [kthrotlds] belastar processorn; på en svag VDS upp till 100%, på svagare servrar, men märkbart.

Efter infektion tar den skadliga programvaran bort poster från cron och registrerar endast sig själv för att köras var fjärde minut, medan den gör crontab-filen oföränderlig. Crontab -e kan inte spara ändringar, ger ett felmeddelande.

Oföränderlig kan tas bort på följande sätt, efter vilket kommandoraden kan tas bort (1.5kb):

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

Därefter, i crontab-redigeraren (vim), tar vi bort raden och sparar:dd
:wq

Men någon av de aktiva processerna skriver om det igen, jag undersöker.

Samtidigt finns det många aktiva wget:er (eller curl:ar) på adresserna från installationsskriptet (se nedan), jag stänger dem så här just nu, men de startar 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}'`

Trojanens installationsskript hittades här (centos): /usr/local/bin/nptd… jag publicerar det inte för att undvika problem, men om någon är infekterad och kan hantera shellscript, vänligen studera det noggrant.

Jag kommer att uppdatera detta efter hand.

UPD 1: Ta bort filer (med föregående chattr -i) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root hjälpte inte, likaså att stoppa tjänsten — jag var tvungen att radera hela crontab (döpa om bin-filen).

UPD 2: Trojanens installationsprogram låg ibland också på andra ställen, med hjälp av storleksökning:
find / -size 19825c

UPD 3: Varning! Förutom att stänga av selinux, lägger trojanen till sin SSH-nyckel i ${sshdir}/authorized_keys! Och aktiverar följande fält i /etc/ssh/sshd_config, om de inte redan har angivits som YES:
PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes
echo UsePAM yes
PasswordAuthentication yes

UPD 4: Sammanfattningsvis för tillfället: stäng av exim, cron (med rötter), ta snabbt bort trojanens nyckel från ssh och redigera sshd-configen, starta om sshd! Även om det inte är säkert att detta hjälper, men utan det är det verkligen dåligt.

Jag har lyft fram viktig information från kommentarerna om patchar/uppdateringar till början av anteckningen, så att de som läser den börjar där.

UPD 5: AnotherDenni skriver att malware ändrade lösenord i WordPress.

UPD 6: Paulmann har förberett en tillfällig lösning, vi testar! Efter omstart eller avstängning verkar det försvinna, men åtminstone så här.

Den som kan göra (eller hitta) en stabil lösning, vänligen hör av er, det skulle hjälpa många.

UPD 7: Användare clsv skriver:

Om det inte redan har sagts så återuppstår viruset tack vare ett oavskickat mail i exim, vid ett nytt försök att skicka mailet återställs det, kolla i /var/spool/exim4

För att tömma hela exim-kön kan du göra så här:
exipick -i | xargs exim -Mrm
Kontrollera antalet poster i kön:
exim -bpc

UPD 8: Återigen tack för informationen AnotherDenni: FirstVDS föreslog sin version av skriptet för behandling, låt oss testa!

UPD 9: Det verkar som att på att implementera protokollet ActivityPub., tack Kiril för skriptet!

Det viktigaste är att inte glömma att servern redan har blivit komprometterad och att angriparna kan ha lagt till andra ovanliga skadligheter (som inte anges i dropparen).

Därför är det bättre att flytta till en nyinstallerad server (vds), eller åtminstone fortsätta hålla koll på ämnet — om det dyker upp något nytt, skriv i kommentarerna här, eftersom uppenbarligen inte alla kommer att flytta till en ny installation…

UPD 10: Tack igen clsv: det påminner om att inte bara servrar smittas, utan till exempel även Raspberry Pi, och olika virtuella maskiner… Så efter att ha räddat servrarna, glöm inte att rädda dina mediaboxar, robotar och så vidare.

UPD 11: Från författaren av det helande skriptet viktig anteckning för de som "botar manuellt":
(efter att ha tillämpat en viss metod för att bekämpa detta skadliga program)

är det nödvändigt att starta om — skadlig programvara finns någonstans i öppna processer och, därmed, i minnet, och skriver om sig själv i cron var 30:e sekund

UPD 12: supersmile2009 har hittat ett annat(?) skadligt program i sin kö exim och rekommenderar att först studera sin specifika problematik innan behandling påbörjas.

UPD 13: lorc rekommenderar att snarast flytta till ett rent system, och flytta filer med extrem försiktighet, eftersom den skadliga programvaran redan är offentligt tillgänglig och kan användas av andra på mindre uppenbara och mer farliga sätt.

UPD 14: som lugnar sig med tanken på att smarta människor inte kör som root — ännu ett brådskande meddelande från clsv:

Även om det inte körs som root inträffar en hackning… Jag har Debian Jessie på OrangePi UPD: stretch, exim körs av Debian-exim och ändå inträffade hackningen, cron raderades och annat.

UPD 15: när du flyttar till en ren server från en komprometterad, kom ihåg hygienen, en användbar påminnelse från w0den:

Vid flytt av data, var uppmärksam inte bara på körbara eller konfigurationsfiler, utan även allt som kan innehålla skadliga kommandon (till exempel kan detta i MySQL vara CREATE TRIGGER eller CREATE EVENT). Glöm inte heller .html, .js, .php, .py och andra offentliga filer (idealiskt bör dessa filer, liksom andra data, återställas från lokal eller annan betrodd lagring).

UPD 16: daykkin och savage_me står inför ett annat problem: i systemet var en version av exim installerad, men i praktiken kördes en annan.

Så alla bör efter uppdateringen se till att ni verkligen använder den nya versionen!

exim --version

Tillsammans löste vi specifikt deras situation.

På servern användes DirectAdmin och dess gamla paket da_exim (gamla version, utan sårbarhet).

Med hjälp av DirectAdmin:s paketchefsverktyg custombuild installerades senare faktiskt en nyare version av exim, som redan är sårbar.

Specifikt i den här situationen hjälpte en uppdatering via custombuild också.

Glöm inte att göra säkerhetskopior innan sådana experiment, och se till att alla exim-processer från den gamla versionen har stoppats och inte har "fastnat" i minnet.

Källa: habr.com