Nuevo Flash Player día-cero (CVE-2014-0515) utilizado en ataques watering-hole

Después de un análisis detallado, quedó claro que no utilizaban ninguna vulnerabilidad conocida hasta entonces. Enviamos los exploits a Adobe, y después de unos días nos confirmaron que en realidad utilizaban una vulnerabilidad día-cero posteriormente denominada CVE-2015-0515. Esta vulnerabilidad se encuentra en el componente Pixel Bender, diseñado para el procesamiento de video e imágenes.

Recibimos una muestra del primer exploit el 14 de abril, mientras que la muestra del segundo nos llegó el 16 de abril. KSN detectó inicialmente el primero el 9 de abril, mediante una firma heurística general. El 14 y el 16 de abril se produjeron varias detecciones posteriores. Es decir, logramos detectar una amenaza anteriormente desconocida mediante el método heurístico.

Según los datos de KSN, estos exploits se guardaban como movie.swf e include.swf en un sitio infectado. La única diferencia entre ambos programas maliciosos radica en los shellcodes. Debemos remarcar que el segundo exploit (include.swf) no se detectó con la misma firma heurística que el primero, porque contenía un shellcode único.

Cada exploit viene como un archivo de video flash desempaquetado. El código Action Script no estaba ni ofuscado ni cifrado.

Como suele suceder con este tipo de exploits, la primera etapa consiste en utilizar una técnica heap spray que prepara la memoria dinámica para explotar la vulnerabilidad. Los exploits también pueden verificar la versión del sistema operativo; si detecta Windows 8, utiliza un bytecode ligeramente modificado del componente Pixel Bender.

Un fragmento del código vulnerable Pixel Bender (los datos encuadrados en rojo cambian según la versión del sistema operativo)

Un fragmento del código descompilado del exploit

A continuación se explota la vulnerabilidad, es decir, se modifica uno de los índices en la tabla de métodos/funciones virtuales.

Curiosamente, ambos exploits tienen dos shellcodes. El primero es similar en ambas aplicaciones; es bastante corto y prepara la memoria para que tenga éxito la ejecución del segundo shellcode.

Un fragmento del primer shellcode depurado en WinDBG

Primero, la memoria vigente está marcada como leer, escribir y ejecutar con la función API VirtualProtect, y después se asigna la memoria adicional mediante VirtualAlloc. El segundo shellcode se copia a esta memoria y se le transfiere el control. La inicialización de las funciones API y la transferencia del control al segundo shellcode aparecen enmarcadas en rojo en la captura de pantalla de arriba.

Los segundos shellcodes del exploit difieren en gran manera.

El exploit que detectamos inicialmente tiene un shellcode estándar (movie.swf). Realiza una búsqueda de bibliotecas de sistema en la memoria, y después descarga y ejecuta la carga maliciosa. Por desgracia, el enlace estaba desactivado cuando realizamos esta investigación.

Fragmento del segundo shellcode movie.swf del exploit, responsable de descargar y ejecutar la carga maliciosa

En el otro exploit, include.swf, el segundo shellcode era inusual. Recibe la base de direcciones DLL para flash10p.ocx, busca fragmentos específicos e interactúa con ciscompeaddin5x0 – Cisco MeetingPlace Express Add-In versión 5×0. Este complemento lo usan los participantes en videoconferencias para ver documentos e imágenes desde la pantalla del presentador. Debemos notar que el exploit no funciona si las versiones requeridas de Adobe Flash Player ActiveX y Cisco MPE no se encuentran en el sistema.

Fragmento del segundo shellcode include.swf del exploit

Al parecer, parte de la información para el exploit include.swf proviene del exterior. Según los datos de KSN, el referer para include.swf apunta a otro archivo SWF: stream.swf. Al mismo tiempo, el referer del primer exploit movie.swf apunta a index.php localizada en la misma carpeta que el exploit (ver abajo). No logramos establecer con exactitud la carga maliciosa del exploit include.swf debido a la falta de datos transmitidos desde la página de aterrizaje y/u otros exploits.

Sin duda alguna, todos estos trucos se usaron para ejecutar actividades maliciosas contra un grupo de usuarios muy específicos, pasando desapercibidas ante las soluciones de seguridad. Creemos que el complemento de Cisco que mencionamos antes puede usarse para descargar/implementar la carga maliciosa, y para espiar directamente en el equipo infectado.

Ambos exploits que detectamos se propagan desde un sitio localizado en http://jpic.gov.sy/. El ministerio sirio de justicia lanzó este sitio en 2011 con la intención de ser un foro para que los ciudadanos presenten sus quejas sobre faltas contra la ley y el orden. Creemos que este ataque estaba diseñado contra los disidentes sirios que se quejan contra el gobierno de ese país.

El sitio fue hackeado en septiembre de 2013, lo que el supuesto hacker anunció en su cuenta de Twitter.

El enlace a estos exploits es como sigue: http://jpic.gov.sy/css/images/_css/***********.

Cuando accedimos al sitio, las cargas maliciosas ya no se encontraban en la carpeta “_css”. Suponemos que los ciberdelincuentes crearon esta carpeta, cuyo nombre no llama la atención en un recurso administrativo, desde donde descargaron los exploits. Probablemente se desviaba a las víctimas mediante un frame o un script localizado en el sitio. Hasta esta fecha, 28 de abril, la cantidad de detecciones por nuestros productos supera las 30, y sucedieron en los equipos de siete usuarios únicos, todos en Siria, lo que no es sorprendente dada la naturaleza del sitio. Curiosamente, todos los usuarios atacados accedieron al sitio a través de distintas versiones de Mozilla Firefox.

Es probable que el ataque haya sido cuidadosamente planificado por profesionales de primer nivel. Esto se constata por el uso de exploits día-cero diseñados profesionalmente para infectar un recurso único.

Asimismo, mientras que el primer exploit es bastante estándar y puede infectar prácticamente cualquier equipo desprotegido, el segundo (include.swf) sólo funciona adecuadamente en equipos que tienen instalados Adobe Flash Player 10 ActiveX y Cisco MeetingPlace Express Add-In. El componente Flash Player Pixel Bender, al que Adobe ya no brinda soporte, se usó como vector de ataque. Los ciberdelincuentes contaban con que los desarrolladores no iban a encontrar ninguna vulnerabilidad en ese componente y que el exploit permanecería activo por mucho tiempo. Todo esto sugiere que los atacantes no tenían blancos masivos.