Colegas, los que usan servidores de correo Exim versiones 4.87…4.91 — actualicen urgentemente a la versión 4.92, deteniendo previamente Exim para evitar un hackeo a través de CVE-2019-10149.
Potencialmente, varios millones de servidores en todo el mundo son vulnerables, la vulnerabilidad se califica como crítica (CVSS 3.0 base score = 9.8/10). Los atacantes pueden ejecutar comandos arbitrarios en su servidor, en muchos casos como root.
Por favor, asegúrese de que está utilizando la versión corregida (4.92) o ya parcheada.
O parchee la existente, véase la rama .
Actualización para centos 6: véase — para centos 7 también funciona, si aún no ha llegado desde epel directamente.
UPD: Ubuntu afectado 18.04 y 18.10, se ha lanzado una actualización para ellos. Las versiones 16.04 y 19.04 no están afectadas, a menos que se hayan instalado variantes personalizadas. Más información .
Actualmente, el problema descrito allí está siendo explotado activamente (supongo que por un bot), lo he notado en algunos de mis servidores (que estaban en 4.91) contagiados.
A partir de aquí, es relevante solo para aquellos que ya han "caído" — hay que mover todo a una VPS limpia con software reciente, o buscar una solución. ¿Lo intentamos? Escriba si alguien puede combatir este malware.
Si usted, siendo usuario de Exim y leyendo esto, aún no ha actualizado (no se ha asegurado de tener la 4.92 o una versión parcheada), por favor deténgase y corra a actualizar.
Para aquellos ya infectados — continuemos…
UPD: y da el consejo correcto:
Puede haber una gran cantidad de malwares. Al ejecutar una cura equivocada y limpiar la cola, el usuario no se curará y es posible que no se dé cuenta de qué necesita tratar.
La infección se nota así: [kthrotlds] carga el procesador; en un VDS débil al 100%, en servidores más débiles, pero notablemente.
Después de la infección, el malware elimina las entradas en cron, dejando solo la suya para ejecutarse cada 4 minutos, y al mismo tiempo hace el archivo crontab inmutable. Crontab -e no puede guardar cambios, arroja un error.
Se puede quitar la inmutabilidad así, después de lo cual eliminar la línea del comando (1.5kb):
chattr -i /var/spool/cron/root
crontab -e Luego en el editor de crontab (vim) eliminamos la línea y guardamos:dd
:wq
Sin embargo, algún proceso activo la sobrescribe de nuevo, estoy investigando.
Mientras tanto, hay un montón de wget (o curl) activos a las direcciones del script del instalador (ver más abajo), los estoy deteniendo así, pero se reinician:
ps aux | grep wge[t]
ps aux | grep cur[l]
echo "Deteniendo..."
kill -9 `ps aux | grep wge[t] | awk '{print $2}'`
kill -9 `ps aux | grep cur[l] | awk '{print $2}'`
He encontrado el script del instalador del troyano aquí (centos): /usr/local/bin/nptd... no lo publico por razones de seguridad, pero si alguien está infectado y sabe de scripts de shell, por favor investiguen con más detalle.
Añadiré más conforme tenga información actualizada.
UPD 1: Eliminación de archivos (con chattr -i previo) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root no ayudó, al igual que detener el servicio — tuve que eliminar el crontab por completo (renombrar el archivo bin).
UPD 2: A veces, el instalador del troyano se encontraba en otros lugares, ayudó buscar por tamaño:
find / -size 19825c
UPD 3: ¡Atención! Además de desactivar selinux, el troyano también añade su clave SSH a ${sshdir}/authorized_keys! Y activa los siguientes campos en /etc/ssh/sshd_config, si aún no estaban configurados como YES:
PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes
echo UsePAM yes
PasswordAuthentication yes
UPD 4: Resumiendo hasta ahora: desactivamos exim, cron (con root), eliminamos urgentemente la clave del troyano de ssh y corregimos la configuración de sshd, ¡reiniciamos sshd! Y eso aún no está claro si ayudará, pero sin esto es un desastre total.
He destacado información importante de los comentarios sobre parches/actualizaciones al inicio de la nota, para que quienes la lean comiencen desde allí.
UPD 5: que el malware cambió las contraseñas en WordPress.
UPD 6: , ¡lo estamos probando! Después de reiniciar o desactivar el remedio, parece que se elimina, pero al menos así estamos.
Quien encuentre (o haga) una solución estable, por favor escríbame, ayudarán a muchos.
UPD 7: escribe:
Si no lo han dicho, el virus se revive gracias a un correo no enviado en exim; al intentar enviar el correo nuevamente, se restaura, miren en /var/spool/exim4.
Para limpiar toda la cola de exim se puede hacer así:
exipick -i | xargs exim -Mrm
Comprobación de la cantidad de registros en la cola:
exim -bpc
UPD 8: De nuevo : FirstVDS ha propuesto su versión del script para la cura, ¡vamos a probarlo!
UPD 9: Parece que está trabajando, gracias por el script!
Lo principal es no olvidar que el servidor ya ha sido comprometido y que los atacantes podrían haber introducido otras cosas no típicas (no mencionadas en el droppers).
Por lo tanto, es mejor mudarse a un servidor limpio (vds), o al menos seguir la discusión; si hay algo nuevo, escriban en los comentarios aquí, ya que claramente no todos se mudarán a una instalación fresca...
UPD 10: Una vez más gracias : recuerda que no solo se infectan los servidores, sino también, por ejemplo, Raspberry Pi, y diversas máquinas virtuales… Así que después de salvar los servidores, no olvides salvar tus consolas de videojuegos, robots, etc.
UPD 11: De una nota importante para los que "curan manualmente":
(después de aplicar cualquiera de los métodos para combatir este malware)
es obligatorio reiniciar: el malware permanece en los procesos abiertos y, por lo tanto, en la memoria, y se regraba en cron cada 30 segundos.
UPD 12: en su cola exim otro(?) malware y aconseja investigar específicamente tu problema antes de comenzar el tratamiento.
UPD 13: moverse a un sistema limpio, y transferir archivos con mucha cautela, ya que el malware ya está disponible públicamente y podría ser utilizado por otros de maneras menos obvias y más peligrosas.
UPD 14: tranquilizándose con el hecho de que las personas inteligentes no ejecutan desde root — otro :
Incluso si funciona sin root, puede ocurrir un hackeo... Yo tengo Debian Jessie en mi OrangePi UPD: Stretch, Exim se ejecuta desde Debian-exim y aun así ocurrió un hackeo, se borró cron y demás.
UPD 15: al mudarte a un servidor limpio desde uno comprometido, no olvides la higiene, :
Al transferir datos, no solo prestes atención a los archivos ejecutables o de configuración, sino también a todo lo que pueda contener comandos maliciosos (por ejemplo, en MySQL esto podría ser CREATE TRIGGER o CREATE EVENT). Además, no olvides los archivos .html, .js, .php, .py y otros archivos públicos (en ideal, estos archivos, al igual que otros datos, deben ser restaurados desde un almacenamiento local u otro de confianza).
UPD 16: y : en el sistema había una versión de exim en los puertos, pero en realidad se estaba ejecutando otra.
Así que todos después de la actualización deben asegurarse de que están utilizando la nueva versión exactamente.
exim --versionConcretamente, resolvimos juntos su situación.
En el servidor se utilizaba DirectAdmin y tenía su viejo paquete da_exim (versión antigua, sin vulnerabilidades).
Con el administrador de paquetes custombuild de DirectAdmin, se instaló en realidad una versión más nueva de exim, que ya era vulnerable.
En esta situación específica, también ayudó la actualización a través de custombuild.
No olviden hacer copias de seguridad antes de tales experimentos, y asegúrense de que antes/después de la actualización todos los procesos de exim de la versión anterior y no 'se queden' en la memoria.
Fuente: habr.com
