Análisis del malware CVE-2017-11826

Entre las vías de entrada de malware más comunes, se han identificado las campañas de SPAM como una de las principales. Normalmente estas campañas suelen incorporar un enlace malicioso o un fichero adjunto (generalmente, un documento ofimático que contiene una macro maliciosa).

En esta ocasión, el equipo de seguridad y privacidad de Gradiant ha obtenido y analizado una muestra de documento ofimático que, en lugar de incorporar una macro maliciosa, explota la vulnerabilidad 0-day identificada con CVE-2017-11826 cuyo parche se publicó el pasado 17 de octubre de 2017. El uso de este exploit permite al atacante ejecutar código malicioso sin interacción por parte del usuario.

Aunque siempre es difícil atribuir un ataque, las evidencias apuntan a que probablemente se trate de una botnet rusa alojada en un servidor estadounidense.

Análisis de la vulnerabilidad

En primer lugar, se han enumerado los objetos OLE incrustados en el fichero RTF adjunto al correo de la campaña de SPAM:

Concretamente, el exploit radica en el fichero “./word/document.xml” perteneciente al último objeto OLE de la ilustración anterior (objeto con id = 2).

Tras analizar el contenido del fichero, la vulnerabilidad explotada se ha clasificado como type confusion ya que tiene lugar en el objeto inesperado idmap situado justo después de la apertura de la etiqueta font produciendo el error en el analizador de OOXML. Adicionalmente, se ha observado que la vulnerabilidad requiere unas condiciones especiales que el atacante ha tenido en cuenta, es decir, ha declarado un objeto OLEObject justo antes de la etiqueta font y añadido un atributo name con el contenido lo suficientemente grande (mayor o igual a 32 Bytes después de la conversión que se realiza sobre el mismo de UTF-8 a Unicode).

Con el fin de analizar cómo aprovecha el atacante la vulnerabilidad, se han observado los bytes del atributo name de la etiqueta font, obteniendo la siguiente representación hexadecimal:

Los cuales, transformados a unicode y representarlos en big endian tal y como ocurre en el analizador de OOXML, resultan en la siguiente dirección de memoria: 0x088888EC

Como se puede apreciar en la siguiente imagen, cuando se produce el type confusion un puntero es desreferenciado obteniendo el contenido de dicha dirección de memoria, al cual el programa le suma 4 unidades y el flujo de ejecución se transfiere a la dirección resultante de dicha suma:

Análisis del exploit. Ejecución arbitraria de código

Para controlar el contenido de la dirección de memoria 0x088888EC los atacantes han utilizado la técnica heap spraying la cual consiste en rellenar una gran proporción de la memoria con la repetición de una secuencia de bytes (denominada spray), de manera que se maximicen las probabilidades de encontrar esa secuencia de bytes en memoria cuando su posición no se puede predecir de forma exacta. En este caso, la implementación de esta técnica ha consistido en una gran ristra de objetos ActiveX que importan el spray almacenado en el fichero activeX1.bin.

Como se puede apreciar en la siguiente imagen que muestra parte del contenido de activeX1.bin, el atacante ha realizado heap spraying de dos direcciones de memoria: a la que desea que apunte el puntero desreferenciado (0x088888EC) y el contenido que desea que haya en dicha posición de memoria (0x729440CB) que es una dirección perteneciente a la librería msvbvm60.dll decrementada en 4 unidades para compensar el incremento en 4 unidades realiza el código vulnerable del analizador de OOXML.

Los atacantes cargan la librería “msvbvm60.dll” mediante su código CLSID tal y como se ha resaltado en la siguiente imagen. Además, se ha observado que dicha librería se carga únicamente con el fin de hacer “ROP” sobre ella (ROP es una técnica de explotación de software que permite evadir ciertas protecciones, por ejemplo: la protección de regiones de memoria no ejecutables y la protección mediante código firmado) ya que esta librería tiene desactivadas las protecciones DEP y ASLR.

Mediante “ROP Gadgets” (grupos de instrucciones que permiten llevar a cabo la técnica ROP) existentes en la librería “msvbvm60.dll” el atacante consigue dar permisos de ejecución a la “shellcode” y redirigir el flujo de ejecución al comienzo de la misma.

Se ha observado que la shellcode simplemente descifra y ejecuta el malware embebido (una librería en formato Portable Executable) y consta de dos fases: La primera es lo que se conoce como “egg hunter”, es decir, un código que localiza y ejecuta otro código. En este caso, el “egg hunter” localiza la segunda parte de la shellcode en memoria, la descifra y salta a dicha segunda parte descifrada. La segunda parte busca la etiqueta 0xBABABABA (que es el marcador que el atacante ha utilizado para indicar la dirección en que empieza el malware) y aplica un descifrado XOR sobre todos los DWORDs que lo conforman utilizando la clave 0xCAFEBABE hasta llegar a la marca de fin de malware 0xBBBBBBBB. Por último, utiliza la clave 0xBAADF00D para descifrar el documento que reemplazará al original.

Como suele ocurrir generalmente en los ficheros de tipo Portable Executable, contiene muchos ceros. Por tanto, al cifrar con la clave estos ceros, la clave queda reflejada en el propio texto cifrado.

Como se puede observar en la imagen anterior, se han identificado múltiples apariciones de la DWORD 0xBEBAFECA, en little endian y, por tanto, 0xCAFEBABE es la clave XOR.

Haciendo uso de esta información, se ha desarrollado un script que realiza la extracción y descifrado del fichero embebido para su posterior análisis estático.

————————————————– INICIO CÓDIGO ———————————————–

#!/usr/bin/env python

# -*- coding: utf-8 -*-

DECODE_KEY=»CAFEBABE».decode(«hex»)

PE_START_TAG=»BA»*6

PE_END_TAG=»BB»*6

INPUT_FILE=»2.doc»

OUTPUT_FILE=»decoded.vir»

#It reads the document bytes

f=open(INPUT_FILE,»rb»)

bytes_doc=f.read()

f.close()

#It extracts the embebbed bynary file

pe_encoded=bytes_doc.split(PE_START_TAG.decode(«hex»))[1].split(PE_END_TAG.decode(«hex»))[0]

#It decrypts the embebbed file bytes

pe_decoded=»»

for pos in range(0,len(pe_encoded), 4):

try:

pe_decoded+=chr(ord(pe_encoded[pos])^ord(DECODE_KEY[(pos+3)%4]))

pe_decoded+=chr(ord(pe_encoded[pos+1])^ord(DECODE_KEY[(pos+2)%4]))

pe_decoded+=chr(ord(pe_encoded[pos+2])^ord(DECODE_KEY[(pos+1)%4]))

pe_decoded+=chr(ord(pe_encoded[pos+3])^ord(DECODE_KEY[pos%4]))

except IndexError:

pass

#It saves the embedded malware after its decryption

f=open(OUTPUT_FILE,»wb»)

f.write(pe_decoded)

f.close()

————————————————– FIN CÓDIGO ———————————————–

Análisis del malware

A continuación analizamos el malware resultante.

En primer lugar, se han identificado tres direcciones URL escritas directamente en el código que pertenecen al dominio mymyawady.com:

A continuación, se ha realizado una consulta whois sobre el dominio atacante, identificando que es de origen ruso y que fue creado durante el mes anterior a la compilación de la librería embebida en el documento.

Adicionalmente, se ha obtenido un histórico DNS del dominio, detectando que al día siguiente de la creación del mismo este apuntaba a una dirección IP estadounidense (45.77.46.81) de un proveedor de diversos servicios en la nube (hxxps://www.vultr.com/) que los atacantes utilizaban para alojar la carga maliciosa de este malware.

Se ha observado que el malware intenta descargar los dos ficheros CAB maliciosos alojados en el centro de comando y control (C&C) bajo los nombres: logo.jpg y readme.txt utilizando la siguiente función:

Los cuales guarda en rutas temporales:

Y descomprime en el mismo directorio utilizando la herramienta de sistema “expand.exe” con los parámetros que se observan en la imagen:

Por último, se ha identificado la ejecución de un fichero avgdate.exe que el malware espera haya resultado de la descompresión del CAB.

Además, la librería se mantiene en un bucle que se ejecuta con una frecuencia de 23 segundos hasta que consigue descargar alguno de estos dos malware CAB:

En cada iteración del bucle el malware recopila información del sistema.

Accede al registro de Windows para obtener el SID del usuario.

La cual posteriormente estructura atendiendo a la cadena de formato “aSidUserSCompu”:

Por ejemplo, en la siguiente imagen puede observarse una instancia del malware que ha completado dicha cadena con la información de una de nuestras máquinas del laboratorio incluyendo si ha podido o no descargar y ejecutar las muestras de malware alojadas en el C&C. Toda esta información formateada será enviada al “gate” mediante una petición “POST” sobre el parámetro “news” al que se le pasa el SID del usuario.

En la siguiente pantalla se puede observar la dirección URL del “gate” mencionado anteriormente:

Conclusiones

Nuestro equipo ha notado un ligero incremento en la cantidad de documentos ofimáticos maliciosos que no hacen uso de macros. Por ello, es tan importante mantener el software siempre actualizado.

Recomendamos consultar solamente aquellos documentos y enlaces que sean de confianza y, en caso de duda, contactar con el remitente utilizando un medio de comunicación seguro.

IOCs

• cb3429e608144909ef25df2605c24ec253b10b6e99cbb6657afa6b92e9f32fb5
• 9209946f3012a37509cb703f55c58b552361f76507acc4786f7b73f6c5092eae
• c6de846128c9ee10e7894af47c2855e1dc3c7c19f1db0c960f882ab60f522a2e
• cd4679c14349744b0e2bfa4d385afe49c9cb8540196f893f52c8f50c47cddbec
• hxxps://cdn1.mymyawady.com/x4/dll/logo.jpg
• hxxps://cdn2.mymyawady.com/x4/dll/readme.txt
• hxxps://cdn3.mymyawady.com/x4/dll/info.php

Autor: David Álvarez Pérez, investigador del equipo de Seguridad y Privacidad de Gradiant