La siguiente publicación es una traducción y adaptación del post “Linux/Cdorked.A malware: Lighttpd and nginx web servers also affected” escrito por Marc-Etienne M. Léveillé y publicado en We Live Security.
Nuestra investigación sobre este código malicioso continúa. Después de publicar los primeros hallazgos en el post Linux/Cdorked.A: nuevo backdoor Apache utilizado masivamente para propagar Blackhole, hemos descubierto algunos aspectos muy significativos:
- El troyano ha sido aplicado a otros demonios de servidores web. Gracias a la información provista por administradores de sistemas infectados, pudimos analizar versiones “troyanizadas” de otros webservers como Lighttpd y nginx.
- De acuerdo a nuestra información estadística, esta operación se ha llevado a cabo desde diciembre de 2012.
- Linux/Cdorked.A posee más técnicas de ocultamiento de las que creíamos. Analizando la forma en que los atacantes configuran este backdoor, pudimos determinar que no se redirige al usuario a contenido malicioso si el rango de la dirección IP del mismo se encuentra dentro de una extensa lista negra. Asimismo, tampoco se redirecciona a la víctima si el navegador se encuentra configurado en japonés, finlandés, ruso, ucraniano, kazajo (Kazajistán) y bielorruso.
- Nuestra información estadística también muestra que existen más de 400 servidores web infectados con Cdorked. De estos, 50 pertenecen a los 100.000 sitios más populares de acuerdo a Alexa.
- En algunas de las configuraciones que pudimos analizar, existían redirecciones específicamente configuradas para usuarios de iPad y iPhone.
En este post, entregaremos más detalles sobre las funcionalidades de este backdoor. También describiremos las configuraciones típicas que pudimos observar y el payload malicioso que se utilizaba para afectar a las víctimas. En un escenario típico, las víctimas son redirigidas a un sitio malicioso que utiliza Blackhole, sin embargo, también descubrimos que esta infraestructura maliciosa utiliza DNS hijacking, algo poco usual. En la última parte de este post profundizaremos sobre dicha técnica.
Antes de ahondar en el tema, aprovechamos de aclarar que desconocemos cómo Linux/Cdorked ingresó a los servidores web. Creemos que hubo más de un vector de propagación y que no se puedes atribuir exclusivamente a cPanel. Esto debido a que solo algunos de los servidores investigados utilizan ese programa de administración. Lo que sí está claro es que este malware no se propaga por sí solo ni tampoco explota vulnerabilidades específicas. Linux/Cdorked es un backdoor controlado por cibercriminales para redirigir a las víctimas hacia sitios maliciosos. La siguiente imagen muestra el código assembler de las conexiones reversas utilizadas en los servidores Apache, Lighttpd y nginx:
El código de la amenaza parece igual en las tres variantes, sin embargo, los hooks de la petición se encuentran dentro de una función distinta de acuerdo al servidor, y las estructuras también difieren. El atacante se tomó el tiempo necesario para crear una serie de parches para el código fuente de cada servidor afectado.
Capacidades de Linux/Cdorked
Nuestro análisis reveló más detalles sobre los comandos descritos en el post anterior. A continuación, se muestra una tabla con los comandos disponibles para controlar esta amenaza:
Todos esos comandos son almacenados en el área de memoria compartida detectada por nuestra herramienta. Esto posibilita que los atacantes sean muy precisos al momento de redireccionar a la víctima. Linux/Cdorked también mantiene una lista de las direccionesIP de usuarios a los que redirigió para evitar que dicha acción vuelva a ocurrir en un período corto de tiempo. Ninguna de estas configuraciones es guardada en el disco duro, sino que permanecen en memoria. El cibercriminal puede modificar estos parámetros a través de una petición HTTP enviada al servidor web comprometido.
Configuración típica de Linux/Cdorked
Gracias a la colaboración de administradores de sistema y Sucuri, pudimos obtener la región de memoria compartida utilizada por algunas infecciones de Linux/Cdorked. Tras analizar los archivos dump, nos percatamos que la configuración luce idéntica de un servidor a otro en un mismo período de tiempo. La siguiente captura muestra un ejemplo de un archivo de volcado:
En todos los casos, solo una URL fue establecida como redirección. No hemos observado ninguna configuración que incluya más de una URL. La redirección funciona en usuarios que visitan el sitio utilizando Internet Explorer o Firefox en Windows XP, Vista y 7. Las personas que utilizan un iPhone o iPad también son redirigidas, pero hacia sitios con contenido pornográfico. La siguiente captura muestra una redirección en un iPhone:
Los parámetros de configuración de Cdorked también incluyen una larga lista negra de rangos de direcciones IP. Los internautas de dichos rangos IP nunca serán redirigidos a sitios maliciosos. En la configuración que examinamos, un 50% del espacio de IPv4 es bloqueado aparentemente sin distinción de la ubicación geográfica. Asimismo, la configuración también contempla el bloqueo de usuarios basado en el idioma de la cabecera HTTP Accept-Language:
Creemos que los cibercriminales tras esta campaña de malware están haciendo esfuerzos significativos para pasar inadvertidos y complicar los análisis tanto como sea posible.
Estadísticas de redirección
Todas las redirecciones maliciosas tienen algo en común: la cadena “/info/last” en la ruta del sitio comprometido. Si nos basamos en dicha cadena, los primeros indicios de esta campaña datan del 24 de diciembre de 2012 y utilizaban los mismos patrones DNS. Tras analizar el tráfico web de los sitios afectados, pudimos identificar alrededor de 400 páginas afectadas por Cdorked. De esos sitios, 50 se encuentran dentro del ranking de las 100.000 páginas más populares según Alexa. El sitio comprometido más popular está dentro del top 2000 de portales más visitados de Internet. Algunas personas ya están desinfectando sus servidores después de que publicamos el primer análisis de este código malicioso. El siguiente gráfico muestra la cantidad de accesos por día a sitios comprometidos que incluyen la cadena /info/last:
Linux/Cdorked mantiene un timestamp de la última redirección realizada a la IP de cada víctima. Pudimos extraer la información de los archivos de volcado para estimar cuántas redirecciones realiza un único servidor por día. Vimos un servidor que redireccionaba 28.000 peticiones por día. También observamos que un servidor no está constantemente activo.
A continuación, se presentan dos gráficos. Cada uno muestra las redirecciones de un servidor por día:
El siguiente gráfico corresponde al segundo servidor analizado:
DNS hijacking
Las URL del servidor comprometido por Cdorked varían frecuentemente, sin embargo, notamos tres aspectos:
- El dominio casi siempre está formado por números, letras como a, b, c, y <tld>.
- Los subdominios siempre coincide con una cadena de 16 caracteres hexadecimales.
- El nombre de servidor de esos dominios cambia con menor frecuencia que los dominios en sí.
En base a lo anterior, analizamos el patrón de esos nombres de dominio que fueron utilizados para redirigir a los usuarios hacia sitios maliciosos. Primero, nos dimos cuenta que el número que aparece al principio de los dominios se deben simplemente a que el servicio de hospedaje de esos servidores es compartido, por lo tanto, cuando se ordenan alfabéticamente, el primero es asociado con la dirección IP de ese servidor. El formato particular de los subdominios y el hecho de que están constantemente cambiando nos permite inferir que los servidores DNS también están comprometidos. Realizamos algunas pruebas en donde se modificaron los caracteres del subdominio y en algunos casos, la IP de respuesta cambió. Haciendo más pruebas, pudimos confirmar que la IP devuelta por la petición DNS está codificada en el mismo subdominio. Está utilizando caracteres en posiciones extrañas para formar una cadena de 4 bytes hexadecimales de longitud para decodificar la dirección IP. Una cadena básica de cifrado XOR es utilizada para codificar la dirección IP:
El algoritmo decodificado luce así:
Debido a la naturaleza del comportamiento del algoritmo, creemos que los binarios del servidor DNS fueron modificados. Contactamos a los webhost afectados para notificarles sobre el problema.
Cadena de redirección
Cuando una víctima es redirigida por Cdorked, primero pasa por múltiples sitios antes de alcanzar la página que contiene Blackhole. La primera página es /index.php con un parámetro codificado en base64. En el siguiente ejemplo, el parámetro en base64 decodificado se ve así:
La página contiene el siguiente código Javascript:
El valor de b64 es provisto por el servidor y contiene algo como esto:
La siguiente URL está compuesta por tres partes: el subdominio inicial, el valor iflag y la URL provista por el servidor. El valor iflag indica si el documento está siendo visualizado en la primera ventana del navegador. En dichos casos, el servidor rechaza las peticiones. La parte del subdominio provista por el servidor también contiene el id scr de la URL inicial y timestamp. Aún no sabemos qué significan las otras partes:
La siguiente página, sort.php, establece un tiempo de espera que redirige a exit.php. A su vez, este devuelve un sitio con imágenes y enlaces hacia sitios pornográficos (todavía no está claro si esos dominios son maliciosos o un programa referrer). También inyecta un Iframe en la página de Blackhole:
Finalmente, si la explotación es satisfactoria, un código malicioso es descargado en el computador de la víctima. Nuestras pruebas indican que el malware instalado por Blackhole en este momento es Win32/Glupteba.G:
Desinfección
Como se mencionó en nuestro post anterior, recomendamos a los administradores de sistema comprobar la integridad de los servidores web utilizando sistemas de paquetes estándar. Asimismo, publicamos una herramienta para volcar el contenido de la memoria compartida en un archivo en caso de infección. Por otro lado, actualizamos dicha herramienta para que detecte todas las variantes conocidas incluyendo las que afectan a Lighttpd y nginx. Para los usuarios finales, recomendamos mantener actualizados los navegadores, extensiones, y programas de terceros como Java, lectores PDF y reproductores Flash con el objetivo de evitar una infección producto de esta campaña.
Un agradecimiento especial para Marc-Etienne M. Léveillé, Mathieu Lavoie, Benjamin Vanheuverzwijn, Sébastien Duquette y Pierre-Marc Bureau por participar de esta investigación.
Traducido y adaptado por André Goujon
Especialista de Awareness & Research
