La visita de un viejo amigo: Counter.php

Hace como un año, publiqué algo sobre los entonces ataques web más comunes en España y el malware responsable. ¡Ha llegado la hora de una actualización!

De forma regular, recolectamos datos sobre los sitios web infectados, basándonos en nuestras detecciones de la Kaspersky Security Network (KSN). En los últimos meses, ha llamado mi atención un programa que se ha instalado en el Top 3 junto con los veredictos que suelen encontrarse en esta clasificación: Trojan.JS.Iframe.aeq.
Este veredicto era muy popular los últimos meses, en especial en sitios .ES. La detección demuestra que las víctimas están muy expandidas:

Pero, ¿qué es Trojan.JS.Iframe.aeq?

El nombre es bastante descriptivo, un código Javascript que redirige a la víctima creando un iframe. Esta es suficiente información para un veredicto, pero quería conocer los detalles. Entonces, echemos un vistazo a los sitios infectados. El código malicioso es obvio. Al final del código fuente del sitio web infectado, encontramos esto:

Counter.php tiene una larga historia de redirecciones maliciosas de muchos modos diferentes. En este caso, llama la atención que el iframe esté después de la etiqueta. Mi colega Micha-san descubrió un par de ejemplos en marzo, como puedes ver aquí . Es interesante que la mayoría de los sitios analizados en Japón también estaban alojados en España. En esos casos, Counter.php muestra algo así:

La redirección no te devuelve el código bajo ciertas condiciones, como veremos más adelante. La primera condición es que no se acceda dos veces desde la misma IP. Cuando se ejecuta (hay revisiones clásicas para evitar la ejecución en un entorno fuera del navegador) se traduce en:

Así se realiza la segunda redirección para el sitio del paquete de exploits con un identificador único.

El paquete de exploits

Esta es la primera vez que yo mismo encuentro un paquete de exploits Styx libre en la red. Aquí (en inglés) puedes encontrar más información sobre Styx. En esencia, ejecuta una función de script llamada PluginDetect para definir un perfil de la víctima:

Al final del HTML encontramos el código para seleccionar el exploit:

para complicar las cosas un poco más, se hace referencia al elemento “gujny” mediante un iframe:

y contiene:

al combinar este contenido con el código de llamada, obtenemos:

y ahora todo tiene más sentido. Dependiendo de la versión de Java detectada por la función PluginDetect, escoge el exploit necesario en jorg.html (versiones [5-6.32] o [7-7.09]), jlpn.html (versiones [7.1-7.21]) o pdfx.html para el resto (exploit que no es para Java).

Los exploits

El análisis de nuestros colegas de McAfee indica que las vulnerabilidades que se explotan son:

• ?jorg.html CVE-2013-0422
• ?jlnp.html CVE-2013-2423
• ?pdfx.html loads ?fnts.html CVE-2011-3402
• ?jovf.html CVE-2013-1493
• and downloads a .pdf file CVE-2010-0188

Podemos confirmar que jorg.html explotaba la vulnerabilidad CVE-2013-0422, pero no analizamos el paquete en profundidad (en las otras vulnerabilidades). Aquí puedes ver un análisis muy interesante de esta vulnerabilidad cuando apareció suelta en la red como una vulnerabilidad de día cero. Este es el subprograma que se descarga con el parámetro para descargar el binario:

No fue fácil analizar el subprograma, ya que ningún descompilador de Java puede tratarlo, pero pronto estarán los resultados de mi investigación en el sector de análisis de Viruslist. Es interesante que sólo Kaspersky Lab detectó el subprograma (según Virus Total y al momento del análisis) gracias a la tecnología de Prevención Anti Exploits.

Todos los exploits atacan vulnerabilidades recientes, lo que es preocupante. Echemos un vistazo a su popularidad y sus blancos principales de acuerdo a nuestras estadísticas:

• CVE-2013-2423 Oracle java v This is the most common vulnerability according to KSN
• CVE-2013-0422 Oracle java v 11th most common vulnerability
• CVE-2011-3402 Win32 TrueType v not in the top 20
• CVE-2013-1493 Oracle java v 9th most common vulnerability
• CVE-2010-0188 Adobe Reader v not in the top 20

Estos datos nos preocupan aún más, ya que indican que este paquete explota la vulnerabilidad más común.

La infección

¿Cómo se infectaron los sitios que distribuyen este malware? Como dijimos al principio, counter.php tiene una larga historia de apariciones maliciosas, pero cambia su infraestructura, iframes y código javascript a menudo. Todos los sitios infectados (con una cantidad sorprendente alojada en España) ejecutan tecnologías diferentes, están alojados en proveedores distintos y al parecer no tienen nada en común. Por eso me puse en contacto con las compañías de alojamiento para que me dieran más detalles. Tenía sospechas de una vulnerabilidad en un programa como Plesk (había uno el pasado mayo y se encontró una vulnerabilidad de día cero en junio), WordPress o algo por el estilo. Después de revisar las evidencias con las compañías de alojamiento, creemos que las cuentas FTP de los usuarios de los sitios web estaban comprometidas. No sabemos cómo, pero puede que hayan robado estos datos hace meses o hasta años.

Las compañías de alojamiento colaboraron con nosotros (¡gracias!) y compartieron el famoso counter.php, a donde se dirige a todos los usuarios en primera instancia.

Echemos un vistazo:

Se traduce a esto. Es curioso que diferentes funciones y cadenas de caracteres se guardan en matrices de base64:

Ahora vemos más detalles de la estructura global. Después de dirigir a los usuarios a counter.php, se los vuelve a redirigir, esta vez a stat.php, no sin antes revisar que el usuario que hizo la solicitud no tenga google, bing, yahoo, baidu, msn (evasión de motores de búsqueda) u opera, safari o chrome (selección de navegador). Esta segunda redirección a stat.php tiene los siguientes parámetros:

hXXp://globalbrowserstatistic.com/statG/stat.php?
ip=YOUR_IP
&useragent=mozilla%2F4.0%20(compatible%3B%20msie%207.0%3B%20windows%20nt%206.0)
&domainname=REFERER_DOMAIN
&fullpath= REFERER_FULL_PATH
&check=0

Counter.php filtraba las solicitudes al paquete de exploit para evitar reinfecciones. Como stat.php no revisa que el parámetro IP sea la dirección remota, ahora sabemos cómo crear solicitudes para conseguir ejemplares del paquete de exploits.

El malware

El malware se renueva constantemente para evadir la detección por firmas. En esencia, lo que hace es descargar un dropper muy bien empaquetado que, dependiendo de la ubicación geográfica de la IP, descarga un antivirus falso o ZeroAccess (por lo menos) en la segunda etapa. Mi colega Marta me ayudó con esta parte y pronto publicará el análisis del descargador.

Al parecer es de origen ruso, como se puede ver por el idioma que aparece en los metadatos:

FileDescription: Диспетчер синхронизации synchronization Manager
CompanyName: Корпорация Майкрософт Microsoft

Conclusiones

¿Por qué nos interesa analizar estas campañas masivas de APTs en estos días? Las campañas masivas son las que infectan a la mayor cantidad de usuarios, las descargas drive-by son una herramienta poderosa, y en este ejemplo podemos ver cómo los atacantes renuevan sus métodos a menudo para complicar su infraestructura y mejorar su código javascript para evitar que lo detecten. Es una reflexión de una estructura sólida que se renueva a sí misma para mantenerse en el negocio. Los nuevos ejemplares que se generan tienen un bajo nivel de detección y su infraestructura hace que sea difícil para los sistemas automáticos conseguir detalles en profundidad. Es otro veredicto al que nadie da un segundo vistazo (aunque hay excepciones, como en este caso particular). De todos modos, ten en mente que detectamos el paso inicial en el vector de infección, todo comenzó con un veredicto.

Por otro lado, ¿cómo obtuvieron los atacantes acceso a cientos de sitios web durante meses? Entre las vulnerabilidades de día cero y las inyecciones SQL hay una gran gama de métodos para escoger; en este caso particular creemos que usaron credenciales robadas. Y ahora la parte que me preocupa. ¿Por qué ni los dueños de los sitios infectados ni las compañías de alojamiento detectaron los sitios maliciosos? ¿Cuántos sitios infectados “abandonados” seguirán activos? Tomando en cuenta lo difícil que llega a ser hasta denunciar un incidente de seguridad y cómo se los ignora la mayoría de las veces, creemos que todavía no prestamos suficiente atención a la seguridad. El creciente número de sitios abandonados (o administrados de forma mediocre) es un ejemplo claro de lo rápido que la negligencia se vuelve en nuestra contra.