La más reciente explotación de Flash utilizada en Pawn Storm evita las Técnicas de Mitigación

El análisis que hicimos de la vulnerabilidad de día-cero de Adobe Flash utilizado en la campaña de Pawn Storm más reciente revela que las técnicas de mitigación anteriormente introducidas por Adobe no eran suficientes para asegurar a la plataforma.

Utilizada en Pawn Storm para atacar a ciertos ministerios de relaciones exteriores, la vulnerabilidad identificada como CVE-2015-7645 representa un cambio importante en las tácticas de las explotaciones anteriores. Es importante mencionar que Adobe ha liberado el boletín APSB15-27 para resolver esta vulnerabilidad; así, la versión más reciente de Flash (19.0.0.226) ya no es vulnerable.

Antecedentes

A principios de este año, Adobe introdujo varias técnicas de mitigación contra los exploits de Flash, en colaboración con Google Project Zero. Estas técnicas de mitigación se enfocan en reducir las explotaciones de Vector.<*>, debido a que un Vector.<*> corrupto se utilizaba con frecuencia para lograr la capacidad de leer y escribir partes arbitrarias de la memoria. Esto permite que varias técnicas de seguridad como DEP/ASLR/CFG/EMET sean evadidas y se realice una ejecución remota del código (Remote Code Execution – RCE) dentro del proceso del navegador.

Una vez que se implementaron estas mitigaciones, las explotaciones se redujeron, pero no desaparecieron por completo. Esta reciente vulnerabilidad es la primera explotación de día-cero descubierta después de que se agregaron estas mitigaciones.

Cómo se utilizó CVE-2015-7645 en Pawn Storm

Como ya lo reportamos con anterioridad, Pawn Storm utilizó esta explotación de día cero para atacar a varias secretarías de relaciones exteriores de todo el mundo. Los objetivos enviaron correos electrónicos de spear-phishing que contenían URLs que llevaban al exploit. Los correos electrónicos (en particular los asuntos del correo electrónico y los links) fueron diseñados para hacer creer que hablaban de noticias relacionadas con eventos recientes.

El exploit se descarga cuando la víctima da clic en el URL que viene dentro del correo electrónico. El exploit que nosotros identificamos como SWF_OLOLO.A, deja un archivo DLL (“marlou.fel”) que ha sido identificado como TROJ_SEDNIT.D. Entonces, TROJ_SEDNIT.D deja otro archivo DLL (“mgswizap.dll”) el cual es identificado como TSPY_SEDNIT.D. Las variantes de SEDNIT son conocidas por ser el malware que se utilizó en todas las campañas de Pawn Storm.

Analizando la Causa de Raíz de la Vulnerabilidad

Esta vulnerabilidad en particular es de un nuevo tipo, al cual llamamos Method Confusion. Es la vulnerabilidad de Flash más interesante que hemos analizado hasta ahora.

Una muestra de la explotación SWF se confundió. Después del análisis, se descubrió que la vulnerabilidad se ubica en el método writeObject del objeto ByteArray. Cuando se procesa ba.writeObject(some_obj), si some_obj es un objeto de una clase que implementa la interfaz flash.utils.IExternalizable, llamará al método writeExternal de IExternalizable.

El método writeExternal debe implementarse en la definición de la clase some_obj. Sin embargo, si hay un campo adecuado llamado también writeExternal y es definido de una forma poco común, la propiedad writeExternal ocultará el método writeExternal.

La definición complicada puede ser algo como la siguiente imagen:

Después de que la propiedad writeExternal oculta al método writeExternal, provoca que el binding_id del método tenga un valor erróneo. En ba.writeObject(some_obj), necesita recibir primero la función binding_id de writeExternal. Después usará esto para obtener la estructura del entorno del método usando una frase como methods[binding_id].

Después de obtener el entorno del método, puede aplicarse el JIT (Just in Time) al código nativo, el cual es entonces llamado.

Estos son los pasos simplificados para llamar al método writeExternal en ba.writeObject(some_obj):

1. Localice la función binding_id por el nombre de búsqueda de writeExternal en public namespace.
2. Obtenga la estructura del entorno del método por methods[binding_id]
3. JIT en el entorno del método al código nativo, y llámelo.

Usted puede encontrar el código relativo en el proyecto de código abierto AVMPlus. En el constructor ClassInfo, descubrirá que m_functionBinding utiliza el public namespace y el string kWriteExternal.

La frase clave anterior es MethodEnv* method = obj->vtable->methods[id].

Sabemos que la identificación de la función writeExternal era errónea después de que la ocultara la propiedad writeExternal, debido a que cuando realiza la búsqueda descubre la propiedad writeExternal pública.

Esto significa que ahora los exploits pueden construir una definición de clase a la medida para obtener el valor binding_id de una función deseada.

Desde el código fuente AVMPlus, podemos ver que leerá el método de obj->vtable->methods[id]. El valor id puede controlarse, de manera que los exploits también pueden controlar la lectura MethodEnv*. Después de este punto, la vulnerabilidad se ha vuelto un caso de lectura fuera de los límites; los exploits pueden controlar la disposición de la memoria para poner un MethodEnv* de su elección en la function id slot falsa.

Entonces la explotación utiliza otro método AS3 definido a la medida para ser llamado usando ksome_externalizable_obj como puntero. Ahora parece ser un tipo de caso de confusión.

En resumen, los pasos para esta explotación son:

1. Definir la clase A que implementa utils.IExternalizable. Class A define el método writeExternal y la propiedad writeExternal dentro de public namespace. Controle la orden de la propiedad writeExternal para controlar la binding_id de la función falsa.
2. Definir la clase B, y definir el método B con el código malicioso que va a ser llamado. Los nuevos objetos de esta clase se utilizan para controlar la disposición de la memoria y asegurarse de que la estructura del entorno del método B sea asignada en la binding_id falsa.
3. Crear un nuevo objeto de Class A, y entonces usar writeObject(externalizable_object) para desencadenar la vulnerabilidad.
4. El método B será llamado, y el atacante puede manipular el puntero de externalizable_object en este método.

Ir Más Allá de Vector.<*>

Así es cómo el atacante utilizó esta vulnerabilidad. La muestra sobrescribió el campo length de un objeto basado en ByteArray a 0Xfffffff6. Utilizaron esto para leer y escribir en las ubicaciones arbitrarias de la memoria. Las mitigaciones Vector.<*> no se utilizan aquí ya que la longitud ByteArray no está protegida.

Los atacantes no necesitan depender de dirigirse a Vector.<*> para realizar explotaciones en el futuro. Como lo ha demostrado este ataque, existen otros objetos que los atacantes pueden usar (o abusar). Adobe debe proteger la longitud ByteArray y otros objetos que tengan la propiedad length. 

Depurando los Detalles 

Construimos una prueba de concepto (PoC) simplificada que mostraba la vulnerabilidad y la depuramos. Primero, configuramos el objeto de la propiedad writeExternal para ser la 28° propiedad. La PoC no controla la disposición de la memoria de la ranura binding_id, así que leerá un puntero del entorno del método basura y provocará una caída.

Utilzamos una extensión windbg para ayudar a depurar esta PoC. Esta extensión puede ayudar a delinear y establecer un punto de interrupción en los métodos AS3. Con eso, se puede penetrar fácilmente a MethodEnv* method = obj->vtable->methods[id].

Conclusión

Las mitigaciones pueden reducir las explotaciones pero no son infalibles. La historia ha demostrado que las vulnerabilidades buenas o perfectas siempre pueden evadir a las mitigaciones, lo que hace de suma importancia que los usuarios tengan una defensa de múltiples capas contra los ataques que utilizan las explotaciones de día-cero. Las tecnologías de Trend Micro protegen a los usuarios de las explotaciones de día-cero al ofrecer protecciones para todas las diferentes capas dentro de una infraestructura.

Puede utilizarse la Sandbox existente con el motor Script Analyzer, que es parte de Trend Micro™ Deep Discovery, para detectar ataques que usan Adobe Flash 0day por su comportamiento sin actualizaciones del motor o de los patrones.

Trend Micro Deep Security y Vulnerability Protection, por otro lado, protegen a los sistemas de lo usuarios de las amenazas que puedan aprovechar esta vulnerabilidad de día cero de Adobe Flash con la regla DPI 1007119 – Archivo Adobe Flash SWF Malicioso Identificado.

Los hashes SHA1 de los archivos relacionados con esta amenaza son:

• 2DF498F32D8BAD89D0D6D30275C19127763D5568 – detectado como SWF_OLOLO.A
• 20F5A9C0E1D2AEF36D15CA149FE71AC6B2A9AF1E – detectado como TROJ_SEDNIT.D
• A5FCA59A2FAE0A12512336CA1B78F857AFC06445 – detectado como TSPY_SEDNIT.D

Con el análisis adicional de Stanley Liu

Actualizado el 11 de octubre de 2015, 7:29 P.M. PDT (UTC-7) para agregar los hashes SHA1 relacionados con la explotación de Flash más reciente.