Windigo es una de las operaciones informáticas más sofisticadas de los últimos años. Un grupo de terceros malintencionados han comprometido miles de servidores alrededor del mundo, los cuales son usados principalmente con tres fines: robar credenciales de SSH, redirigir tráfico hacia sitios maliciosos y enviar grandes cantidades de spam. La operación Windigo comenzó en el año 2011 y se estima que unos 25.000 servidores se han visto comprometidos hasta el momento. El software malicioso utilizado es sumamente complejo, ya que puede correr en múltiples sistemas operativos y además pasa muy desapercibido. La operación Windigo cuenta con tres componentes principales: –Linux/Ebury: un backdoor de OpenSSH usado para robar credenciales de servidores. –Linux/Cdorked: un backdoor de HTTP utilizado para redirigir el tráfico web. –Perl/Calfbot: un script de Perl utilizado para enviar spam.
Windigo: ¿cómo detectar si mi servidor está comprometido?
Por suerte este paso resulta sencillo. Veamos a continuación cómo detectar la presencia de cada componente de Windigo: Linux/Ebury: El medio más fácil para identificarlo es corriendo el siguiendo comando desde root:
ssh -G 2>&1 | grep -e illegal -e unknown > /dev/null && echo "Sistema limpio" || echo "Sistema infectado"
Linux/Cdorked: Este es el componente que se encarga de las redirecciones. Su principal punto débil es que redirige todas las peticiones que van a /favicon.iso hacia Google. Verificar su existencia en el servidor es sencillo:
curl -i http://www.misitio.com/favicon.iso | grep "Location:"
Si el resultado arroja Location: http://google.com/ entonces existe una infección. Un resultado nulo indica que no hay infección. Cabe mencionar que el resultado de grep “Location:” puede variar dependiendo de nuestra configuración, por lo tanto obtener un encabezado distinto a Google y que además no sea nulo no quiere decir que el servidor esté infectado. Si se elimina la porción grep de la sintaxis se puede obtener una mayor cantidad de datos. Perl/Calfbot: La presencia de un archivo /tmp/… indica si el servidor está infectado con el script de Perl que se encarga de enviar spam. Verificación:
flock --nb /tmp/... echo "Sistema limpio" || echo "Sistema infectado"
En caso de haber una infección, se utiliza lsof para ver el proceso que hace uso de /tmp/… de la siguiente forma:
lsof /tmp/...
Exploit de NRPE
Y recientemente también hemos visto otro importante exploit pero en este caso para NRPE. NRPE es un software utilizado para realizar tareas de monitorización con Nagios. Las versiones 2.13 y anteriores de NRPE son vulnerables a un exploit a nivel de código. ¿Cómo podemos verificar si la instalación de NRPE de un server remoto está afectada? Desde el servidor que tiene instalado el sistema de monitorización debemos correr lo siguiente como root:
/usr/local/nagios/libexec/check_nrpe -H <IP_del_servidor_remoto> -c check_disk -a '$(echo /boot)'
Un resultado como el de abajo indica que el servidor remoto usa una instalación vulnerada de NRPE:
DISK OK - free space: /boot 53 MB (61% inode=99%);| /boot=33MB;;;0;92
Por otro lado, el siguiente resultado indica que no hay compromisos:
CHECK_NRPE: Received 0 bytes from daemon. Check the remote server logs for error messages.
Actualizar NRPE a una versión posterior a la 2.13 es la forma más rápida y sencilla de evitar el exploit. Tanto en el caso de Windigo como de NRPE, nuestros sysadmins ya han revisado todos los servidores de la red y no ha habido infección alguna.
