Autores
¿Qué es Flashback/Flashfake?
Es una familia de malware para Mac OS X. Las primeras versiones de este tipo de amenazas se detectaron en septiembre de 2011. En marzo de 2012, unos 700.000 ordenadores en todo el mundo se infectaron con Flashback. Los ordenadores infectados forman parte de una red zombi que permite a los ciberdelincuentes instalar en los equipos capturados, a su antojo, módulos maliciosos adicionales. Sabemos que uno de estos módulos genera falsos resultados de los motores de búsqueda. Es muy posible que, además de interceptar el tráfico de los motores de búsqueda, los ciberdelincuentes instalen otros módulos en los ordenadores infectados, por ejemplo para robar información o propagar spam.
La fase cero de la infección: blogs de WordPress hackeados
Entre septiembre de 2011 y febrero de 2012, Flashfake se propagó sólo mediante métodos de ingeniería social: a los visitantes en varios sitios web se les pedía que descarguasen una falsa actualización para Adobe Flash Player. Pero en realidad era el troyano el que se propagaba como archivos de instalación con los nombres “FlashPlayer-11-macos.pkg”, “AdobeFlashUpdate.pkg”, etc.
El uso de exploits para propagar Flashfake se detectó en febrero de 2012; en los ataques se usaban exploits de 2008 y 2011. La explotación de la vulnerabilidad CVE2012-0507 se detectó en marzo de 2012. Se trataba de una vulnerabilidad en Mac OS X que estaba desprotegida, a pesar de que Oracle ya había publicado el respectivo parche en febrero. Esto se debió a que Apple nunca usa parches de Oracle y crea los suyos para reparar las vulnerabilidades en Java. El parche para Mac OS X que reparaba la vulnerabilidad CVE2012-0507 se publicó a principios de abril.
Esta práctica de publicar parches con retrasos de hasta dos meses es tradicional en Apple.
| Vulnerabilidad | Parche de Oracle | Parche de Apple |
| CVE2008-5353 | 14 abril 2009 | 15 junio 2009 |
| CVE2011-3544 | 18 octubre 2011 | 8 noviembre 2011 |
| CVE2012-0507 | 14 febrero 2012 | 03-12 abril 2012 |
Para que Flashfake se propagara en marzo de 2012, sus autores recurrieron a un programa asociado malicioso que parece tener origen ruso.
Este programa asociado se basaba en scripts para desviar usuarios desde numerosos sitios web legítimos en todo el mundo. Entre fines de febrero y principios de marzo de 2012, se infectaron decenas de miles de sitios de la plataforma WordPress. Aún no está claro cómo sucedió esto. Por una parte se sostiene que los bloggers de WordPress estaban usando versiones vulnerables de esta plataforma, y por otra que habían instalado el plugin ToolsPack. Websense estimó el número de sitios afectados en 30.000, mientras que otras compañías calculan que se trataría de hasta 100.000. Un 85% de los blogs comprometidos están localizados en EE.UU.
Cuando se hackeaban los blogs se inyectaba un código en las páginas principales. Al código se le añadieron construcciones del siguiente tipo (por ejemplo):
Entonces, cuando el usuario visitaba cualquiera de los sitios comprometidos, se ponía en contacto con un programa asociado TDS. Según el sistema operativo y la versión del navegador, éste realizaba un desvío oculto hacia sitios en la zona del dominio rr.nu que contenían los exploits apropiados instalados para ejecutar la infección.
Código en un sitio de WordPress con un enlace a un script malicioso
The first phase of the infection: drive-by-downloads and social engineering
Durante los desvíos ocultos (ejemplo: hxxp://ixeld52erlya.rr.nu/n.php?h=1&s=pmg), el navegador accedía a las carpetas /3f/ o /7f/ en el sitio malicioso y ejecutaba Java Script que a su vez cargaba un applet de Java.
Este es un ejemplo de un script:
document.write(‘<applet archive=”rh-3.jar” code=”rhcls” width=”1″
height=”1″></applet>’);
document.write(‘<applet archive=”cl-3.jar” code=”msf/x/AppletX”
width=”1″ height=”1″></applet>’);
}
El ataque intentaba ejecutar cuatro archivos Jar (aplicaciones de Java). Tres de estos eran exploits para las vulnerabilidades en Java; el cuarto estaba camuflado como una aplicación legítima, usando técnicas de ingeniería social para engañar a las víctimas.
Vulnerabilidades explotadas:
- CVE2008-5353 (“deserialización de objetos del Calendario”)
- CVE2011-3544
- CVE2012-0507
Cada archivo Jar contenía un exploit para una vulnerabilidad y un archivo malicioso ejecutable que se extraía e instalaba en el sistema.
Fragmento del código en el exploit CVE2008-5353
Fragmento del código en el exploit CVE2008-5353
Fragmento del código en el exploit CVE2012-0507
Si los exploits fallaban, se hacía un último intento para infectar el sistema mediante un applet Java especialmente elaborado que aparecía como un archivo legítimo firmado por Apple para que el usuario permita su instalación.
Este método de propagación de Flashfake se descubrió en febrero de 2012.
Los atacantes esperan que el usuario otorgue a la aplicación acceso al sistema puesto que está supuestamente firmada por Apple. Pero en realidad el archivo no tiene la firma digital de Apple: los ciberdelincuentes han falsificado el certificado.
Fragmentos del código en el certificado falsificado
Si el usuario acepta otorgar la autorización requerida por el applet, se extraerá e instalará un archivo malicioso.
Fragmento del código en el applet falsificado
Entonces, la ejecución en el navegador de cualquiera de los cuatros applets descritos antes (los que contienen los exploits o el que solicita la autorización del usuario) causará la instalación de un archivo contenedor que funciona como descargador e instalador para los restantes componentes de Flashfake.
El archivo se instala en /tmp/.sysenter y se ejecuta (si se usa el exploit para CVE2012-0507 se genera aleatoriamente el nombre de un archivo).
Diagrama de la primera fase de la infección
Segunda fase de la infección: descargador en la primera etapa
El archivo instalado en el sistema es un contenedor en el formato binario Mach-O, que contiene un módulo 32-bit o 64-bit; ambas versiones tienen una funcionalidad prácticamente idéntica.
La principal función del módulo es establecer comunicación con el servidor de Comando y Control en la primera etapa, descargar módulos adicionales desde el mismo, e instalarlos en el sistema. Una vez realizadas estas funciones, el módulo se autoelimina y no vuelve a aparecer en el sistema infectado.
Cuando se ejecuta, el módulo verifica si la aplicación LittleSnitch (un popular cortafuegos para Mac OS X), XCode (paquete de herramientas para desarrollar aplicaciones OSX), las aplicaciones antivirus VirusBarrierX6.app, iAntiVirus.app, avast!.app y ClamXav.app, o las aplicaciones HTTPScoop.app y Packet Peeper.app se encuentran en el sistema. Si cualquiera de ellos está en el sistema, el módulo deja de funcionar y se autoelimina.
En el caso contrario, el módulo se conecta con los servidores de Comando y Control (por ejemplo, 31.31.79.87, 78.46.139.211), se comunica con el UUID (identificador universal único) del ordenador de la víctima y busca información adicional sobre el sistema, como la versión del sistema operativo. A su vez, recibe un paquete de datos con dos componentes adicionales codificados con una llave basada en el UUID del ordenador.
Fragmento del código con la lista de aplicaciones para verificar, y la URL del ordenador de Comando y Control
Una vez que se carga el paquete de datos, el módulo procede a extraer los archivos componentes desde el paquete y los instala en el sistema:
Diagrama de flujo de funcionamiento de Flashfake en la actual fase de la infección
El descargador puerta trasera es el primer componente en instalarse. Es el principal módulo del robot y es responsable de garantizar la interacción con la red zombi y la descarga de actualizaciones.
El instalador guarda el cuerpo de la puerta trasera con un nombre arbitrario (comienza con un punto, por ejemplo, “.null”)
El instalador también crea el archivo .plist (ver abajo) para garantizar el posterior funcionamiento de la puerta trasera:
Ejemplo de un archivo .plist
Este archivo se instala en $HOME/Library/LaunchAgents/. Esto garantiza que el módulo de la puerta trasera se cargue automáticamente cada vez que el sistema se inicie.
Diagrama de flujo de funcionamiento de Flashfake en la actual fase de la infección
El segundo componente instalado desde Internet intercepta el tráfico web y sustituye las páginas en el navegador.
El procedimiento de instalación para este módulo ha cambiado notablemente en la última versión del instalador de Flashfake, que se propaga a través de la vulnerabilidad CVE2012-0507. Abajo aparece su descripción.
Fragmento del código del instalador
El instalador llama a la función del sistema para solicitar autorización del administrador y espera a que el usuario ingrese su nombre de usuario y su contraseña raíz.
Petición de autorización del administrador
Si el usuario ingresa los datos requeridos, el instalador podrá abrir y escribir la aplicación para el navegador Safari.app (Applications/Safari.app/Contents/Resources/) y guardar en él el módulo que intercepta el tráfico y sustituye las páginas, así como un segundo módulo que ejecuta el primero en el proceso del navegador. Los nombres de estos módulos son aleatorios, pero todos empiezan con un punto y terminan con las extensiones .png y .xsl.
Para garantizar que los módulos se ejecuten de forma automática, el instalador modifica los contenidos del archivo /Applications/Safari.app/Contents/Info.plist añadiéndole los siguientes hilos:
<dict>
<key>DYLD_INSERT_LIBRARIES</key>
<string>/Applications/Safari.app/Contents/Resources/.nombre_del_fichero.xsl</string>
</dict>
Si estas acciones logran su objetivo, el instalador se conectará con el servidor de Comando y Control, por ejemplo, 31.31.79.87/stat_d/, y notificará sobre el éxito de la operación. Si durante la instalación ocurre un error, la conexión se realizará a, por ejemplo, 31.31.79.87/stat_n/.
Tras concluir estas operaciones, el instalador reiniciará el navegador Safari para activar las modificaciones, dejará de funcionar y se autoeliminará del sistema.
Si el usuario no ingresa el nombre de usuario y contraseña de administrador y pulsa “Cancelar”, los módulos se instalarán mediante otro método.
En primer lugar, el instalador busca en el sistema las siguientes aplicaciones: MicrosoftWord.app, MicrosoftOffice 2008, Applications/MicrosoftOffice 2011, y Skype.app. Si las encuentra, el instalador deja de funcionar y se autoelimina del sistema.
A continuación se instala en /Users/Shared/ el módulo para la intercepción del tráfico con el nombre de .libgmalloc.dylib.
Previamente, el instalador borra los archivos en esta carpeta con el comando rm -f /Users/Shared/.*.so. Esta operación de eliminación tiene el objetivo, seguramente, de borrar versiones anteriores de Flashfake presentes en el sistema.
Entonces el instalador crea el archivo $HOME/.MacOS/environment.plist y guarda en él los siguientes hilos:
<string>/Users/Shared/.libgmalloc.dylib</string>
En consecuencia, el módulo se conecta y se carga en cada aplicación ejecutada.
Otro componente auxiliar se instalará en la carpeta $HOME/Library/Application Support/ del usuario con un nombre aleatorio que comienza con un punto y tiene una extensión .tmp.
Diagrama de flujo de la fase de instalación del módulo de intercepción de tráfico web
Tras completarse la instalación, el instalador se conectará con el servidor de Comando y Control, por ejemplo, 31.31.79.87/stat_u/, para informar sobre el éxito de la infección. Entonces el instalador dejará de funcionar y se autoeliminará.
Continuará…
Autores
La anatomía de Flashfake. Parte I.