Colegas que usan las versiones 4.87...4.91 de Exim en sus servidores de correo: actualicen urgentemente a la versión 4.92, habiendo detenido previamente Exim para evitar piratear CVE-2019-10149.
Varios millones de servidores en todo el mundo son potencialmente vulnerables; la vulnerabilidad está clasificada como crítica (puntuación base CVSS 3.0 = 9.8/10). Los atacantes pueden ejecutar comandos arbitrarios en su servidor, en muchos casos desde la raíz.
Asegúrese de estar utilizando una versión fija (4.92) o una que ya haya sido parcheada.
O parchear el existente, ver hilo .
Actualización para CentOS 6: cm. — para centos 7 también sirve, si aún no ha llegado directamente de epel.
UPD: Ubuntu está afectado 18.04 y 18.10, se ha publicado una actualización para ellos. Las versiones 16.04 y 19.04 no se ven afectadas a menos que se les instalen opciones personalizadas. Más detalles .
Ahora que el problema descrito allí está siendo explotado activamente (presumiblemente por un bot), noté una infección en algunos servidores (que se ejecutan en 4.91).
Leer más es relevante solo para aquellos que ya lo han "comprendido": deben transportar todo a un VPS limpio con software nuevo o buscar una solución. ¿Lo intentamos? Escriba si alguien puede superar este malware.
Si usted, siendo usuario de Exim y leyendo esto, aún no se ha actualizado (no se ha asegurado de que esté disponible la versión 4.92 o una versión parcheada), deténgase y ejecute la actualización.
Para los que ya llegaron, continuemos...
UPD: y da el consejo correcto:
Puede haber una gran variedad de malware. Al lanzar el medicamento para lo incorrecto y despejar la cola, el usuario no se curará y es posible que no sepa para qué necesita tratamiento.
La infección se nota así: [kthrotlds] carga el procesador; en un VDS débil es del 100%, en servidores es más débil pero se nota.
Después de la infección, el malware elimina las entradas cron, registrándose allí solo para ejecutarse cada 4 minutos, mientras hace que el archivo crontab sea inmutable. crontab-e No se pueden guardar los cambios, da un error.
Lo inmutable se puede eliminar, por ejemplo, de esta manera y luego eliminar la línea de comando (1.5 kb):
chattr -i /var/spool/cron/root
crontab -e
A continuación, en el editor crontab (vim), elimine la línea y guarde:dd
:wq
Sin embargo, algunos de los procesos activos se están sobrescribiendo nuevamente, lo estoy averiguando.
Al mismo tiempo, hay un montón de wgets (o curls) activos colgados en las direcciones del script del instalador (ver más abajo), los derribaré así por ahora, pero comienzan de nuevo:
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}'`
Encontré el script del instalador del troyano aquí (centos): /usr/local/bin/nptd... No lo publicaré para evitarlo, pero si alguien está infectado y comprende los scripts de shell, estúdielo más detenidamente.
Lo agregaré a medida que se actualice la información.
UPD 1: Eliminar archivos (con chattr -i preliminar) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root no ayudó, ni tampoco detener el servicio; tuve que hacerlo crontab por completo por ahora, quítelo (cambie el nombre del archivo bin).
UPD 2: El instalador del troyano a veces también se encontraba en otros lugares, la búsqueda por tamaño ayudó:
encontrar / -tamaño 19825c
UPD 3: ¡Atención! Además de desactivar selinux, el troyano también añade su propio clave SSH en ${sshdir}/authorized_keys! Y activa los siguientes campos en /etc/ssh/sshd_config, si aún no se han configurado en SÍ:
PermitRootLogin sí
RSAAutenticación sí
PubkeyAuthentication sí
eco UsePAM si
Autenticación de contraseña sí
UPD 4: Para resumir por ahora: deshabilite Exim, cron (con raíces), elimine urgentemente la clave troyana de ssh y edite la configuración de sshd, reinicie sshd. Y todavía no está claro si esto ayudará, pero sin él hay un problema.
Moví información importante de los comentarios sobre parches/actualizaciones al principio de la nota, para que los lectores comiencen con ella.
UPD 5: que el malware cambió las contraseñas en WordPress.
UPD 6: , ¡probemos! Después de reiniciar o apagar, el medicamento parece desaparecer, pero al menos por ahora eso es todo.
Cualquiera que cree (o encuentre) una solución estable, escriba, ayudará a muchos.
UPD 7: escribe:
Si aún no has dicho que el virus resucita gracias a una carta no enviada en Exim, cuando intentas enviar la carta nuevamente se restaura, busca en /var/spool/exim4
Puede borrar toda la cola Exim de esta manera:
exipick -i | xargs exim -Mrm
Comprobando el número de entradas en la cola:
exim-bpc
ACTUALIZACIÓN 8: Otra vez : FirstVDS ofreció su versión del script de tratamiento, ¡probémoslo!
UPD 9: Parece que obras, Gracias por el guión!
Lo principal es no olvidar que el servidor ya estaba comprometido y los atacantes podrían haber logrado colocar algunas cosas desagradables más atípicas (que no figuran en el cuentagotas).
Por lo tanto, es mejor pasar a un servidor completamente instalado (vds), o al menos continuar monitoreando el tema; si hay algo nuevo, escriba aquí en los comentarios, porque Obviamente no todos cambiarán a una instalación nueva...
UPD 10: Gracias de nuevo : recuerda que no sólo los servidores están infectados, sino también Frambuesa Pi, y todo tipo de máquinas virtuales... Así que después de guardar los servidores, no olvides guardar tus videoconsolas, robots, etc.
ACTUALIZACIÓN 11: Desde Nota importante para curanderos manuales:
(después de utilizar uno u otro método para combatir este malware)
Definitivamente necesita reiniciar: el malware se ubica en algún lugar de los procesos abiertos y, en consecuencia, en la memoria, y escribe uno nuevo en cron cada 30 segundos.
UPD 12: Exim tiene otro(?) malware en su cola y le aconseja que primero estudie su problema específico antes de comenzar el tratamiento.
UPD 13: más bien, cambie a un sistema limpio y transfiera archivos con mucho cuidado, porque El malware ya está disponible públicamente y puede utilizarse de otras formas menos obvias y más peligrosas.
UPD 14: asegurarnos de que las personas inteligentes no huyen de la raíz: una cosa más :
Incluso si no funciona desde la raíz, se produce un hackeo... Tengo Debian jessie UPD: estiramiento en mi OrangePi, Exim se está ejecutando desde Debian-exim y aún así se produjo un hackeo, se perdieron coronas, etc.
UPD 15: al pasar a un servidor limpio desde uno comprometido, no se olvide de la higiene, :
Al transferir datos, preste atención no sólo a los archivos ejecutables o de configuración, sino también a cualquier cosa que pueda contener comandos maliciosos (por ejemplo, en MySQL podría ser CREATE TRIGGER o CREATE EVENT). Además, no se olvide de .html, .js, .php, .py y otros archivos públicos (lo ideal es que estos archivos, al igual que otros datos, se restauren desde un almacenamiento local o de otro tipo confiable).
UPD 16: и : el sistema tenía una versión de Exim instalada en los puertos, pero en realidad ejecutaba otra.
Entonces todos después de la actualización debes asegurarte que estás usando la nueva versión!
exim --versionResolvimos juntos su situación específica.
El servidor utilizó DirectAdmin y su antiguo paquete da_exim (versión antigua, sin vulnerabilidad).
Al mismo tiempo, con la ayuda del administrador de paquetes de compilación personalizada de DirectAdmin, de hecho, se instaló una versión más nueva de Exim, que ya era vulnerable.
En esta situación particular, la actualización mediante compilación personalizada también ayudó.
No olvide hacer copias de seguridad antes de dichos experimentos y también asegúrese de que antes/después de la actualización todos los procesos Exim sean de la versión anterior. y no “atascado” en la memoria.
Fuente: habr.com