Compañeiros que usan as versións 4.87...4.91 de Exim nos seus servidores de correo: actualízanse urxentemente á versión 4.92, xa que detiveron previamente o propio Exim para evitar a piratería a través de CVE-2019-10149.
Varios millóns de servidores en todo o mundo son potencialmente vulnerables, a vulnerabilidade está clasificada como crítica (puntuación base CVSS 3.0 = 9.8/10). Os atacantes poden executar comandos arbitrarios no teu servidor, en moitos casos desde root.
Asegúrate de que estás a usar unha versión fixa (4.92) ou unha que xa foi parcheada.
Ou parchear o existente, ver o fío .
Actualización para céntimos 6: cm. — para centos 7 tamén funciona, se aínda non chegou directamente de epel.
UPD: Ubuntu está afectado 18.04 e 18.10, lanzouse unha actualización para eles. As versións 16.04 e 19.04 non se ven afectadas a non ser que se instalaran opcións personalizadas nelas. Máis detalles .
Agora o problema alí descrito está a ser explotado activamente (por un bot, presumiblemente), notei unha infección nalgúns servidores (que funcionan en 4.91).
A lectura adicional só é relevante para aqueles que xa o "obtiveron": debes transportar todo a un VPS limpo cun software novo ou buscar unha solución. Imos tentar? Escribe se alguén pode superar este malware.
Se vostede, sendo un usuario de Exim e lendo isto, aínda non se actualizou (non se asegurou de que a 4.92 ou unha versión parcheada está dispoñible), pare e execute a actualización.
Para os que xa chegaron, seguimos...
ACTUALIZACIÓN: e dá o consello correcto:
Pode haber unha gran variedade de malware. Ao lanzar o medicamento para a cousa equivocada e despexar a cola, o usuario non se curará e pode non saber para que debe ser tratado.
A infección nótase así: [kthrotlds] carga o procesador; nun VDS débil é 100%, nos servidores é máis débil pero nótase.
Despois da infección, o malware elimina as entradas do cron, rexistrándose só alí para executarse cada 4 minutos, mentres que o ficheiro crontab é inmutable. Crontab -e non pode gardar os cambios, dá un erro.
Pódese eliminar o inmutable, por exemplo, así e despois eliminar a liña de comandos (1.5 kb):
chattr -i /var/spool/cron/root
crontab -e
A continuación, no editor crontab (vim), elimine a liña e garda:dd
:wq
Non obstante, algúns dos procesos activos están a sobrescribirse de novo, estou descubrindo.
Ao mesmo tempo, hai unha morea de wgets (ou rizos) activos colgados nos enderezos do script de instalación (ver máis abaixo), polo de agora estou derrumbando así, pero comezan de novo:
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}'`
Atopei aquí o script de instalación de troiano (centos): /usr/local/bin/nptd... Non o estou publicando para evitalo, pero se alguén está infectado e entende os scripts de shell, estudiádeo máis detidamente.
Engaderei a medida que se actualice a información.
UPD 1: A eliminación de ficheiros (con chattr -i preliminar) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root non axudou nin deter o servizo - tiven que crontab completamente por agora arrácalo (cambiar o nome do ficheiro bin).
UPD 2: o instalador troiano ás veces tamén estaba por aí noutros lugares, a busca por tamaño axudou:
atopar / -tamaño 19825c
Actualización 3/XNUMX/XNUMX: Atención! Ademais de desactivar selinux, o troiano tamén engade o seu Chave SSH en ${sshdir}/authorized_keys! E activa os seguintes campos en /etc/ssh/sshd_config, se aínda non foron definidos como SI:
PermitRootLogin si
Autenticación RSA si
PubkeyAuthentication si
echo UsePAM si
Contrasinal de autenticación si
UPD 4: para resumir por agora: desactivar Exim, cron (con raíces), eliminar urxentemente a chave troiana de ssh e editar a configuración de sshd, reiniciar sshd! E aínda non está claro que isto vai axudar, pero sen el hai un problema.
Movei información importante dos comentarios sobre parches/actualizacións ao comezo da nota, para que os lectores comecen con ela.
Actualización 5/XNUMX/XNUMX: que o malware cambiou os contrasinais en WordPress.
Actualización 6/XNUMX/XNUMX: , imos probar! Despois dun reinicio ou apagado, o medicamento parece desaparecer, pero polo momento polo menos é iso.
Calquera persoa que faga (ou atope) unha solución estable, escriba, axudará a moitos.
Actualización 7/XNUMX/XNUMX: escribe:
Se aínda non dixeches que o virus resucitou grazas a unha carta non enviada en Exim, cando tentas enviar a carta de novo, restablecerase, busca en /var/spool/exim4
Podes borrar toda a cola de Exim deste xeito:
exipick -i | xargs exim -Sr
Comprobando o número de entradas na cola:
exim -bpc
UPD 8: De novo : FirstVDS ofreceu a súa versión do script de tratamento, imos probalo!
UPD 9: Parece traballo, grazas polo guión!
O principal é non esquecer que o servidor xa estaba comprometido e que os atacantes poderían ter logrado plantar algunhas cousas desagradables máis atípicas (non listadas no contagotas).
Polo tanto, é mellor pasar a un servidor completamente instalado (vds) ou polo menos seguir supervisando o tema; se hai algo novo, escriba aquí nos comentarios, porque obviamente non todos se moverán a unha instalación nova...
UPD 10: Grazas de novo : lembra que non só os servidores están infectados, senón tamén Raspberry Pi, e todo tipo de máquinas virtuais... Así que despois de gardar os servidores, non esquezas gardar as túas videoconsolas, robots, etc.
UPD 11: Desde Nota importante para os curadores manuais:
(despois de usar un ou outro método para combater este malware)
Definitivamente cómpre reiniciar: o malware sitúase nalgún lugar dos procesos abertos e, en consecuencia, na memoria, e escribe un novo para cronar cada 30 segundos.
Actualización 12/XNUMX/XNUMX: Exim ten outro (?) malware na súa cola e recoméndalle que estude primeiro o seu problema específico antes de comezar o tratamento.
Actualización 13/XNUMX/XNUMX: máis ben, pasa a un sistema limpo e transfire ficheiros con moito coidado, porque O malware xa está dispoñible publicamente e pódese usar doutras formas menos obvias e máis perigosas.
UPD 14: asegurándonos que as persoas intelixentes non corren de raíz - unha cousa máis :
Aínda que non funcione desde o root, prodúcese un hackeo... Teño debian jessie UPD: estira no meu OrangePi, Exim funciona desde Debian-exim e aínda se produciu o hackeo, coroas perdidas, etc.
UPD 15: ao pasar a un servidor limpo desde un comprometido, non te esquezas da hixiene, :
Ao transferir datos, preste atención non só aos ficheiros executables ou de configuración, senón tamén a calquera cousa que poida conter comandos maliciosos (por exemplo, en MySQL pode ser CREATE TRIGGER ou CREATE EVENT). Ademais, non te esquezas de .html, .js, .php, .py e outros ficheiros públicos (idealmente estes ficheiros, como outros datos, deberían ser restaurados desde o almacenamento local ou doutro tipo de confianza).
Actualización 16/XNUMX/XNUMX: и : o sistema tiña unha versión de Exim instalada nos portos, pero en realidade estaba executando outra.
Así que todos despois da actualización debes asegurarte que estás a usar a nova versión!
exim --versionResolvemos xuntos a súa situación específica.
O servidor utilizou DirectAdmin e o seu antigo paquete da_exim (versión antiga, sen vulnerabilidade).
Ao mesmo tempo, coa axuda do xestor de paquetes personalizados de DirectAdmin, de feito, instalouse unha versión máis nova de Exim, que xa era vulnerable.
Nesta situación particular, a actualización mediante custombuild tamén axudou.
Non esquezas facer copias de seguridade antes de tales experimentos e asegúrate de que antes/despois da actualización todos os procesos de Exim sexan da versión antiga. e non "atrapados" na memoria.
Fonte: www.habr.com