MalwareIntelligence es un sitio dedicado a la investigación sobre todas las cuestiones relacionadas con criminología informática, seguridad de la información en general y seguridad antimalware en particular, siempre desde una perspectiva estrechamente relacionado con el campo de inteligencia.

12.10.11

Inside Phoenix Exploit’s Kit 2.8 mini version

Phoenix Exploit’s Kit es uno de los paquetes delictivos con mayor continuidad en la escena del crimeware. Luego de todo este recorrido, actualmente se encuentra in the wild la versión 2.8 que, a pesar de tener una baja actividad desde el último semestre de este año, sigue siendo uno de los tantos Exploit Pack con mayor preferencia por los ciber-delincuentes.

Quizás, esta “poca actividad temporal” tenga su respuesta en la altísima demanda que actualmente posee otro crimeware de este estilo, que podría decirse, es uno de los protagonistas en la actualidad: Black Hole Exploit Pack  .

Sin embargo, PEK posee un modelo de licenciamiento similar, donde la última versión se ha liberado con una “alternativa” de compra. Se trata de Phoenix Exploit’s Kit 2.8 mini. Miremos brevemente esta alternativa delictiva a la cual pudimos acceder a través de nuestro servicio de seguridad ofensiva CrimewareAttack.

El modelo de licenciamiento se compone de su versión Simple de dominio cerrado a un costo de USD 2.200, otra versión Multiproceso también de dominio cerrado a USD 2.700 y un servicio extra de cifrado de USD 40 (ReFUDing), ya presente desde varias versiones atrás como parte del “valor agregado”. 

   
Panel de acceso a PEK 2.8. Al igual que las versiones anteriores, respeta su política de autenticación a través de un solo factor definido por una contraseña que chequea su integridad a través de su HASH MD5.

Básicamente esta nueva versión no modifica sus características, por lo menos respecto a su interfaz gráfica y funcionalidades en relación a las versiones anteriores. Cada sección del crimeware muestra el mismo caudal y tipo de información estadística; minimalista pero concisa, siendo esta, aunque trivial, uno de los principales motivos de la adopción de Phoenix por parte de los ciber-delincuentes. Sencillamente encuentran la información que necesitan para aumentar el nivel de éxito y estrategias de ataque, y fusionar las funcionalidad de este Exploit Pack con algún Malware Kit.

¿Qué diferencias existen entre la versión full y la versión mini?
Básicamente el negocio en torno al modelo de licenciamiento anteriormente mencionado. En el caso de la versión mini, el modelo está sujeto a un dominio bajo la modalidad simple, mientras que la versión full permite multitareas.

Quizás este modelo no dice mucho de esta manera; sin embargo, la razón de su existencia se basa en la posibilidad de utilizar diferentes afiliados de negocios con diferentes perfiles desde el modelo de licenciamiento full. De esta manera los delincuentes pueden ampliar su cobertura de negocio. Mientras que con la versión mini se limita a un solo perfil de usuario.

¿Qué hay de nuevo respecto a los exploits? 
Básicamente no mucho. Todo pasa por la optimización en el código de los exploits para obtener un nivel de éxito eficaz a la hora del proceso de explotación, agregándose el exploit para Java Runtime Environment Trusted.

También se han quitado los siguientes exploits que estaban pre-compilados en la verisón 2.7:
  • Windows Help and Support Center Protocol Handler Vulnerability – CVE-2010-1885  
  • Integer overflow in the AVM2 abcFile parser in Adobe Flash Player – CVE-2009-1869  
  • Integer overflow in Adobe Flash Player 9 – CVE-2007-0071  
  • IEPeers Remote Code Execution – CVE-2009-0806  
  • Internet Explorer Recursive CSS Import Vulnerability – CVE-2010-3971   
Desde M86 Security Lab han publicado a mediados de este año “Phoenix Exploit Kit (2.7) continues to be updated  ”, describiendo la metodología de ofuscación que ya se venía empleando versiones atrás. Con esta modificación, el autor buscó evitar el seguimiento de los componentes de PEK y descubrir su estructura, por ejemplo, durante el proceso de investigación.

Si bien básicamente se trata de los mismos exploits (similares en todos los casos, incluso a los que incorporan los demás Exploits Pack in the wild), el autor los optimiza para cada versión. En este caso, incorpora los siguientes exploits:
A pesar de la optimización de los componentes exploits para cada versión, es llamativo e interesante ver que 
en la cadena de optimización y actualización MDAC sigue siendo el exploit con mayor dominación, no sólo en este Exploit Pack sino que en cualquiera de los existentes ¿Cuál es la razón? Simplemente una falta de madurez en los usuarios (en torno a la aplicaicón de los procedimientos básicos de actualización) que lo transforma en una blanco potencial y altamente potable a través de esta vieja, pero efectiva, vulnerabilidad.

Más información sobre Inside Phoenix Exploit’s Pack de otras versiones:

  
El gráfico muestra algunos de los dominios que los creadores de Phoenix Exploit’s Kit han utilizado durante el año 2011.

Revisión de los componentes que forman parte de Phoenix Exploit’s Kit 2.8 mini versión

  
Simple statistics. La típica y primera pantalla que muestra PEK al momento de acceder. Se visualizan datos de interés para los grupos cibercriminales uqe se encuentran detrás de su gestión: Navegadores (y versión) más explotados, cantidad de equipos comprometidos y los exploits con mayor tasa de éxito.


  
Advanced statistics. Información con un nivel de detalle más amplio respecto a los navegadores comprometidos y sistemas operativos, junto a información de la tasa de éxito para cada uno de ellos.

  
Countries statistics. Información similar a los paneles anteriormente mencionados pero con datos relevantes sobre los países afectados.

  
Referer statistics. Información de los sitios web de referencia a Phoenix Exploit’s Kit.

  
Upload .exe files. Panel mediante el cual se actualiza el malware propagad.

White Paper  
Estado del arte en Phoenix Exploit's Kit (hasta 18/08/2010)  
Relevamiento hasta Phoenix Exploit's Kit v2.3r


 A pesar de algunos aspectos “sutiles”, lo cierto es que PEK prácticamente no cambia en cada versión, y quizás su simplicidad de uso es la clave por la cual sigue con vida en un ambiente delictivo donde la demanda y competencia es muy fuerte. Como en los negocios convencionales pero del lado delictivo.

Crimeware Research Team

Ver más

26.9.11

Show me your Kung-Fu. Reversing/Forensic Android


La pasada semana se celebró la NoConName en Barcelona, y tuve el placer de asistir para dar una conferencia sobre seguridad en Android. En ella hablé sobre cómo realizar un análisis dinámico, estático y forense, saltarse las protecciones de las aplicaciones y liberamos junto a nuestro compañero de MalwareIntelligence, Ehooo, un pequeño PoC que deja en evidencia una vulnerabilidad de Tap-Jacking.

Para aquellos que no pudieron asistir podéis encontrar bajo estas líneas un pequeño resumen de lo que fue mi conferencia, así mismo podéis acceder a toda la información que fue utilizada desde los siguientes enlaces:


·          Source Code: http://code.google.com/p/tap-android/
·          Video: http://www.youtube.com/watch?v=VN_IR2vUMAw

Montando el laboratorio
A la hora de analizar cualquier aplicación de la plataforma Android, debemos de distinguir claramente entre el análisis estático y dinámico. Siendo el primero el estudio a nivel de código de la aplicación para comprender el funcionamiento de la misma y estudiar las funcionalidades que posee, y el segundo basándose en el comportamiento que tiene la aplicación una vez ejecutada con el objetivo de estudiar las conexiones que establece con la red.

Para cada uno de ellos será necesario utilizar un conjunto de herramientas diferentes que variarán según nuestro propósito.

Análisis estático

·         Dex2jar – Permite convertir ficheros de clase *.dex a ficheros *.jar que podrán ser posteriormente abierto y editaros por los IDE específicos para la labor.
·         Jd-GUI – Cargar ficheros *.jar y permite visualizar el código de las clases java que lo componen.
·         JAD – Transforma los ficheros *.class a ficheros *.jad con la intención de ser posteriormente cargados en el Understand para su análisis.
·         Dexdump – Herramienta incluida en el SDK de Android que permite desensamblar todo el código del fichero *.dex a Dalvik Bytecode.
·         Understand Excelente utilidad para analizar, diseminar, y estudiar el funcionamiento y el flujo de llamadas realizados entre los distintos métodos que han sido declaradas en el código fuente de la aplicación.
·         Axml2print – Para obtener información clara del AndroidManifest.xml.

Otras herramientas que quizás puedas encontrar de utilidad sean:


Análisis dinámico

1.       Crear una máquina virtual hacienda uso del SDK.
2.       Lanzar el emulador sobre un puerto determinado y almacenar las conexiones

a.      Emulator –port n @device-name –tcpdump foo.pcap
3.       Instalar la aplicación a analizar
a.      adb install foo.apk
4.       Lanzar eventos sobre el dispositivo y la aplicación (1)
a.      adb shell monkey –v –p package.app n
5.       Analizar los logs creados
a.      adb shell logcat –d
6.       Apoyarnos en Wireshark para analizar las conexiones que se realizan.

(1)  El hecho de lanzar eventos sobre el dispositivo es debido a que en determinadas ocasiones algunas aplicaciones o malware necesitan que se produzcan ciertas circunstancias especiales para poder entrar en funcionamiento. Véase el recibo/envío de un SMS, la entrada de una llamada procedente de un determinado número de teléfono, etc.

Todas estas actividades pueden ser simuladas mediante los siguientes comandos:

·         Llamadas de teléfono
o   Gsm call p-n
o   Gsm accept p-n
o   Gsm cancel p-n

·         SMS
o   Sms send p-n text

·         Cambiar coordenadas GPS
o   Geo fix -13… 21…

Modus Operandi
Si tu objetivo es comenzar analizar aplicaciones sin necesidad de introducirte en los entresijos de la plataforma Android, un modus operandi que puede servirte es el siguiente:

·         AXML2Print – Extraemos los permisos que requiere la aplicación del AndroidManifest.xml
·         Dex2Jar / JAD – Para realizar las transformaciones de código necesarias.
·         JDGUI – Para analizar el fichero de clases *.jar
·         Understand – Para hacer un análisis estático del código y obtener los diagramas de flujo de las funciones que componen la aplicación.
·         Wireshark – Para realizar el análisis dinámico de la aplicación y observar las conexiones que realiza.

Análisis Forense

Para poder realizar una correlación del sistema de ficheros es necesario disponer de permisos root en el dispositivo, esto lo podemos conseguir gracias a diversos exploits o aplicaciones que pueden ser encontrados sin demasiada dificultad, así como una explicación de sus correcta utilización.

Al levantar una shell al teléfono podemos observar que el sistema está basado en Unix y que el sistema de ficheros está montado de la siguiente manera:

$ mount
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/mtdblock3 /system yaffs2 ro,relatime 0 0
/dev/block/mtdblock5 /data yaffs2 rw,nosuid,nodev,relatime 0 0
/dev/block/mtdblock4 /cache yaffs2 rw,nosuid,nodev,relatime 0 0

De manera que existen diversos puntos de montaje en distintos mtdblocks para cada directorio importante en nuestro teléfono:

·         /systen está montado en /dev/block/mtdblock3
·         /cache está montado en /dev/block/mtdblock4
·         /data está montado en /dev/block/mtdblock5

Y en caso de disponer de una tarjeta SD, podemos encontrarla en /sdcard.
El paso necesario para hacer una correlación de forma correcta es utilizar el comando dd acompañado de pull para traernos la imagen que realicemos del sistema a nuestro entorno de trabajo local:

# dd if=/dev/mtd/mtd5 of=/sdcard/data/mtd5.img bs=2048
100480+0 records in 
100480+0 records out
205783040 bytes transferred in 108.504 secs (1896547 bytes/sec)

sebas@Helios:~/Android/sdk/platform-tools$ sudo ./adb pull /sdcard/data/mtd5.img /home/sebas/Android/research/mtd5.img
1799 KB/s (205783040 bytes in 111.650s)

De manera que el proceso resulte tan trivial como grepear la salida en busca de ciertos strings que puedan servirnos de utilidad:

sebas@Helios:~/Android/research$ strings -a ./mtd5.img | grep databases | more
 
...
/data/data/com.android.providers.contacts/databases/contacts2.db-journal
/data/data/com.google.android.gsf/databases/talk.db-journal
/data/data/com.google.android.gsf/databases/talk.db-mj157DA2E7
...

Llegando a la conclusión de que la información de las aplicaciones instaladas en el teléfono se encuentra en la ruta:

·         /data/data/package.app/databases/…

Por lo que el proceso será tan trivial como traernos los ficheros que deseemos nuevamente a nuestro entorno de trabajo para su posterior análisis.

Saltándonos las protecciones

Para poder saltarnos las protecciones de Google existen dos posibles métodos:

Forma manual:
1.       Desensamblar el código haciendo uso de Baksmali:
a.       sebas@Helios:~/Android/research/protection/com.yoyogames/bcode/com$ java -jar baksmali-1.2.6.jar -x -o baksmali_code ../../Android/research/protection/com.yoyogames/classes.dex

2.        Realizar las siguientes modificaciones de código en el fichero de comprobación de licencia (./baksmali_code/com/android/vending/licensing/LicenseChecker.smali)

a.       Modificamos el método checkAccess por el siguiente código http://pastebin.com/FHfaD6WU

b.      Modificamos el método handleServiceConnectionError por el siguiente código http://pastebin.com/fHS8Kp8p

3.       Empacamos la aplicación nuevamente utilizando la herramienta APKTool
4.       Firmamos la aplicación con JarSigner
a.       sebas@Helios:~/Android/sdk/tools$ jarsigner -verify -verbose -certs ~/Android/research/protection/com.yoyogames/prueba.apk

5.       Utilizamos zipalign para temas de optimización y eficiencia:
a.       sebas@Helios:~/Android/sdk/tools$ ./zipalign -v 4 ~/Android/research/protection/com.yoyogames/prueba.apk ~/Android/research/protection/com.yoyogames/prueba-final.apk

6.       Instalamos la aplicación y disfrutamos.

Forma automática

Hacemos uso de la herramienta Anti-LVL (http://androidcracking.blogspot.com/p/antilvl.html) desarrollada por Lohan Plus:

sebas@Helios:~/Android/sdk/tools$ sudo java -jar antilvl.jar -f ~/Android/research/protection/com.yoyogames.droidtntbf-1.apk pruebafinal.apk

De forma que con un simple y sencillo paso nos realizará automáticamente todos los pasos del método manual.

Vulnerabilidad de Tap-Jacking

La vulnerabilidad encontrada y explotada viene debida al modelo de confianza que las aplicaciones de Android disponen, permitiendo abrir diálogos con determinados permisos al usuario, de forma que este pueda tomar decisiones que la aplicación por sí misma no puede realizar.

Una aplicación maliciosa que explote esta vulnerabilidad de TapJacking puede abrir un diálogo con privilegios y colocar una capa opaca por encima de esta que pase todos los eventos de pantalla a la capa directamente inferior. Consiguiendo de esta forma poder realizar llamadas, envío de mensajes, clicks en anuncios, transacciones bancarias, todo ello mientras el usuario no es consciente de ello.

El fallo se conseguía a raíz de los Toasts, clases especiales de diálogos, que a diferencia de las “Activities” permitía superpone la actividad actual de la aplicación mientras los eventos de pantalla de esta eran pasados a capas inferiores.

Estos que un principio poseen una apariencia que los permite distinguir de los diálogos normales, podían ser modificados en tamaño y comportamiento, como podréis ver en el vídeo que se ha subido.

La vulnerabilidad, corregida en un principio por Google, afecta a todas las versions actuales de teléfonos Android. Siendo por tanto el riesgo bastante alto. Se desarrollaron un total de 4 payloads para probar su funcionamiento:

·         CallPayload.java – Realiza llamadas de teléfono al número indicado.
·         MarketPayload.java – Descarga e instala aplicaciones del market.
·         ResetPayload.java – Devuelve al estado de fábrica el teléfono.
·         SMSPayload.java – Envía un mensaje de texto  al número  indicado.

Y la estructura interna es la siguiente:

·         Main.java – Ejecuta el servicio principal y carga los payloads.
·         MalwarePayload.java – Abstracción interna para facilitar la implementación de nuevos payloads.
·         MalwareService.java – Crea el toast e inicia el proceso de tap-jacking.
·         Main.xml – Tiene el layout de la aplicación, lanzando con un evento onClick cada payload.
·         Strings.xml – Contiene las cadenas que son utilizadas  en la aplicación.

Conclusión
Después de este pequeño resumen y de la investigación acaecía se me ocurren algunas preguntas para lanzar al aire:

·         En el tema de la protección de aplicaciones, ¿Tiene la culpa el desarrollador por no haber tomado las medidas de protección adecuadas, o la culpa es de Google por tener un sistema tan ‘infalible’?
·         ¿Se preocupa Google por combatir contra el Malware? ¿O es una batalla que tiene perdida desde el comienzo?
·         ¿Es necesario seguir sacando nuevas versiones en lugar de corregir los errores que hay en las anteriores?¿Fomentamos el progreso de la plataforma, o una fragmentación de versiones inevitable?
·         ¿Necesitamos proteger nuestros datos?¿Podemos confiar en la protección ofrecida por Google?¿Compensa tener más cercana nuestra vida digital sabiendo el peligro que corremos? 

Sebastian Guerrero
Crimeware Research

Ver más