Octubre Rojo. Análisis del vector de distribución de exploit para Java

A partir de la publicación de nuestro informe, nuestros colegas de Seculert han descubierto y escrito un blog sobre el uso de otro vector de distribución en los ataques de Octubre Rojo (http://blog.seculert.com/2013/01/operation-red-october-java-angle.html).

Además de los documentos de Office (CVE-2009-3129, CVE-2010-3333, CVE-2012-0158), al parecer los atacantes también penetraron las redes de sus víctimas a través de una vulnerabilidad en Java (MD5: 35f1572eb7759cb7a66ca459c093e8a1 – ‘NewsFinder.jar’), conocida como el exploit ‘Rhino’ (CVE-2011-3544).

Conocemos el cronograma de aplicación de esta técnica de principios de febrero de 2012, y el uso de este exploit coincide con su enfoque de que no se trata de un día-cero. Es muy posible que a las víctimas potenciales se les haya enviado un enlace a este sitio, y que los sistemas de las víctimas estuviesen ejecutando una versión desactualizada de Java.

Sin embargo, parece que el grupo no hizo un uso intenso de este vector. Cuando descargamos el php responsable de servir al archivo comprimido malicioso ‘.jar’, había comentarios en la línea de códigos que distribuía el exploit de java. Asimismo, los enlaces relacionados, java, y la carga ejecutable han resultado difíciles de rastrear hasta la fecha.

El dominio involucrado en el ataque apareció sólo en una caja de arena pública en malwr.com (http://malwr.com/analysis/c3b0d1403ba35c3aba8f4529f43fb300/), y sólo el 14 de febrero, el mismo día en que registraron el dominio hotinfonews.com.

Tras ese rápido descubrimiento público, los MD5s y los enlaces relacionados no aparecieron en depósitos públicos o privados, a diferencia de muchos otros de los componentes de Octubre Rojo.

Podría especularse que el grupo distribuyó con éxito su carga de programas maliciosos a los blancos apropiados durante algunos días, y que después ya no necesitaron hacerlo. Esto también nos dice que este grupo, que meticulosamente adaptó y desarrolló sus herramientas de infiltración y recopilación al ambiente de sus víctimas, tuvo la necesidad de migrar a Java desde sus habituales técnicas spearphishing a principios de enero de 2012. Y después volvieron a ellas.

También vale la pena notar que había un registro de tres sistemas de víctimas independientes detrás de una dirección IP en EE.UU., cada uno de los cuales se conectaba con un instituto gubernamental de investigación económica en el Medio Oriente.

Entonces, este exploit Java Rhino parece haber tenido un uso limitado. Y, la funcionalidad PHP script incrustada en el lado del servidor que distribuía este archivo es muy diferente a la funcionalidad común y relacionada que hemos visto en el troyano puerta trasera usado en los cinco años de campaña.

Las rutinas de codificación mantenidas y distribuidas dentro del mismo exploit están configuradas de tal manera que la llave que se usa para decodificar las cadenas URL dentro de los exploits se distribuye dentro del mismo applet Java. Esta es nuestra rutina de codificación PHP usada para codificar la URL para descarga de contenidos:

Y esta es la función que incrusta el applet en la HTML, pasando la cadena URL codificada a través del parámetro ‘p’:

Este es el código dentro del applet que consume las cadenas codificadas y las utiliza. La funcionalidad resultante descarga el archivo desde la URL y la escribe en ‘javaln.exe’. Observemos que las variables strb y stra mantienen las mismas cadenas que las variables $files y $charset en el script PHP:

Esta rutina de decodificación de “transferencia” retorna una URL que está concatenada con otras variables, dando como resultado “hXXp://www.hotinfonews.com/news/dailynews2.php?id=&t=win”. Es este contenido el que se escribe en el disco y se ejecuta en el equipo de la víctima. A continuación ofrecemos una descripción del descargador. Resulta muy interesante que la rutina de codificación de esta combinación exploit/PHP sea distinta a la ofuscación tan habitual en los módulos de Octubre Rojo. Sugiere además que es muy probable que este paquete de uso limitado se haya desarrollado aparte del resto para un blanco específico.

Segunda etapa del ataque: EXE, descargador

La segunda etapa del ataque se descarga desde “http://www.hotinfonews.com/news/dailynews2.php” y la ejecuta la carga del exploit Java. Funciona como un descargador para la siguiente etapa del ataque.

Locación conocida del archivo: %TEMP%javaln.exe
MD5: c3b0d1403ba35c3aba8f4529f43fb300

Este es un archivo PE EXE. Compilado con Microsoft Visual Studio 2008 en fecha 06.02.2012. El archivo está protegido por una capa de ofuscación, la misma que usan muchos módulos de Octubre Rojo.

Capa de ofuscación desensamblada

El módulo crea un mutex llamado “MtxJavaUpdateSln” y lo abandona si ya está creado.
Posteriormente, duerme por 79 segundos y después crea uno de los siguientes valores de registro que se cargarán automáticamente al arrancar el equipo:

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRun] JavaUpdateSln=%full path to own executable%

A continuación, tras una pausa de 49 segundos, ingresa en un bucle infinito buscando conectarse a Internet. Cada 67 segundos envía una petición HTTP POST a los siguientes sitios:

• www.microsoft.com
• update.microsoft.com
• www.google.com

Una vez que se establece una conexión válida con Internet, continúa con su bucle principal.

Bucle de conexión al servidor de comando y control

Cada 180 segundos el módulo envía una petición HTTP POST a su servidor de comando y control.
Esta petición se envía a una URL codificada: www.dailyinfonews.net/reportdatas.php

Los contenidos de la petición POST tienen el siguiente formato:

id=%ID de usuario único, recuperada de la superposición del archivo%&
A=%entero, indica si la llave de registro autorun estaba escrita%&
B=%0 o 1, indica si el usuario tiene autorización%&
C=%entero, nivel de privilegios asignados al usuario actual%

Petición HTTP POST enviada al servidor de comando y control

El módulo decodifica la respuesta del ser4vidor de comando y control con un algoritmo AMPRNG mediante una llave codificada. Después, verifica si es una firma EXE válida (“MZ”) en offset 37 en el buffer decodificado. Si existe esta firma, escribe el archivo EXE en “%TEMP%nvsvc%p%p.exe” (%p depende del tiempo del sistema) y lo ejecuta.

Tercera etapa del ataque: EXE, desconocido

Actualmente, el servidor de comando y control no está disponible y no contamos con los ejecutables que el descargador “javaln.exe” usó. Muy probablemente, fueron los mismos droppers, similares a los que usan los exploits para Word y Excel.

Conclusión

A medida que se cuenta con más información sobre Octubre Rojo y que terceras partes publican sus propias investigaciones sobre los ataques, se hace más evidente que el alcance de la operación es mayor a lo que se pensó en un principio.

Además del exploit Java que hemos presentado aquí, es posible que se hayan usado otros mecanismos de distribución durante los cinco años en que ha estado activa esta pandilla. Por ejemplo, no hemos visto todavía ningún exploit para PDF, que son muy comunes en otros grupos; algo muy raro.

Seguiremos monitoreando la situación y publicando actualizaciones a medida que se vayan desvelando los hechos.