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:
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=2048100480+0 records in 100480+0 records out205783040 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.img1799 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)
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?
Crimeware Research Ver más
