Diego Berrueta

(This is a reprint of the original post)

Hay visitas que son más agradables que otras. En el servidor de AsturLiNUX recibimos una de las que menos gustan. El pasado lunes 5, Chipi observó un proceso extraño en el servidor, ejecutándose con la personalidad del Apache, y rápidamente pasó el aviso. Los administradores paramos el servidor web y comenzamos a analizar la situación. El proceso no era sino un backdoor que algún atacante había conseguido colar para poder abrirse un shell en un puerto. Todo indica que no consiguió abrirse el shell, en parte gracias al firewall y también porque no se le ocurrió otra forma de hacerlo (¿un script-kiddie? ¿o tal vez alguien más hábil jugando al despiste?). En cualquier caso, había varias tareas que hacer antes de poder restaurar el servicio. Las dos más importantes: encontrar el agujero utilizado (y cerrarlo, naturalmente) y estudiar el daño causado (y repararlo, claro).

El agujero, como apuntó Chipi, estaba en el Drupal (el CMS que hay detrás de la Comunidad de AsturLiNUX). Concretamente, en una vulnerabilidad de la biblioteca XML-RPC para PHP. Drupal usa esta biblioteca para proporcionar servicios web con los cuales es posible, por ejemplo, enviar historias a los blogs desde el escritorio con Gnome Blog. El bug, muy gordo, permite ejecutar código PHP en el servidor. Como es natural, alguien se ocupó de escribir, exploits para detectar y aprovechar el agujero.

¿Por qué nos afectó este agujero, si Debian sacó puntualmente una actualización de seguridad? Pues porque el Drupal que corría hasta ahora en pintaiux no era el empaquetado para Debian, puesto que se instaló antes de que existiera el paquete. Lo mejor hubiera sido reemplazar el Drupal instalado por el empaquetado en cuando se dispuso del paquete, pero los administradores no tuvimos tiempo.

Por tanto, desde el 10 de Julio la vulnerabilidad era pública, y el día 12 ya era público un exploit. Como cabía esperar en la jungla de Internet, algunos se dedicaron a buscar Drupales ajenos para reventarlos (no viene a cuento hablar ahora de las motivaciones para este comportamiento tan estúpido). Parece que usaron Google para buscar "huellas" del Drupal y encontrar así dónde está instalado (atacar a desconocidos es doblemente estúpido). He encontrado rastros de los escaneos indiscriminados en los logs de otros servidores, principalmente en la segunda quincena de Julio.

A pintaiux llegaron el 21 de Julio, aunque la primera intrusión confirmada se produjo el 31 de Julio (entre esas fechas hay muchos intentos, pero no hay pruebas de que consiguieran nada). El 31 de Julio consiguieron meter el backdoor usando uno de los exploits. Gracias al resto de medidas de seguridad que tenemos, parece que no pudieron abrirse un shell ni causar daños significativos en el servidor (y si lo han hecho, yo no he sido suficientemente listo como para darme cuenta). Potencialmente, sí quedó expuesto el contenido de la base de datos del Drupal, que por fortuna tenemos parcheada para que almacene las contraseñas encriptadas, y que no contiene datos personales (por motivos obvios de seguridad, los datos de los socios no están en pintaiux). Como hay muchos listillos por el mundo, otros consiguieron repetir la jugada (instalación del backdoor) en un par de ocasiones más.

En tanto no pongamos en marcha una solución definitiva, la brecha se ha cerrado deshabilitando los servicios web del Drupal. También se han ajustado algunos permisos para que, si vuelve a aparecer un agujero similar, los atacantes lo tengan más difícil.

La mayor parte del tiempo que ha estado el servidor apagado, lo he dedicado a revisar logs y comparar backups. Afortunadamente tenemos una buena infraestructura de backups, que se realizan automáticamente y de forma regular, almacenando la información en otra máquina. Por tanto, he podido examinar con detenimiento los registros de los distintos demonios, comparar ficheros y permisos y analizar, registro a registro, todos los cambios en las bases de datos en estas semanas. Es posible que se me haya escapado algo, pero tengo la confianza suficiente como para volver a poner en marcha los servicios sin restaurar desde backup. Ojalá no esté cometiendo un grave error.

No he comentado nada acerca de quienes fueron los visitantes. Sus direcciones IP, pertenecientes a un ISP brasileño, quedaron registradas en varios logs, pero como sabemos, es muy difícil llegar mucho más lejos.