Linux/Cdorked.A: nuevo backdoor para Apache que se está usando para propagar el malware Blackhole

El siguiente articulo es una adaptación del post publicado en el blog We Live Security de ESET por nuestro compañero Pierre-Marc Bureau.

La semana pasada, nuestros amigos de Sucuri nos enviaron una versión modificada  de un servidor web Apache que redirigía algunas de sus peticiones al infame kit de exploits Blackhole. Sucuri ha publicado un artículo en su blog hablando de este ataque.

Nuestro análisis de este malware, bautizado como Linux/Cdorked.A, revela que estamos ante un backdoor sofisticado y que sabe ocultarse, diseñado para dirigir el tráfico a sitios webs maliciosos. Instamos a los administradores de sistemas a que revisen sus servidores y verifiquen que no se encuentran afectados por esta amenaza. Más adelante veremos los pasos a realizar para realizar esta revisión (se puede encontrar más información acerca de Blackhole en el siguiente enlace).

De hecho, Linux/Cdorked.A es uno de los backdoors de Apache más sofisticados con los que nos hemos topado hasta ahora. A pesar de que aún nos encontramos procesando los datos, nuestro sistema Livegrid informa de cientos de servidores comprometidos. El backdoor no deja rastro de los hosts comprometidos en el disco duro, más allá del binario httpd, lo que complica el análisis forense. Toda la información relacionada con el backdoor se almacena en la memoria compartida. El atacante lanza la configuración a través de peticiones HTTP ofuscadas que no son registradas en los logs normales de Apache. Esto significa que no se almacena ninguna información en el sistema sobre centros de mando y control.

Análisis técnico de Linux/Cdorked

A continuación mostramos el primer análisis técnico de Linux/Cdorked, que parece estar afectando a cientos de servidores web en estos momentos. En el binario de Linux/Cdorked encontramos todas las cadenas sospechosas cifradas. Tal y como se muestra en la siguiente imagen, una función es responsable de descifrar las cadenas a petición con una clave XOR estática.

La versión de Linux/Cdorked que hemos analizado contiene un total de 70 cadenas que se encuentran codificadas de esta manera. Tal y como se muestra en la siguiente captura de pantalla, la clave usada para cifrar los datos es: 27A4E2DADAF183B51E3DA7F6C9E6239CDFC8A2E50A60E05F

Como hemos mencionado anteriormente, Linux/Cdorked no guarda ningún fichero en el disco. En su lugar, reserva alrededor de seis megabytes de memoria compartida para mantener la información de su estado y configuración. Este bloqueo de memoria, una región POSIX de memoria compartida (shm), se usa para todos los subprocesos de Apache, pero también puede ser accedida por otros procesos, ya que los autores de este malware no limitaron sus permisos. La siguiente captura de pantalla muestra los permisos (lectura, escritura para todos) asignados a la región de la memoria compartida.

Hay dos formas que el atacante puede utilizar para controlar el comportamiento de un servidor infectado: a través de una shell de conexión inversa o a través de comandos especiales, todos los cuales son activados vía peticiones HTTP.

El backdoor Linux/Cdorked.A

El servidor HTTP está equipado con un backdoor de conexión inversa que puede ser activado mediante una petición HTTP GET especial. Se le invoca cuando una petición a una ruta especial se realiza con una cadena de búsqueda en un formato en particular, conteniendo el nombre del host y el puerto al que se va a conectar. La dirección IP de un dialogo HTTP se usa como clave para descifrar la cadena de búsqueda como una clave XOR de 4 bytes. Adicionalmente, la IP especificada en las cabeceras X-Real-IP o X-Forwarded-For sobreescribirá tanto la IP del cliente como la clave XOR. Esto significa que podemos crear una cabecera X-Real-IP que será una clave “\x00\x00\x00\x00”. La cadena de búsqueda también necesita estar codificada en hexadecimal antes de enviarse.

Mientras que la shell es usada por el atacante, la conexión HTTP se cuelga (el código del backdoor no implementa la posibilidad de realizar un fork). Esto significa que las shells maliciosas pueden ser encontradas si se tiene acceso al servidor y se buscan conexiones HTTP de larga duración. Por otro lado, las peticiones HTTP no aparecen en el fichero de registro de Apache debido a la manera en la que este código malicioso se ancla en Apache.

Redirección en Linux/Cdorked.A

Cuando se redirecciona a un cliente, el malware añade una cadena codificada en base64 a la búsqueda que contiene información como la URL visitada inicialmente y si la petición fue o no originalmente un archivo javascript para que el servidor pueda descargar el malware adecuado.

Un ejemplo de redirección tiene este aspecto:

Location:hxxp://dcb84fc82e1f7b01.xxxxxxgsm.be/index.php?j=anM9MSZudmNiaW11Zj1jY3Zja3FqdSZ0aW1lPTEzMDQxNjE4M

jctMzYwNDUzNjUwJnNyYz0yMzImc3VybD13d3cuaW5mZWN0ZWRzZXJ2ZXIu

Y29tJnNwb3J0PTgwJmtleT0xM0Q5MDk1MCZzdXJpPS9mb3J1bS93Y2YvanMv

M3JkUGFydHkvcHJvdG9hY3Vsb3VzLjEuOC4yLm1pbi5qcw==

Tras descifrarlo, aparecen los siguientes parámetros:

js=1&nvcbimuf=ccvckqju&time=1304161827-360453650&src=232&surl=www.infectedserver.com&sport=80&key=13D90950&suri=/forum/wcf/js/3rdParty/protoaculous.1.8.2.min.js

El parámetro “surl” muestra el host infectado mientras que el “suri” indica cuál fue el recurso originalmente solicitado.

Tras la redirección, una cookie se establece en el cliente para que no sea redireccionado de nuevo. Esta cookie también se establece si se realiza una petición para una página que se parezca a una página de administración. El backdoor revisará si la URL, el nombre del servidor o el referrer coincide con alguna de las siguientes cadenas de texto: ‘*adm*’, ‘*webmaster*’, ‘*submit*’, ‘*stat*’, ‘*mrtg*’, ‘*webmin*’, ‘*cpanel*’, ‘*memb*’, ‘*bucks*’, ‘*bill*’, ‘*host*’, ‘*secur*’, ‘*support*’. Esto se realiza probablemente para evitar enviar contenido malicioso a los administradores del sitio web, haciendo que la infección sea más difícil de detectar. La siguiente captura de pantalla muestra parte del código responsable de manejar la cookie de la web.

Han de cumplirse unas cuantas condiciones adicionales antes de que se produzca la redirección. Por ejemplo, se busca la presencia de cabeceras Accept-Language, Accept-Encoding y Referrer.

Otros comandos de Linux/Cdorked.A

Encontramos 23 comandos en Linux/Cdorked.A que pueden enviarse al servidor vía POST a una URL especialmente diseñada. Esta petición debe contener una cabecera de la cookie que empiece por “SECID=”. El valor de la cadena de búsqueda debe contener 2 bytes codificados en hex que se encuentran cifrados con la IP del cliente, usando la misma técnica que la Shell. Los datos de la cookie SECID se usarán como argumentos para algunos de los comandos. Creemos que las URL para redireccionar a los clientes se envían al backdoor usando este método. La información de redirección se almacenará de forma cifrada en la región reservada de la memoria compartida. También creemos que las condiciones para la redirección se configuran de esta forma para, por ejemplo, preconfigurar una lista blanca de user agents para redireccionarlos y establecer una lista negra de IPS para evitar esta redirección.

Esta es la lista completa de comandos encontrados en el binario que hemos analizado: ‘DU’, ‘ST’, ‘T1′, ‘L1′, ‘D1′, ‘L2′, ‘D2′, ‘L3′, ‘D3′, ‘L4′, ‘D4′, ‘L5′, ‘D5′, ‘L6′, ‘D6′, ‘L7′, ‘D7′, ‘L8′, ‘D8′, ‘L9′, ‘D9′, ‘LA’, ‘DA’.

Finalmente, se envía información acerca del estado del backdoor de vuelta usando la cabecera ETag HTTP, tal y como se muestra en la captura de pantalla más abajo. Seguimos investigando el propósito de cada uno de los comandos y publicaremos nuestros resultados tan pronto como finalice el análisis. En resumen, todos ellos añaden contenido a, o lo eliminan de, la configuración en la región de la memoria compartida.

Eliminación de Linux/Cdorked.A

Tal y como hemos mencionado anteriormente, los permisos en la asignación de la memoria compartida son bastante vagos. Esto permite que otros procesos puedan acceder a la memoria. Hemos desarrollado una herramienta gratuita para permitir a los administradores de sistemas comprobar la presencia de la región en la memoria compartida y volcar su contenido a un archivo.

También recomendamos usar debsums para sistemas Debian y Ubuntu y rpm-verify para sistemas basados en RPM, para así comprobar la integridad de la instalación de su servidor Apache. No obstante, recordad aplicar esta medida con precaución puesto que el paquete puede haber sido alterado por un atacante.

Buscar por la presencia de este malware en la memoria compartida es el método recomendado para asegurarnos de que no estamos infectados. Asimismo, estamos interesados en recibir cualquier volcado de memoria para su análisis.

En el momento de escribir este artículo, el sistema de monitorización Livegrid de ESET muestra cientos de servidores web que parecen estar afectados por este backdoor, con miles de visitantes siendo redireccionados a contenido malicioso. Publicaremos más información acerca de la escala y complejidad de esta operación en los próximos días.

SHA1 del binario analizado: 24e3ebc0c5a28ba433dfa69c169a8dd90e05c429

Traducido y adaptado por Josep Albors