Sucedió hace unas semanas. Recibo la llamada de un cliente preocupado, en la que me dice que algo raro está pasando en dos de sus servidores, que las colas de los procesos de correo se han vuelto locos y que están brutalmente sobrecargados. Se trata de una humilde empresa que da servicios de hosting web y correo a varios clientes a través de dos servidores alquilados. Me envía las credenciales de acceso a los mismos, tanto para SSH como para Plesk.
Una vez conectado a las máquinas, y tras comprobar que la carga de las mismas no es excesivamente elevada, descargo un kit de herramientas para diagnosticar el problema. Mediante unhide, rkhunter y chkrootkit, veo que el sistema no muestra procesos ocultos ni malware conocido. La ejecución de unhide-tcp así como un nmap remoto completo, me deja ver que no hay sockets ocultos aparentes (me parecería extraño que hubiese algún malware que exigiese port knocking previo para activarse/desactivarse, aunque la idea es bastante buena). Por otra parte, el tipo de empresa, y la de sus clientes, no me pareció que fuesen a ser el objetivo de ninguna organización ni gobierno que quiera robar secretos nucleares, por lo que no me hago a la idea que vaya a ser muy complejo el mecanismo por el que le están atizando.
Sin embargo, las colas de correo siguen incrementándose más y más. La sangre no ha debido llegar al río suficientemente, puesto que amispammer no indica que las direcciones IP de mi cliente hayan sido incluídas en alguna lista antispam. Los logs de diferentes servicios no arrojan excesiva información, excepto el de qmail, que no para de mostrar montones de intentos de conexión a servidores de AOL, a los que no puede enviar determinados mensajes por no ser válidos los buzones buscados. ¿Pero esto de AOL no se había muerto ya hace años? Sin embargo, con un simple "top" observo que se ejecuta frecuentemente un mismo cgi en php. No veo un aumento significativo de recursos cada vez que se ejecuta, pero por echarle un vistazo, nada pierdo, ¿verdad?
Pues touché… según edito el fichero, me encuentro con un script php en una única línea, que claramente han ofuscado. ¿Adivináis la ruta? Dentro de un directorio con plugins para joomla de uno de los dominios clientes de hosting. En concreto en /components/com_content/newso2p.php y /components/com_content/statgpZO.php, con idéntico contenido.
Probé a subirlo a virustotal, y oh sorpresa, aparecía referenciado por muy pocos antimalware. En concreto, los únicos que lo detectaban eran ClamAV, DrWeb, Sophos, Trendmicro y VBA32…
Entre otras acciones, como borrar los ficheros en concreto, le propuse al cliente que actualizara Joomla y sus componentes, eliminara los plugins inútiles, etc, etc, dentro de lo que el panel de hosting le permite.
A partir de aquí caben dos preguntas. ¿Cómo ha llegado ese PHP ahí? ¿Y qué es lo que hace?
La primera de las preguntas parece de fácil respuesta: dado que el fichero tenía como dueño el usuario de Apache, y dado el lugar donde estaba, tiene toda la pinta que por alguna vulnerabilidad de Joomla! que permita escribir ficheros en sus directorios de plugins o componentes.
¿Qué hace el "malware"?
Como indiqué más arriba, el código PHP está ofuscado y, en una sola línea, hace bastante incómoda su lectura:
Por no liarme a buscar el ofuscador utilizado para este script, usé mi manido Perl para dejarlo de una forma más legible. Me hice un script quick & dirty que me permitiese pre-procesarlo:
Con lo que me queda en out.php, la idea era identificar las diversas variables del fichero, y cambiarlas por un valor más sencillo de ver, como por ejemplo $a en vez de $v1cb251ec, f1 en vez de n9a2d8ce3 para los nombres de funciones, etc,… Aproveché a eliminar funciones que no eran llamadas nunca, que simplemente confundían más al análisis.
Con lo que me queda en out.php, la idea era identificar las diversas variables del fichero, y cambiarlas por un valor más sencillo de ver, como por ejemplo $a en vez de $v1cb251ec, f1 en vez de n9a2d8ce3 para los nombres de funciones, etc,… Aproveché a eliminar funciones que no eran llamadas nunca, que simplemente confundían más al análisis.
Así, el script PHP quedaría de esta manera:
Fundamentalmente, el atacante, simplemente tenía que hacer llamadas a este PHP, mediante el método HTTP POST y en el POST DATA enviaba en varios campos diferentes la información necesaria para construir los correos: origen, destino, subject y cuerpo.
Inicialmente, estos datos vienen codificados en Base64 y se descodifican en tiempo de ejecución. Por otra parte, se procesa en el código, una lista con las direcciones de correo destino, que viene también en la llamada. Se establecen las cabeceras necesarias del correo y el propio bicho busca si hay servidor de correo en localhost. Si lo hay, lo usa, y si no lo hay resuelve él mismo los registros MX de los correos que recibirán el spam y les abre un socket al puerto 25, estableciendo una comunicación SMTP, enchufándoles el contenido con cabeceras del correo generado.
Conclusiones
- Pese a no ser un troyano muy mediático, el script está suficientemente bien hecho para que llame poco la atención dentro del sistema. No consume muchos recursos, ya que envía correos según se le hacen llamadas desde fuera, y en una sola llamada puede generar la ejecución de muchos correos de spam a la vez.
- Los logs que deja no son muchos, debido a que al ser con POST, no quedan datos almacenados por los parámetros que tendría si se hiciese mediante GET.
- Además, si da algún error la llamada POST, tampoco deja rastro, puesto que lo primero que hace en su ejecución, es deshabilitar cualquier tipo de traza así: "@error_reporting(0); @ini_set('error_log', NULL); @ini_set('log_errors',0); "
- En cualquier caso, y supongo que para evitar WAFs o algunos IPS que analicen las llamadas HTTP, codifica los parámetros en base64. De esta manera evitas la detección de los ingredientes necesarios para construir correos con spam en base a patrones.
- En este caso, quien se quejaba, era el sistema de monitorización de procesos del hosting, en los que el administrador veía que las estadísticas de envío de correo no eran normales, para lo que estaban acostumbrados a ver.
- Es interesante que se comunica con el atacante (o con el bot que lo ejecuta) mediante códigos OK + el md5 de "1234567890" cuando es correcto y un código de estado + el md5 de "0987654321" cuando es incorrecto.
- Los logs generados por Qmail se dispararon también en tamaño y un tcpdump del puerto 25 era como ver pasar las letras de Matrix pero a alta velocidad.
