Servidor comprometido: Restaurar o desinfectar? Desinfección

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.

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

#!/bin/bash
# Para finalizar el proceso en curso
pkill -f tcpdump
# Nuevo proceso. Notese que ponemos el path completo
/usr/sbin/tcpdump -ni eth0 -s0 proto TCP and port 25 -w /root/myserver-$(date +%Y%m%d%H%M%S).smtp.pcap

Tarea cron cada 30 minutos

*/30 * * * * /root/analisis.sh > /dev/null 2>&1

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.

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.

# cat /var/log/messages|grep -i firewall|grep UID|grep DPT=25
...
Feb 19 11:11:07 srv108 kernel: Firewall: *TCP_OUT Blocked* IN= OUT=eth0 SRC=176.31.31.233 DST=65.20.0.49 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=63111 DF PROTO=TCP SPT=55456 DPT=25 WINDOW=29200 RES=0x00 SYN URGP=0 UID=1054 GID=1054
Feb 19 11:11:07 srv108 kernel: Firewall: *TCP_OUT Blocked* IN= OUT=eth0 SRC=176.31.31.233 DST=65.20.0.49 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=16978 DF PROTO=TCP SPT=55462 DPT=25 WINDOW=29200 RES=0x00 SYN URGP=0 UID=1054 GID=1054
Feb 19 11:11:07 srv108 kernel: Firewall: *TCP_OUT Blocked* IN= OUT=eth0 SRC=176.31.31.233 DST=65.20.0.49 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=14566 DF PROTO=TCP SPT=55466 DPT=25 WINDOW=29200 RES=0x00 SYN URGP=0 UID=1054 GID=1054
Feb 19 11:11:09 srv108 kernel: Firewall: *TCP_OUT Blocked* IN= OUT=eth0 SRC=176.31.31.233 DST=65.20.0.49 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=53420 DF PROTO=TCP SPT=55872 DPT=25 WINDOW=29200 RES=0x00 SYN URGP=0 UID=1054 GID=1054
Feb 19 11:11:09 srv108 kernel: Firewall: *TCP_OUT Blocked* IN= OUT=eth0 SRC=176.31.31.233 DST=65.20.0.49 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=4806 DF PROTO=TCP SPT=55874 DPT=25 WINDOW=29200 RES=0x00 SYN URGP=0 UID=1054 GID=1054
Feb 19 11:11:09 srv108 kernel: Firewall: *TCP_OUT Blocked* IN= OUT=eth0 SRC=176.31.31.233 DST=65.20.0.49 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=61404 DF PROTO=TCP SPT=55878 DPT=25 WINDOW=29200 RES=0x00 SYN URGP=0 UID=1054 GID=1054
...

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

# getent passwd 1054
hackuser:x:1054:1054::/home/hackuser:/usr/local/cpanel/bin/jailshell

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.

Lectura recomendada

tcpdump Cheat Sheet es un buenismo artículo sobre TCPdump, que puede ser una referencia en trabajos posteriores de seguridad, y que permite descubrir en profundidad esta herramienta

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