La siguiente publicación es una adaptación y traducción del post “Linux/Cdorked.A: New Apache backdoor being used in the wild to serve Blackhole” escrito por Pierre-Marc Bureau y publicado en We Live Security.
La semana pasada, nuestros amigos de Sucuri nos enviaron una versión modificada de un servidor web Apache que redirigía algunas de las peticiones hacia el paquete de exploits Blackhole. Detectado por los productos de ESET como Linux/Cdorked.A, el análisis de este malware reveló que se trata de un sofisticado backdoor (troyano de puerta trasera) que implementa técnicas de ocultamiento, y cuyo objetivo es redirigir el tráfico hacia sitios maliciosos. Considerando esto, recomendamos encarecidamente a los administradores de sistemas web comprobar que sus servidores se encuentren libres de esta amenaza. Las instrucciones para realizar este procedimiento se detallarán al final de este post.
Linux/Cdorked.A es uno de los backdoor para Apache más sofisticados que hemos observado. Pese a que aún continuamos procesando los datos, nuestro sistema de alerta temprana, ESET Live Grid, reporta cientos de servidores comprometidos, incluidos algunos en América Latina. Por otro lado, el troyano casi no deja rastros en el disco duro del sistema infectado. Lo único que queda es el binario httpd modificado, lo que dificulta cualquier análisis forense. Toda la información relacionada a este backdoor es almacenada en un área de memoria compartida. Asimismo, la configuración es enviada por el atacante a través de peticiones HTTP ofuscadas que no son registradas en el log de Apache. Esto significa que no se almacena ninguna información del Centro de Comando y Control en el sistema afectado.
Análisis técnico de Linux/Cdorked
En esta sección analizaremos técnicamente el troyano Linux/Cdorked, amenaza que está afectando cientos de servidores web en estos momentos. En el binario de Cdorked todas las cadenas importantes o sospechosas están cifradas. Como se muestra en la siguiente imagen, una función específica es responsable de descifrar la petición de las cadenas utilizando una llave estática XOR:
La variante de Linux/Cdorked que analizamos contiene un total de 70 cadenas que están cifradas de esa forma. Como se muestra en la siguiente captura, la llave utilizada para cifrar esta información es 27A4E2DADAF183B51E3DA7F6C9E6239CDFC8A2E50A60E05F:
Como se mencionó anteriormente, Linux/Cdorked no escribe ningún archivo en el disco duro, sino que asigna seis megabytes de memoria compartida para almacenar información de su estado y configuración. Este bloque de memoria, que es una región de memoria compartida POSIX, es utilizada por todos los subprocesos de Apache sin embargo, también puede ser accedida por cualquier otro proceso debido a que los autores del código malicioso no limitaron este permiso. A continuación se muestran los permisos de lectura y escritura asignados a la región de memoria compartida y todos los procesos:
Existen dos vías por las cuales un atacante puede controlar el comportamiento del servidor comprometido: a través de una shell por conexión reversa o mediante comandos especiales. Todos estos comandos funcionan por medio de peticiones HTTP.
Backdoor Linux/Cdorked.A
El servidor HTTP está equipado con un backdoor de conexión reversa que puede ser activado a través de una petición HTTP GET especial. Se activa cuando se realiza una petición de cadena en un formato particular que debe contener el nombre del servidor y el puerto a conectarse. La dirección IP del cliente HTTP es utilizada como una llave para descifrar la cadena enviada como una llave XOR de 4 bytes. Adicionalmente, la IP especificada en la cabecera X-Real-IP o X-Forwarded-For anula la IP del cliente como una llave XOR. Esto significa que es posible manipular la cabecera X-Real-IP que, en efecto, será una llave “x00x00x00x00”. Las peticiones de cadena también necesitan estar codificadas en hexadecimal antes de enviarse:
Mientras la shell es utilizada por el atacante, la conexión HTTP generada se bloquea debido a que la amenaza no implementa forking. Esto implica que las shells maliciosas pueden ser encontradas si se accede al servidor y se comprueban que existen conexiones HTTP por un largo período de tiempo . Por otro lado, las peticiones HTTP generadas por la amenaza no aparecen en el log de Apache debido al método de hook que utiliza el malware.
Redireccionamiento en Linux/Cdorked.A
Cuando se redirige a un cliente, el malware añade cadenas cifradas en base64 a las peticiones que contengan información como la URL que se pretendía visitar originalmente. Lo mismo ocurre si la petición fue concebida por medio de un archivo Javascript. De esta manera se permite ejecutar el payload adecuado:
Una redirección de ejemplo luce como esta:
Location: hxxp://dcb84fc82e1f7b01. xxxxxxgsm.be/index.php?j=anM9MSZudmNiaW11Zj1jY3
Zja3FqdSZ0aW1lPTEzMDQxNjE4MjctMzYwNDUzNjUwJnNyYz0yMzImc3VybD13d3cuaW5mZWN0ZWRzZXJ2
ZXIuY29tJnNwb3J0PTgwJmtleT0xM0Q5MDk1MCZzdXJpPS9mb3J1bS93Y2YvanMvM3JkUGFydHkvcHJvdG
9hY3Vsb3VzLjEuOC4yLm1pbi5qcw==
Después de descifrarla, 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 y “suri” indica cuál fue el recurso de la petición original. Después de la redirección, se instala una cookie en el cliente para evitar redirigirlo nuevamente. La cookie también se instala si se realiza una petición a un sitio de administración. Luego, el backdoor comprueba si la URL, el nombre del servidor, o el parámetro referrer coinciden con algunas de las siguientes cadenas: *adm*’, ‘*webmaster*’, ‘*submit*’, ‘*stat*’, ‘*mrtg*’, ‘*webmin*’, ‘*cpanel*’, ‘*memb*’, ‘*bucks*’, ‘*bill*’, ‘*host*’, ‘*secur*’, ‘*support*’. El malware realiza este procedimiento probablemente para dificultar la detección al evitar enviar contenido malicioso a administradores de sitios web. La siguiente captura muestra parte del código responsable de manipular la cookie:
Otras condiciones deben cumplirse antes de que la redirección suceda: se comprueba la presencia de Accept-Language, Accept-Encoding y la cabecera referrer.
Otros comandos de Linux/Cdorked.A
Encontramos 23 comandos en Linux/Cdorked.A que pueden ser enviados a la URL maliciosa utilizando una petición POST. Asimismo, la petición debe contener una cookie que comience por “SECID=”. El valor en la cadena de la petición debe poseer 2 bytes hexadecimales que son cifrados con la dirección IP del cliente utilizando la misma técnica de la shell. La información de la cookie SECID es utilizada como argumento para algunos de los comandos. Creemos que las URLs utilizadas para redirigir a los clientes son enviadas al backdoor utilizando este método. Los datos de redireccionamiento son almacenados de forma cifrada en la región asignada de memoria compartida. También creemos que las condiciones de redireccionamiento son establecidas de esta manera. Por ejemplo, una lista blanca de user agents para redireccionar a las víctimas y otra lista negra para evitar que esto suceda.
Esta es la lista completa de comandos que se pueden encontrar en el binario 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, algunos datos del estado del backdoor son devueltos en una cabecera HTTP ETag tal como lo muestra la siguiente imagen. Todavía estamos analizando el propósito de cada comando y publicaremos los resultados tan pronto la investigación haya concluido. En simples palabras, estos comandos son para agregar o remover contenido dentro del archivo de configuración:
Desinfección de Linux/Cdorked
Como se mencionó previamente, los permisos de asignación de memoria compartida pueden ser manipulados. Esto permite que otros procesos puedan acceder a este espacio. Hemos desarrollado una herramienta gratuita (dump_cdorked_config.c) que les permite a los administradores de sistema verificar la presencia de la región de memoria compartida y volcar el contenido en un archivo. También recomendamos utilizar "debsums" para Debian o Ubuntu, y "rpm-verify" para sistemas basados en RPM con el objetivo de verificar la integridad de los archivos de instalación de Apache (considerando que el manifest del paquete fue manipulado por el atacante). Pese a esto, verificar la presencia de la memoria compartida sigue siendo el modo recomendado para asegurarse de que el servidor no está infectado. Asimismo, estamos interesados en recibir cualquier volcado de memoria (memory dump) para analizarlo.
Al momento de escribir este post, el sistema de alerta temprana ESET Live Grid muestra cientos de servidores web que aparentemente están infectados con este código malicioso. Producto de lo anterior, son miles las víctimas que están siendo redirigidas hacia contenido malicioso. Publicaremos más información sobre la magnitud y complejidad de esta operación en los próximos días.
Actualización 02/05/2013: debido al descubrimiento de nuevas variantes de este malware, hemos actualizado la herramienta gratuita para obtener la memoria compartida que utiliza Linux/Cdorked. Recomendamos a todos los administradores ejecutar esta nueva versión programada en lenguaje C para comprobar si los servidores Apache se encuentran infectados con esta amenaza.
Traducido y adaptado por André Goujon
Especialista de Awareness & Research
