Cuando un usuario visita cierta página maliciosa el exploit kit se encarga de probar diferentes exploits para, normalmente, instalar algún tipo de código malicioso en su ordenador. Según un estudio de Kaspersky Lab, SEO Sploit Pack y Crimepack son dos de los exploit kits que han surgido a principios de este año, y las vulnerabilidades de PDF y Java son las más utilizadas en estos kits. Para ver de primera mano este peligro voy a analizar un PDF malicioso descargado de un SEO Sploit Pack, usando peepdf como herramienta de análisis.
El archivo PDF en concreto, llamado kissasszod.pdf y descargado desde hxxp://marinada3.com/88/eatavayinquisitive.php, tenía una tasa de detección muy baja en su momento (4/40). Veamos qué es lo que tiene dentro:
Rápidamente vemos que hay código Javascript en el objeto 8 y que se usa el formulario /AcroForm para ejecutar “algo” al abrir el documento. El siguiente paso sería obtener más información sobre estos objetos y ver qué se quiere ejecutar:
Vemos que el objeto 8 se encuentra dentro del array /XFA del /AcroForm y que el elemento al que se va a hacer referencia, mirando las etiquetas de los diferentes elementos que cuelgan de /Fields, es yomRote[0].grueLox[0].khfdskjfh[0]. Ahora miramos qué hay exactamente en el objeto 8, que contiene código Javascript:
Las etiquetas que hemos visto bajo el elemento /Fields indican qué elemento estará contenido en el formulario: yomRote[0].grueLox[0].khfdskjfh[0]. Si nos fijamos, los nombres yomRote y grueLox son subforms de la plantilla (template) que contiene el objeto 8. Dentro del subformulario grueLox tenemos un campo (field) llamado khfdskjfh, que a su vez contiene el código Javascript. Por lo que sabemos a ciencia cierta que este código será ejecutado:
En este script se pretende ofuscar la ejecución de la función eval (línea 5), por lo que podríamos sustiuir brtd por eval en el script para verlo un poco más claro. Como se puede ver en la línea 24, se está ejecutando mediante eval lo devuelto por la función oerz. Ésta coge como argumentos el contenido del elemento khfdskjfh (a partir del carácter número 50) y la propia función eval. ¿Pero dónde está el contenido de khfdskjfh? En el objeto 8 se define la estructura del formulario, pero no está definido el contenido de esta variable, que debería encontrarse colgando de un elemento xfa:datasets. Si echamos un vistazo al resto de los objetos del array /XFA...
El objeto 10 es el ganador. En él podemos encontrar el contenido del campo khfdskjfh, que parecen ser dos arrays, el primero, un array de arrays, y el segundo, un array de números. Viendo la función oerz podemos entender qué es lo que se hace con estos arrays. Se le pasa como primer argumento el segundo array, que se almacenará en la variable axzr, y en la variable uyj se guarda el primer array. Posteriormente en yjf se guardan los caracteres cuyos valores decimales van entre 32-48, 65-97, 48-64, 10-11, 13-14 y 97-126 (primer array). Por último, en la variable tash se guarda el resultado final de usar el segundo array (axzr) como array de índices de yjf. Vamos a tener que hacer varias modificaciones en el código porque al Spidermonkey de peepdf no le gusta el código tal y como está. Una vez hechos los cambios se puede ejecutar correctamente:
El resultado es una segunda etapa de código Javascript:
El objeto 10 es el ganador. En él podemos encontrar el contenido del campo khfdskjfh, que parecen ser dos arrays, el primero, un array de arrays, y el segundo, un array de números. Viendo la función oerz podemos entender qué es lo que se hace con estos arrays. Se le pasa como primer argumento el segundo array, que se almacenará en la variable axzr, y en la variable uyj se guarda el primer array. Posteriormente en yjf se guardan los caracteres cuyos valores decimales van entre 32-48, 65-97, 48-64, 10-11, 13-14 y 97-126 (primer array). Por último, en la variable tash se guarda el resultado final de usar el segundo array (axzr) como array de índices de yjf. Vamos a tener que hacer varias modificaciones en el código porque al Spidermonkey de peepdf no le gusta el código tal y como está. Una vez hechos los cambios se puede ejecutar correctamente:
El resultado es una segunda etapa de código Javascript:
En este segundo código se ejecuta la función _X, que asigna un valor codificado en base64 dependiente de la versión de Acrobat Reader (línea 45) al elemento khfdskjfh (línea 59). Si decodificamos el contenido nos encontramos con una imagen en formato TIFF:
Este punto es el trigger de la vulnerabilidad CVE-2010-0188. Justo antes, se pasa como argumento la shellcode a la función _L, que se encarga del heap spraying. La variable _ET (línea 57) es la que contiene la shellcode escapada, de la que podemos obtener los bytes sin escapar mediante los siguientes comandos:
Se puede intuir que el objetivo de la shellcode es descargarse desde la URL encontrada algún tipo de malware, aunque no se puede ver ninguna función claramente. En este caso no nos valdrá con el comando sctest, por lo que vamos a obtener un exe con shellcode2exe de Mario Vilas y echar un vistazo en el debugger:
