Auditando aplicaciones en Android

Introducción

El objetivo de este artículo es exponer los pasos necesarios para poder hacer un pentesting a las aplicaciones de Android, cubriendo así, la realización de ataques Man in the Middle (MiTM) para poder interceptar todo el tráfico generado.

¿Qué es necesario antes de comenzar?

Desde los puntos en los que he investigado, existen dos formas posibles de llevar a cabo el trabajo, bien utilizando un emulador o un dispositivo físico. Cada una de ellas, presenta sus ventajas y desventajas.

Por ejemplificar alguno de los inconvenientes que me he encontrado utilizando emuladores, es el hecho de que algunas aplicaciones comprueban el IMEI/MSISDN/IMSI del dispositivo, y si detecta que estamos emulándolo automáticamente cesará la actividad de la aplicación. No obstante esto es posible solventarlo realizando algunas modificaciones a nivel de código, pero eso es algo que está fuera del ámbito de esta entrada.

Nosotros, partiremos utilizando un dispositivo físico, y asumiremos que ya tenemos algo de experiencia y que por tanto disponemos del SDK de Android instalado adecuadamente en nuestro equipo.

En caso de no ser así, recomiendo leer estos dos artículos:

• Getting Android SDK
• Installing Android Development Tool (ADT) plugin for Eclipse

El siguiente punto, es la necesidad de tener nuestro dispositivo rooteado. Aquí no voy a explayarme en demasía, según la versión que tengas instalada en tu teléfono el método variaría.

En los terminales sobre los que investigo, siempre trato de utilizar 2.3.4 o 2.3.6 por manías propias. Sobre cómo rootear dichas versiones, podéis encontrar infinidad de artículos. Si queréis un método rápido, siempre podéis flashear el teléfono a la versión 2.3.6 descargando la imagen acorde a vuestro dispositivo y posteriormente utilizar el exploit zergRush.

Si por un casual decides hacer las pruebas en un emulador, te recomiendo que utilices la versión de api-level-8 o Android 2.2 y tras descargar el siguiente archivo:

• su-2.3.6.1-ef-signed (Contiene el binario de su adaptado a ARM y el superuser.apk)

Realices los siguientes pasos mientras el dispositivo emulado está ejecutándose:


./adb shell mount -o rw,remount -t yaffs2 /dev/block/mtdblock03 /system
./adb push su /system/xbin/su
./adb shell chmod 06755 /system.
./adb shell chmod 06755 /system/xbin/su




Posteriormente para instalar la aplicación superuser.apk, bastará con que ejecutes el siguiente comando:


./adb install -r superuser.apk




Estos pasos, serán necesarios realizarlos cada vez que levantes el emulador, sin embargo, puedes escribirte un pequeño script que te facilite la tarea.

¿Interceptamos HTTP?

Una vez realizados los pasos anteriores, nuestro siguiente objetivo en el punto de mira es saber cómo comenzar a interceptar las comunicaciones que son enviadas a través de HTTP por las aplicaciones o las páginas web que visitamos.

Supondremos como proxy (entre otras cosas) la aplicación Burp. Si estamos utilizando un dispositivo físico, bastará con descargar una aplicación que ejerzca de proxy, más adelante comentaré el uso de ProxyDroid.

Si por el contrario estamos bajo el emulador, podemos utilizar algunas de las opciones que por defecto la utilidad emulator (incluída en el SDK) pone a nuestra diposición. En mi humilde opinión, las más intersantes son las siguientes (-http-proxy | -dns-server | -debug-proxy  | -tcpdump).

Así pues, podríamos levantar el emulador utilizando la siguiente línea desde la terminal:

./emulator @device_name -http-proxy ip_proxy:proxy_port -debug-proxy




Obviamente, independientemente del método elegido, será necesario tener ejecutnado una instancia de Burp por detrás para que vaya interceptando todo el tráfico generado.

¿Cuál es el problema?

La cosa se “complica” cuando se intenta interceptar el tráfico generado por una aplicación que se comunique a través de SSL, en ese caso nuestro proxy será incapaz de capturar las peticiones y las respuestas generadas por el servidor. Provocando el cierre abrupto de la aplicación.

Llegados a este punto es necesario realizar dos ligeras modificaciones a nuestro entorno de laboratorio:

• Incrustar el certificado raíz de BurpSuite en nuestro contenedor del dispositivo y hacerlo de confianza.
• Modificar las cadenas “CONNECT IP” por “CONNECT DOMAIN_NAME”

El motivo de esto es debido a que Android por defecto no soporta el uso de proxies, cosa contraria al caso de iPhone. De forma que el comando HTTP CONNECT, normalmente asociado a proxies HTTP, no resuelve correctamente el nombre de dominio asignado a una dirección IP, provocando errores en los certificados SSL que impiden a la aplicación cargar su actividad con normalidad.

¿Cómo abordamos este problema?

Suponiendo que tenemos exportado el CA de Burp (puedes ver aquí cómo hacerlo según el navegador), dependiendo de si estamos en un dispositivo emulado o físico, el proceso de incrustarlo en nuestro sistema será distinto.

También necesitarás descargar el jar de bcprov-jdk16-141 a la hora de firmar el certificado.


Leyenda:

• Símbolo > : Linea de comando en el equipo.
• Symbol $ : Acceso por terminal al dispositivo (no privilegiado).
• Symbol # : Acceso por terminal al dispositivo (privilegiado).

• Dispositivo físico
> ./adb shell
> ./adb pull /system/etc/security/cacerts.bks .
> keytool -keystore cacerts.bks -storetype BKS -provider org.bouncycastle.jc.provider.BouncyCastleProvider -providerpath path_to_bcprov-jdk16-141.jar -storepass changeit -import -v -trustcacerts -alias subdomain.yourappserver.com -file path_to_Burp_CA
> ./adb shell mount -o remount, rw /system
> ./adb push cacerts.bks /sdcard/
$ su
# cd /system/etc/security
# cp cacerts.bks cacerts.bks.bak
# rm cacerts.bks
# cp /sdcard/cacerts.bks cacerts.bks
> ./adb shell mount -o remount, ro /system
  Si reinicias el dispositivo, tendrás añadido como certificado de confianza el CA de Burp y ya podrás interceptar el tráfico que se envíe a través de SSL
  
• Dispositivo emulado (api-level-8 v2.2)

> ./emulator @nombre_del_dispositivo
> ./adb shell
> ./adb pull /system/etc/security/cacerts.bks .
> keytool -keystore cacerts.bks -storetype BKS -provider org.bouncycastle.jc.provider.BouncyCastleProvider -providerpath path_to_bcprov-jdk16-141.jar -storepass changeit -import -v -trustcacerts -alias subdomain.yourappserver.com -file path_to_Burp_CA
> ./adb shell mount -o remount, rw /system
> ./adb shell
# mount
# chmod 777 /system
> ./adb push cacerts.bks /system/etc/security/
> ./adb push mkfs.yaffs2.arm /data/data/temp/mkfs.yaffs2
> ./adb shell chmod 777 /data/data/temp/mkfs.yaffs2
> ./adb shell
# cd /system
# ./mkfs.yaffs2 /system /data/data/temp/system.img
> ./adb pull /data/data/temp/system.img system.img
> ./adb shell mount -o remount,ro -t yaffs2 /dev/block/mtdblock0 /system


Navega hasta: android_SDK_home_path\platforms\target_version\images, realiza un backup del system.img.
Sustitúyela por la imagen generada utilizando la herramienta mkfs.yaffs2 y reinicia el emulador. Una vez arranque, tendrás una versión parcheada del llavero, conteniendo el CA de nuestro proxy.


• Dispositivo emulado (api-level-14 v4.0)A diferencia de los casos anteriores, aquí bastará con hacer:>./adb push path_to_your_burp_CA /sdcard/E instalarlo manualmente desde el panel de configuración.

Comenzando a auditar una aplicación

El siguiente paso será configurar el proxy de Burp con las siguientes opciones:

• (bind to port: 8080 | bind to address: specific address | support invisible proxying | generate a CA-signed certificate  with a specific hostname)

Esta última opción es importante, puesto que para cada aplicación que deseemos auditar, tendremos que exportar e importar el certificado generado para el dominio al que nos estamos conectando a través de SSL, e indicarlo en el correspondiente recuadro.

Por otro lado será necesario  instalar la aplicación  ProxyDroid en nuestro dispositivo y configurarla con los mismos parámetros que hayamos utilizado para el Burp.

Finalmente, como recompensa, obtendremos lo siguiente:

Fuente:  http://blog.seguesec.com