Col·legues que utilitzen les versions 4.87...4.91 d'Exim als seus servidors de correu: s'actualitzen urgentment a la versió 4.92, havent aturat prèviament el mateix Exim per evitar la pirateria mitjançant CVE-2019-10149.
Diversos milions de servidors a tot el món són potencialment vulnerables, la vulnerabilitat es classifica com a crítica (puntuació base CVSS 3.0 = 9.8/10). Els atacants poden executar ordres arbitràries al vostre servidor, en molts casos des de l'arrel.
Si us plau, assegureu-vos que esteu utilitzant una versió fixa (4.92) o una que ja s'hagi pegat.
O pega l'existent, vegeu el fil .
Actualització per centenars 6: cm. — per centos 7 també funciona, si encara no ha arribat directament d'epel.
UPD: Ubuntu està afectat 18.04 i 18.10, s'ha publicat una actualització per a ells. Les versions 16.04 i 19.04 no es veuen afectades tret que s'hi instal·lin opcions personalitzades. Més detalls .
Ara el problema que s'hi descriu està sent explotat activament (per un bot, presumiblement), vaig notar una infecció en alguns servidors (que funciona amb la 4.91).
La lectura addicional només és rellevant per a aquells que ja ho han "aconseguit": cal transportar-ho tot a un VPS net amb programari nou o buscar una solució. Ho intentarem? Escriu si algú pot superar aquest programari maliciós.
Si vostè, sent usuari d'Exim i llegint això, encara no us heu actualitzat (no us heu assegurat que hi hagi disponible la 4.92 o una versió amb pedaços), atureu-vos i executeu l'actualització.
Per als que ja hi heu arribat, continuem...
ACTUALITZACIÓ: i dóna el consell adequat:
Hi pot haver una gran varietat de programari maliciós. En llançar el medicament per a la cosa equivocada i netejar la cua, l'usuari no es curarà i pot ser que no sàpiga per què ha de ser tractat.
La infecció es nota així: [kthrotlds] carrega el processador; en un VDS feble és al 100%, als servidors és més feble però es nota.
Després de la infecció, el programari maliciós elimina les entrades cron, registrant-se només allà per executar-se cada 4 minuts, alhora que fa que el fitxer crontab sigui immutable. Crontab -e no pot desar els canvis, dóna un error.
L'immutable es pot eliminar, per exemple, així, i després esborrar la línia d'ordres (1.5 kb):
chattr -i /var/spool/cron/root
crontab -e
A continuació, a l'editor crontab (vim), suprimiu la línia i deseu:dd
:wq
Tanmateix, alguns dels processos actius s'estan sobreescriure de nou, ho estic esbrinant.
Al mateix temps, hi ha un munt de wgets (o rínxols) actius penjats a les adreces de l'script d'instal·lació (vegeu més avall), de moment els estic derrocant així, però comencen de nou:
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}'`
He trobat l'script d'instal·lador de troià aquí (centos): /usr/local/bin/nptd... No el publico per evitar-ho, però si algú està infectat i entén els scripts d'intèrpret d'ordres, estudieu-lo amb més atenció.
Afegiré a mesura que s'actualitzi la informació.
UPD 1: L'eliminació de fitxers (amb xat preliminar -i) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root no va ajudar, ni tampoc aturar el servei; vaig haver de fer-ho crontab per ara esborra-lo completament (canviar el nom del fitxer bin).
UPD 2: l'instal·lador de troià de vegades també es trobava en altres llocs, la cerca per mida va ajudar:
trobar / -mida 19825c
Actualització 3/XNUMX/XNUMX: Atenció! A més de desactivar selinux, el troià també afegeix el seu Clau SSH a ${sshdir}/authorized_keys! I activa els camps següents a /etc/ssh/sshd_config, si encara no s'han establert en YES:
PermitRootLogin sí
Autenticació RSA sí
PubkeyAuthentication sí
echo UsePAM sí
Contrasenya d'autenticació sí
UPD 4: Per resumir de moment: desactiveu Exim, cron (amb arrels), elimineu urgentment la clau de Troia de ssh i editeu la configuració de sshd, reinicieu sshd! I encara no està clar que això ajudarà, però sense ell hi ha un problema.
Vaig traslladar informació important dels comentaris sobre pegats/actualitzacions al començament de la nota, perquè els lectors comencin amb ella.
Actualització 5/XNUMX/XNUMX: que el programari maliciós va canviar les contrasenyes a WordPress.
Actualització 6/XNUMX/XNUMX: , fem una prova! Després d'un reinici o apagat, el medicament sembla desaparèixer, però de moment almenys això és tot.
Qualsevol que faci (o trobi) una solució estable, si us plau, escrigui, ajudaràs a molts.
Actualització 7/XNUMX/XNUMX: escriu:
Si encara no heu dit que el virus ha ressuscitat gràcies a una carta no enviada a Exim, quan intenteu tornar a enviar la carta, es restaura, mireu a /var/spool/exim4
Podeu esborrar tota la cua d'Exim així:
exipick -i | xargs exim -Sr
Comprovació del nombre d'entrades a la cua:
exim -bpc
UPD 8: De nou : FirstVDS va oferir la seva versió de l'script de tractament, provem-ho!
UPD 9: Sembla obres, gràcies pel guió!
El més important és no oblidar que el servidor ja estava compromès i els atacants podrien haver aconseguit plantar algunes coses més desagradables atípiques (no figuren al comptegotes).
Per tant, és millor passar a un servidor completament instal·lat (vds), o almenys continuar supervisant el tema; si hi ha alguna cosa nova, escriviu aquí als comentaris, perquè òbviament no tothom passarà a una nova instal·lació...
UPD 10: Gràcies de nou : recorda que no només els servidors estan infectats, sinó també Raspberry Pi, i tota mena de màquines virtuals... Així que després de desar els servidors, no us oblideu de guardar les vostres videoconsoles, robots, etc.
UPD 11: Des Nota important per als curanderos manuals:
(després d'utilitzar un o altre mètode per combatre aquest programari maliciós)
Definitivament haureu de reiniciar: el programari maliciós es troba en algun lloc dels processos oberts i, en conseqüència, a la memòria, i s'escriu un de nou per cronar cada 30 segons.
Actualització 12/XNUMX/XNUMX: Exim té un altre (?) programari maliciós a la seva cua i us aconsella que primer estudieu el vostre problema específic abans de començar el tractament.
Actualització 13/XNUMX/XNUMX: més aviat, moveu-vos a un sistema net i transferiu fitxers amb molta cura, perquè... El programari maliciós ja està disponible públicament i es pot utilitzar d'altres maneres menys òbvies i més perilloses.
UPD 14: assegurant-nos que les persones intel·ligents no corren des de l'arrel, una cosa més :
Fins i tot si no funciona des de l'arrel, es produeix la pirateria... Tinc debian jessie UPD: estira al meu OrangePi, Exim s'està executant des de Debian-exim i encara s'ha produït un pirateig, s'han perdut corones, etc.
UPD 15: quan passeu a un servidor net des d'un de compromès, no us oblideu de la higiene, :
Quan transferiu dades, presteu atenció no només als fitxers executables o de configuració, sinó també a qualsevol cosa que pugui contenir ordres malicioses (per exemple, a MySQL això podria ser CREATE TRIGGER o CREATE EVENT). A més, no us oblideu dels fitxers .html, .js, .php, .py i altres fitxers públics (idealment aquests fitxers, com altres dades, s'haurien de restaurar des d'emmagatzematge local o de confiança).
Actualització 16/XNUMX/XNUMX: и : el sistema tenia una versió d'Exim instal·lada als ports, però en realitat n'executava una altra.
Així que tothom després de l'actualització, hauríeu d'assegurar-vos que estàs utilitzant la nova versió!
exim --versionVam resoldre junts la seva situació concreta.
El servidor utilitzava DirectAdmin i el seu antic paquet da_exim (versió antiga, sense vulnerabilitat).
Al mateix temps, amb l'ajuda del gestor de paquets personalitzats de DirectAdmin, de fet, es va instal·lar una versió més nova d'Exim, que ja era vulnerable.
En aquesta situació particular, l'actualització mitjançant custombuild també va ajudar.
No us oblideu de fer còpies de seguretat abans d'aquests experiments, i també assegureu-vos que abans/després de l'actualització tots els processos Exim siguin de la versió antiga. i no "encallat" a la memòria.
Font: www.habr.com