Kolleger, der bruger Exim versioner 4.87…4.91 på deres mailservere — opdater venligst til version 4.92, efter at have stoppet Exim for at undgå hacking via CVE-2019-10149.
Potentielt sårbare er millioner af servere verden over, sårbarheden vurderes som kritisk (CVSS 3.0 base score = 9.8/10). Angribere kan køre vilkårlige kommandoer på din server, ofte med root-adgang.
Sørg venligst for, at du bruger den rettede version (4.92) eller en allerede patcheret version.
Eller patch din nuværende, se tråden .
Opdatering til centos 6: se. — det virker også for centos 7, hvis det endnu ikke er blevet sendt direkte fra epel.
UPD: Ubuntu er berørt 18.04 og 18.10, opdatering til dem er udgivet. Versioner 16.04 og 19.04 er ikke berørt, medmindre der er installeret tilpassede versioner på dem. Læs mere .
Den beskrevne problematik bliver i øjeblikket aktivt udnyttet (af en bot, kan det antages), jeg har bemærket inficering på nogle af mine servere (der kørte på 4.91).
Herefter er det kun relevant at læse for dem, der allerede er "ramt" — enten skal alting flyttes til en ren VPS med ny software, eller så skal der findes en løsning. Skal vi prøve? Skriv, hvis nogen kan bekæmpe denne malware.
Hvis du, som bruger af Exim, læser dette og stadig ikke har opdateret (ikke har sikret dig, at version 4.92 er til stede eller at du har en patcheret version), så stop og skynd dig at opdatere.
For dem, der allerede er ramt — lad os fortsætte…
OPD: og giver det gode råd:
Der kan være mange varianter af skadelig software. Hvis brugeren kører et program, der ikke er korrekt, og rydder køen, vil de hverken blive renset eller muligvis forstå, hvad de skal behandles for.
Inficering er synlig ved: [kthrotlds] belaster CPU'en; på en svag VDS 100%, på svagere servere, men mærkbart.
Efter inficering sletter den skadelige software poster i cron, og kun sig selv tilføjes til at køre hvert 4. minut, samtidig med at crontab-filen gøres immutable. Crontab -e kan ikke gemme ændringer, giver en fejl.
Immutable kan fjernes for eksempel sådan, hvorefter man kan slette kommandoens linje (1.5 KB):
chattr -i /var/spool/cron/root
crontab -e Derefter i crontab-editoren (vim) sletter vi linjen og gemmer:dd
:wq
Men en af de aktive processer overskriver det igen, jeg undersøger det.
Der er mange aktive wget'er (eller curl'er), der kører mod adresser fra installationsscriptet (se nedenfor). Jeg stopper dem midlertidigt, 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}'`
Trojan-installer-scriptet blev fundet her (centos): /usr/local/bin/nptd… jeg offentliggør det ikke for at undgå problemer, men hvis nogen er inficeret og forstår shell-scripts, så undersøg det venligst nærmere.
Jeg vil opdatere, når jeg får ny information.
UPD 1: Slet af filer (med forudgående chattr -i) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root hjalp ikke, ligesom at stoppe tjenesten — jeg måtte fjerne crontab helt (omdøbe bin-filen).
UPD 2: Trojan-installer blev også nogen gange fundet andre steder, en søgning efter størrelse hjalp:
find / -size 19825c
UPD 3: Opmærksomhed! Udover at deaktivere selinux, tilføjer trojaneren også sin SSH-nøgle til ${sshdir}/authorized_keys! Og aktiverer følgende felter i /etc/ssh/sshd_config, hvis de ikke allerede var sat til YES:
PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes
echo UsePAM yes
, gem ændringerne og genstart Ubuntu 20.04.
UPD 4: For at opsummere indtil videre: deaktiver exim, cron (med root-adgang), fjern straks trojanens nøgle fra ssh og rediger sshd-konfigurationen, genstart sshd! Og det er stadig usikkert, om dette hjælper, men uden det er det virkelig slemt.
Vigtig information fra kommentarerne om patches/opdateringer er fremhævet i begyndelsen af notatet, så læsere kan starte her.
UPD 5: at malware har ændret adgange i WordPress.
UPD 6: , vi tester! Efter genstart eller deaktivering ser det ud til, at det falder fra hinanden, men indtil videre er det bedre end intet.
Hvis nogen finder eller laver en stabil løsning, så skriv venligst, det vil hjælpe mange.
UPD 7: skriver:
Hvis det ikke allerede er nævnt, bliver viraet genoplivet takket være en uafsendt e-mail i exim. Ved gentagelse af forsøget på at sende e-mailen genoprettes det, tjek i /var/spool/exim4
Man kan rydde hele exim-køen sådan her:
exipick -i | xargs exim -Mrm
Kontroller antallet af poster i køen:
exim -bpc
UPD 8: Igen : FirstVDS tilbød deres version af scriptet til reparation, lad os teste det!
UPD 9: Det virker som virker, tak en script!
Husk at serveren allerede er blevet kompromitteret, og angribere kunne have haft tid til at indsætte andre atypiske skadelige programmer (ikke registreret i dropperen).
Derfor er det bedre at flytte til en nyinstalleret server (vds), eller i det mindste fortsætte med at følge emnet — hvis der kommer noget nyt, skriv kommentarer her, for det er klart, at ikke alle vil flytte til en frisk installation…
UPD 10: Endnu engang tak : det minder om, at ikke kun servere bliver inficeret, men for eksempel også Raspberry Pi, og forskellige virtuelle maskiner… Så glem ikke at redde dine medieafspillere, robotter osv. efter at have reddet serverne.
UPD 11: Fra vigtig bemærkning til dem, der "helbreder manuelt":
(efter anvendelsen af en eller anden form for bekæmpelse af denne skadelig software)
skal genstarten helt klar — malware sidder et sted i åbne processer og dermed i hukommelsen, og skriver sig selv i cron igen hver 30. sekund
UPD 12: hos sig i køen exim en anden(?) skadelig software og anbefaler først at studere specifikt sin egen problemstilling, før behandling påbegyndes.
UPD 13: hellere at flytte til et rent system, og overføre filer med ekstrem forsigtighed, fordi malware allerede er offentligt tilgængelig og kan bruges af andre, mindre åbenlyse og mere farlige metoder.
UPD 14: beroligelse til sig selv ved at sige, at kloge mennesker ikke kører som root — endnu en :
Selv hvis det ikke kører som root, sker der en hack… Jeg har en OrangePi med debian jessie UPD: stretch, exim kører fra Debian-exim og der skete stadig en hack, cronen og andet blev slettet.
UPD 15: når du flytter til en ren server fra en kompromitteret, glem ikke hygiejnen, :
Når du overfører data, skal du være opmærksom ikke kun på eksekverbare eller konfigurationsfiler, men også alt, der kan indeholde skadelige kommandoer (for eksempel kan det i MySQL 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, genskabes fra et lokalt eller andet betroet lager).
UPD 16: og : i systemet var der en version af exim på portene, men i virkeligheden blev en anden kørt.
Så sørg for, at alle efter opdatering kontrollere, at du bruger den nye version!
exim --versionVi fandt sammen ud af deres situation.
På serveren blev der brugt DirectAdmin, og den gamle pakke da_exim (gammel version, uden sårbarhed) var installeret.
Med DirectAdmins pakkeadministrator custombuild blev der installeret en nyere version af exim, som desværre er sårbar.
I denne situation hjalp det også at opdatere via custombuild.
Husk at lave backups inden sådanne eksperimenter, og sørg for at alle processer for den gamle version af exim og ikke 'hang' i hukommelsen.
Kilde: habr.com
