Servidor comprometido: Restaurar o desinfectar? Desinfección

Desinfección Guy fawkes hacking anonymous wordpress

Desde hace veinte años, siempre he oido la misma cantinela “Su servidor está comprometido. Debe restaurar desde una copia de seguridad limpia“. Esto siempre me lo han dicho, y siempre he pensado que los gurús que lo decían, a parte de ingenieros de revista, no viven en la realidad de los sistema en producción de una empresa de hosting. Yo creo que un servidor comprometido, tiene posibilidad de desinfección, y que el trabajo requiere un análisis forense, para evaluar el alcance de la infección. Lo demás, son las típicas coletillas de los gurus de internet, como el caso en Spam sending on my machine not write on log of exim and ASSP en el que todo su aporte es indicar la misma cantinela que se repite desde tiempos inmemoriales, obviando que existe el trabajo forense.

Desinfectar un servidor comprometido

Síntomas de la infección

Recibí avisos de uno de mis proveedores de servidores, OVH, de su sistema anti-spam. No es que funcione excesivamente bien, ya que se le pasan muchos problemas de spam, pero es una herramienta muy útil, porque a veces tus propios sistemas fallan, y en estas cosas dos mejor que uno, y tres mejor que dos.

OVH Notificación

Estimado/a cliente:

Nuestro sistema de protección antispam ha detectado un envío de spam
desde una de sus IP:
176.31.XX.XXX

Para garantizar la seguridad de nuestra red, hemos bloqueado el tráfico
saliente de su servidor hacia el puerto 25.

Para que pueda realizar las comprobaciones oportunas, le ofrecemos algunos
ejemplos del correo bloqueado:

Destination IP: 104.44.YYY.ZZZ – Message-ID: ee1692dc-4fb36f-384d8c@farwestsxxxxxl.com – Spam score: 300
Destination IP: 104.44.YYY.ZZZ – Message-ID: 5c7e3f7b-536a-36bf@xxxxxmett.edu – Spam score: 300
Destination IP: 104.44.YYY.ZZZ – Message-ID: 24e645-f3b591-4ef97ddb@xxxxxning.com – Spam score: 300
Destination IP: 104.44.YYY.ZZZ – Message-ID: eca9-32dbdd-41c7361d@xxxxxiciancaptives.com – Spam score: 300
Destination IP: 104.44.YYY.ZZZ – Message-ID: 7eca76d4-3b2cf-4ff5f@xxxxxris.it – Spam score: 300

Bueno, lo normal es tratar de localizar los destinatarios en los logs del servidor de correo, pero en mi caso no aparecían. Tampoco estaban en el ASSP (Anti-spam SMTP Proxy Server). Bueno, lo deje pasar y lo di como falso positivo. Saque por unos días el correo por mi smarthost y luego solicite el desbloqueo de la IP.

Sorpresa!!! Volvíamos a la carga y encima me ofusque con el soporte de OVH. Menos mal que últimamente han mejorado mucho, aunque queda algún resquicio del pasado que hace insoportable la solicitud de un soporte efectivo, conseguí que se encaminara hacía un departamento superior.

Bueno, algo estaba mal en mi concepción del problema. Era algo nuevo. Me había obcecado en que los logs son la madre de todos los análisis, pero había obviado que los logs pertenecen a aplicaciones, y para enviar correo desde una máquina hay métodos que no pasan por esas aplicaciones.

OVH me confirmo que la salida del sistema antispam, era real, y que se trataba de conexiones telnet.

Ahora quedaba claro que estaban utilizando telnet o en su defecto una aplicación que hiciera uso de sockets para comunicarse directamente con los servidores de correo de destino y eso no dejaba rastro en los logs de correo.

Verificación de la infección

Necesitaba primero verificar y después con la marca de tiempo buscar entre los logs de Apache, acceso a Cpanel, y logs de sistema, como y cuando se producía el intento de envío que me indicaba OVH confinado que su marca de tiempo fuera correcta.

La mejor forma que encontré era realizar un volcado con tcpdump  para el tráfico entre mi máquina y otras máquinas a través del puerto 25 (correo). Como el tamaño podía ser considerable, y el lanzamiento del spam relay, se efectuaba a distintas horas, me cree una script para hacer paquetes de 30 minutos, más manejables.

analisis.sh

Tarea cron cada 30 minutos

Análisis del tráfico del puerto 25 con Wireshark

Una vez, que salta el problema, y con la marca de tiempo en nuestras manos, se trata de analizar el tcpdump para verificar y localizar la mejor marca de tiempo, con el fin de buscar después en los logs, gracias a Wireshark.

Pantalla de análisis tcpdump puerto 25 con WireShark

Como buscar en los logs del sistema relativos a la accesibilidad (Apache, ftp, cpanel, …) es complicado y dado que el foco estaba muy localizado en un puerto, la opción era bloquear temporalmente el uso del puerto 25 a todos los usuarios, excepto root, utilizando para ello el módulo ipt_owner/xt_owner, el cual nos permite conocer la UID de los paquetes ethernet en nuestro sistema.

Observamos, que el usuario con UID 1054, esta presente de forma continuada en el tiempo indicado. Ahora vamos a por él.

Obtener el usuario desde el UID

Desinfección

El resto de los procesos, como es la detección de la actividad en el sitio web del usuario (log de apache), accesos del usuario via ftp, via cpanel, comprobación de sus cron, pertenecen ya a algo más interno que dejamos a desarrollar por el administrador. Realizados, nos permitirán una plena desinfección, y una análisis del problema para documentarlo y evaluar los mecanismos y procedimientos a modificar o incorporar con el fin de evitarlo.

En nuestro caso, el proceso era aprovechar una vulnerabilidad en un WordPress desactualizado, que nuestro Mod Security no podía frenar, y a través de él, inyectar un fichero perl, encargado de introducir un binario en el directorio temporal, y una tarea cron, para lanzarlo. Al mismo tiempo, se borraba el fichero perl. El binario, era una pequeña aplicación que trataba de hacer relay (enviar correo en nombre del alguien desde un sistema, que ni siquiera tiene que ver con el emisor, mediante telnet), y debido a su forma de enviarlo no utilizaba el sistema, y por tanto no dejaba huella en los logs.

Nota del autor
Evidentemente este artículo no esta escrito por un gurú de la seguridad informática, ni por un paranoico de la misma, sino por un administrador de sistemas, que debe conciliar, el trabajo de seguridad con servidores compartidos, con cientos de usuarios, software de muy mala calidad, y malas prácticas en la custodia de credenciales.

En esa conciliación, pese al uso de herramientas como Mod Security, CXS Scanner, y otras más que están incorporadas, el no poder utilizarlas al 100% debido a la dificultad del usuario medio de entender la necesidad de las mismas, debido a las malas prácticas de nuestros proveedores de acceso a Internet cuyas IP están permanentemente bloqueadas, los servidores de correo de las administraciones publicas y grandes empresas y/o bancos, que no cumplen normativas, y el uso de softwares de terceros con mas agujeros de seguridad, que una puerta de contrachapado, hacen muy difícil el cerrar bien la puerta.


La imagen de portada, ha sido creada por freevector.com y distribuida bajo licencia Creative Commons Attribution-NonCommercial 4.0 siendo retocada por Abdelkarim Mateos

Comparte este artículo

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax