Como encontrar facilmente scripts de PHP que envían SPAM

Tengo la costumbre de revisar cada pocos días los gráficos que genera la herramienta Munin para controlar los recursos de mi servidor. Ayer por la tarde, detecté una gráfica de lo más inusual:

Cola de postfix en Munin

Cola de postfix en Munin

Se trata de la gráfica de la cola de correo pendiente de enviar de Postfix. Como se puede ver en el gráfico por mes o por semana, en el caso de mi servidor, la cola rara vez tiene una gran ocupación. En algún envío masivo a los usuarios de algún foro es posible que tenga algunas decenas de correos pendientes en un instante dado, pero ayer había mas de 4000 correos en la cola, pendientes de su envío, algo totalmente fuera de lo común.

Eché un vistazo a la cola con el comando “mailq”, y el resultado fue desalentador:

[crayon-5bf4c71a947c2436554279/]

Y así hasta 4000 correos y aumentando cada segundo. Demasiados intentos de enviar correo a direcciones de Rusia para mi gusto.

Inicialmente borre la cola de postfix con el comando

[crayon-5bf4c71a947d1043303820/]

de ahí que en la gráfica se vez un brusco descenso del numero de correos, pero esto no supuso ni siquiera un alivio temporal, ya que en pocas horas volvía a tener varios miles de correos en cola (hasta 14.000).

En el volcado del comando mailq, pudimos ver que el usuario que enviaba los correos era el usuario de ubuntu “www-data”, bajo el cual se ejecuta normalmente el servidor web Apache. Por lo tanto, todo parecía indicar, que alguien había subido un script a alguno de los sitios alojados en el servidor, quizás aprovechando un exploit, y estaba usando mi servidor para enviar spam masivo. La pregunta es, ¿como localizar el script php que esta enviando los correos?

Recientemente, con la versión de PHP 5.3, hay una novedad que nos facilita mucho saber que script de PHP está actuando como spammer en nuestro servidor. Concretamente, consiste en añadir las siguientes lineas a nuestro fichero php.ini (normalmente descomentarlas, ya que ya estarán presentes):

[crayon-5bf4c71a947d6591494868/]

Lo que hace la primera sentencia, es añadir una cabecera a todo email saliente, que incluye el UID y el nombre del fichero del script que ha enviado el correo.

La segunda linea, se encarga de guardar en un fichero log, cada vez que se envía un correo, dicha cabecera. Es importante crear el archivo si no existía, y asegurarse de que el usuario “www-data” tiene permisos de escritura sobre dicho archivo.

Una vez añadidas las dos nuevas lineas en nuestro fichero php (en Ubuntu, localizado normalmente en /etc/php5/apache/php.ini), reiniciamos nuestro servidor web apache para que tenga en cuenta nuestra nueva configuración (apache2ctl graceful).

Inmediatamente empecé a ver en el fichero phpmail.log, el origen de los envíos de spam:

[crayon-5bf4c71a947d9209038030/]

Haciendo un tail -F sobre el fichero /var/log/phpmail.log, apreciamos que el ritmo de envío de spam era vertiginoso, no se podía leer el fichero log de lo rápido que era el desplazamiento. Así que para poder trabajar cómodamente, y como el sitio web no era critico, decidimos desactivarlo temporalmente para interrumpir el envio de spam:

[crayon-5bf4c71a947dd105317584/]

Con esto conseguimos interrumpir el envío masivo de correos. Una vez hecha una copia de seguridad del sitio, por si acaso se nos va la mano durante la desinfección, observamos que todo el árbol de directorios del mismo estaba infestado por scripts php de origen extraño. Se trata de una instalación antigua de Joomla, que por motivos técnicos no puede ser actualizada, y suponemos que los spammers conocen bien los exploits para subir scripts maliciosos en esta versión.

Examinando el código fuente de los ficheros sospechosos, vemos que efectivamente, son scripts que envían correo de manera masiva. Algunos ficheros son fácilmente identificables, y los borramos manualmente, pero para otros, decidimos utilizar el antivirus de Linux Clamav.

La manera de instalarlo no podría ser más sencilla:

[crayon-5bf4c71a947e0880541384/]

Si planeamos usarlo de manera automática ejecutándose como un demonio, tendremos que instalar

[crayon-5bf4c71a947e3134895725/]

En ambos casos el comando “freshclam” se usa para actualizar la base de datos del antivirus con la ultima versión.

Una vez instalado y actualizado, para escanear nuestro servidor:

[crayon-5bf4c71a947e6768558447/]

O si queremos escanear todo el servidor:

[crayon-5bf4c71a947e9646258235/]

Con esto nuestro sitio web infectado debería quedar mejor que antes. Es recomendable en estos casos, actualizar en cuanto se pueda la versión del software que tengamos para ese sitio web, o si no es posible, realizar alguna otra actuación que permita asegurar el sitio.

En nuestro caso, no es posible por motivos técnicos y deseos del cliente, subir la versión de Joomla a otra mas reciente / segura. Así que hemos optado por una solución numantina: proteger la carpeta y todas sus subcarpetas contra escritura. Esto es factible en el caso actual, que la web no puede ser actualizada, pero tampoco es utilizada, simplemente permanece ahí como reliquia “on line”. Pero en otros escenarios, lo mas probable es que no sea una solución válida.

Solo queda reactivar el sitio web, y vigilar el phpmail.log y el mail.log para comprobar que el envío de spam ha remitido.

[crayon-5bf4c71a947ec903977669/]

Ya podemos observar en el grafico de Munin como se normaliza la cola de Postfix:

Postfix normalizado
Postfix normalizado