Un exploit dirigido

En septiembre, Microsoft compartió información sobre una nueva vulnerabilidad de Internet Explorer: CVE-2013-3893. La vulnerabilidad afecta a las versiones IE 6 a 11 para las plataformas Windows XP a Windows 8.1. Pocas semanas después, publicó un parche para solucionar el problema.

A los cibercriminales les gusta explotar estas vulnerabilidades porque esto implica dinero fácil: Internet Explorer sigue siendo un navegador muy común.

Top 5 de navegadores según http://gs.statcounter.com .

Este tipo de vulnerabilidad es muy peligroso porque permite la ejecución de códigos arbitrarios en el sistema de la víctima. A finales de septiembre, descubrimos un exploit para la vulnerabilidad, que emplea un ataque del tipo “use after free” contra el motor de conversión de HTML de Internet Explorer: mshtml.dll.

Hace poco descubrimos que se está usando una modificación del exploit en ataques dirigidos contra varias organizaciones de alto perfil en Japón.

Ataque dirigido

La vulnerabilidad se explota sólo en aquellos ordenadores que son parte de subredes específicas de las organizaciones afectadas:

Definición de las subredes en los equipos que sufrirán el ataque

Si la dirección IP de un equipo pertenece a alguno de los rangos definidos por los cibercriminales, la vulnerabilidad se explotará después de que el usuario visite una página web infectada.

La siguiente información se consigue en la primera etapa del ataque:

• Versión del sistema operativo
• Versión de Internet Explorer
• Idioma del sistema operativo
• Si tiene instalado Microsoft Office

El exploit selecciona la cadena de caracteres ROP y el código shell según la información que haya obtenido en esta etapa:

Selección de la cadena ROP y código shell

Vale la pena mencionar que el exploit no funcionará en aquellos sistemas Windows 7 que no tengan instalado Microsoft Office.

Revisión de la versión del OS y confirmación sobre si Microsoft Office está instalado o no

Esto se debe a que los sistemas operativos de hoy en día incluyen mecanismos que dificultan la explotación de vulnerabilidades. Uno de ellos es ASLR (Organización Aleatoria del Espacio de la Dirección). El exploit utiliza un truco muy ingenioso para evadir el mecanismo: carga la biblioteca hxds.dll, un módulo compilado sin compatibilidad con ASLR, en el contexto de los procesos del navegador.

Código después de que se ejecute el hxds.dll que se cargó

La biblioteca, que forma parte del paquete de Microsoft Office, no es compatible con ASLR. Se carga en direcciones conocidas en la memoria y los atacantes utilizan tecnología ROP para marcar como ejecutable la memoria que contiene el código shell.

El siguiente código Shell se ejecuta después de que se ha logrado explotar la vulnerabilidad:

La figura de arriba muestra que el código shell decodifica su parte principal usando 0x9F como llave.

Después de la decodificación, el código busca las funciones necesarias para descargar y ejecutar la carga explosiva, realizando la búsqueda con sus resúmenes criptográficos (hashes):

Hashes de las funciones usadas

Al terminar la búsqueda de las direcciones necesarias, se da el siguiente paso del ataque:

1. se descarga un objeto malicioso llamado “runrun.exe” del servidor del atacante:

Descargando la carga explosiva

2. Como el módulo que se descarga está codificado, el código Shell lo lee del disco y lo decodifica usando 0x95 como llave. Después, ejecuta el módulo decodificado.

Distribución del exploit

Como hemos mencionado arriba, el ataque dirigido usa sólo una modificación del exploit para CVE-2013-3893. Hasta ahora, se ha descubierto un total de 21 modificaciones. La mayoría de los ataques de este tipo se ha detectado en Taiwan:

Tenemos la siguiente información sobre los servidores desde donde se descarga la carga explosiva del exploit:

Un breve análisis de una de las variantes de la carga explosiva (md5 – 1b03e3de1ef3e7135fbf9d5ce7e7ccf6) mostró que el módulo ejecutable ha codificado los datos en sus recursos:

Datos codificados en los recursos de la carga explosiva

El módulo ejecutable extrae los datos y los transforma en un módulo DLL:

Extracción de los datos codificados

Se utiliza la siguiente ruta para escribir en el disco el DLL que se creó al transformar los datos extraídos de la carga explosiva:
TempPathtmp.dll (md5 – bf891c72e4c29cfbe533756ea5685314).

La biblioteca exporta las siguientes funciones:

Funciones que exporta tmp.dll

Cuando la biblioteca se ha escrito en el disco, se carga en el espacio de la dirección del proceso y se solicita la función de exportación ishk:

Solicitud de la función de exportación ishk

La biblioteca en sí misma realiza una inyección a otro espacio de dirección del proceso.

Después de su ejecución, el malware se comunica con un servidor de Corea del Norte. Desde el equipo infectado se envían las siguientes solicitudes:

Solicitudes enviadas desde el equipo infectado

Kaspersky Lab detecta la carga explosiva como Trojan-Dropper.Win32.Injector.jmli.

Detectamos el exploit como HEUR:Exploit.Script.Generic.