Cómo montar un laboratorio de pentesting para Android en Windows…
…sin sufrir demasiado.
La mayoría de guías destinadas a este propósito obvian algunos errores típicos durante la instalación de algunos de estos componentes y se limitan al siguiente, siguiente, siguiente del emulador de turno, pero montar un laboratorio para Android destinado a pentesting, sin ser una tarea compleja, requiere de una sentada de 15–20 minutos para ubicar y configurar bien todos los componentes.
Por esto, esta guía pretende ser una referencia para propios y extraños en la que no dejemos ningún cabo suelto y, al finalizar, disponer de un laboratorio completo y funcional.
Los ingredientes para esta receta serán:
- Genymotion, el emulador de Android
- ADB (Android Debug Bridge)
- Burp
- Frida (requerirá python3.x)
Genymotion
Existen diferentes soluciones para emular Android, la preferida en la mayoría de casos es Genymotion y su principal atractivo es que dispone de varias versiones de Android y emula diferentes modelos de smartphones, así como poder lanzar nuestras propias configuraciones personalizadas.
En realidad la emulación corre sobre VirtualBox, por eso disponemos de un instalador de Genymotion que incluye una versión compatible de VirtualBox o, si ya disponemos de VirtualBox en nuestra máquina, de un instalador en el que sólo se incluye Genymotion. La recomendación, siempre que sea posible, es descargar el instalador donde se incluyen ambas opciones, así evitaremos posibles incompatibilidades.
Si os habéis peleado con VirtualBox o VMWare Player previamente ya sabréis que estos emuladores no conviven muy bien con Hyper-V en entornos Windows, así que si vuestro sistema necesita Hyper-V, ya sea porque virtualizáis o usáis dockers con él, el consejo de amigo es buscarse otro Windows, acabaréis antes.
Se recomienda instalar y ejecutar Genymotion con permisos de Administrador, la creación de máquinas virtuales Android generará múltiples interfaces de red VirtualBox Host-Only y si no proporcionamos estos permisos tendremos ir dando permisos una a una y en ocasiones, al no disponer de suficientes privilegios para crear o reiniciar estas interfaces durante el arranque de la máquina virtual, sencillamente nuestro Android emulado no iniciará. La instalación no tiene más misterio, debéis registraros y seguir los pasos.
Si tras la primera ejecución -corriendo como Administrador- el Android virtual no arranca se pueden seguir los siguientes workarounds:
- Iniciar TODAS las interfaces VirtualBox Host-Only deshabilitadas y reiniciar las activas, todas deben quedar activas:
- Los sistema HiDPI o de reescalado de vuestro escritorio pueden dar errores al iniciar el Android virtual. En mi caso tengo dos monitores y uno de ellos no está reescalado, así que intento iniciar siempre en ese monitor. Si no disponéis de varios monitores probad con cambiar el reescalado al 100% y comprobad si así desaparece el error.
Para acceder a las diferentes aplicaciones y settings debemos mantener pulsado el ratón sobre el botón central del menú inferior y desplazarlo hacia arriba, como si de un smartphone real se tratara:
Uno de los aspectos que podemos echar de menos en nuestro recién levantado Android virtual es la ausencia de la Google Play Store:
Desde el menú lateral OpenGAPPS podemos instalar la GPlayStore y empezar a instalar cualquier aplicación:
Una vez instalada será necesario reiniciar el sistema virtualizado para poder verla en nuestro menú:
ADB (Android Debug Bridge)
ADB es una conjunto de herramientas portables que permiten conectar y lanzar diferentes instrucciones sobre un dispositivo Android, algunas instrucciones básicas y útiles son:
- abd devices: Muestra la lista de dispositivos disponibles
- adb connect <device>: Vincula adb con el device indicado.
- adb pull <path_file>: Descarga el fichero en path_file de nuestro device a nuestra máquina local
- adb push <path_source> <path_destiny>: Hacemos upload de un archivo de nuestro Windows al path_destiny del device
- adb shell: Cual SSH, nos conecta al device en modo consola.
La última versión disponible de ADB la podéis descargar desde aquí, es portable y no requiere de instalación. Por comodidad yo la tengo descomprimida en C:\Android\, pero podéis ubicarla en cualquier carpeta.
Si tenemos corriendo nuestro Android emulado podemos confirmar que ADB conecta con el dispositivo:
Burp
La instalación del certificado de Burp y la configuración del proxy no dista mucho de lo que ya hacemos en muchas ocasiones, pero vamos a detallarla.
El primer paso es poner a escuchar el proxy en todas las interfaces:
Con resultado *:8080
Desde el menú de Settings -> Network -> Wifi -> Android Wifi editamos las opciones de esta conexión en el icono del lápiz en la esquina superior derecha (1), desplegando Advanced option (2), Proxy (3) y seleccionando Manual (4) donde indicaremos la IP local de nuestro Windows:
Rellenamos los campos de proxy hostname y proxy port y guardamos estos cambios:
En este punto podemos intentar navegar, pero veremos sin éxito que todavía no es posible, nos falta instalar el certificado de Burp. El navegador WebView Browser Tester que viene incorporado no es una buena solución para descargar el certificado desde http://burp, así que la opción más óptima es descargarlo desde la shell:
adb shell
cd /storage/emulated/0/Download
wget http://<tu IP local>:8080/cert
mv cert cacert.cer
Desde el menú Settings -> Security -> Encryption & credentials -> Install from SD card -> Menú superior izquierdo, seleccionar Download encontraremos el certificado de Burp:
Clickamos encima y aparecerá un pop-up para su instalación. Le damos nombre, mantenemos la opción VPN and apps y guardamos:
Ahora sí, podemos navegar y veremos todo el tráfico en Burp:
Frida
¿Te suena el SSL pinning o certificate pinning? A mi tampoco hasta hace dos días. Sencillo y para toda la familia: Es un proceso que asocia una aplicación (en este caso APKs) a un certificado predefinido por lo que cualquier otro certificado, aún siendo valido y emitido por una CA conocida, será descartado. Dicho de otra manera, es una capa adicional de seguridad que vincula una aplicación con su certificado y evita que el tráfico pueda ser analizado por aplicaciones intermedias con otros certificados, ya no sólo autofirmados como el que genera Burp, sino incluso válidos en cuanto a cadena de confianza. Por suerte para nosotros, existe frida.
Frida es una herramienta que nos permitirá hacer bypass del certificate pinning y nos permitirá pasar el tráfico de aplicaciones a través de Burp.
En la página de releases de frida encontraremos múltiples aplicaciones, sistemas y arquitecturas diferentes. Lo único que nos interesa de este apartado es descargarnos la última version de frida-server para Android en x86, puesto que las imágenes virtualizadas de Genymotion son de 32 bits:
Descomprimimos este archivo en C:\Android\ y lo renombramos a frida-server:
Lo único que nos queda es subir este binario a nuestro dispositivo y dejarlo running:
adb push frida-server /data/local/tmp
adb shell chmod 755 /data/local/tmp/frida-server
adb shell /data/local/tmp/frida-server &
En cuanto a la parte servidor de frida ya lo tenemos todo. Pasemos a la parte cliente. Necesitamos tener instalado en nuestro sistema python 3.x y pip -que ya viene incluída en el instalador de python3- debemos instalar frida-tools:
pip install frida-tools
Fijémonos que en el primer warning nos advierte que la ruta donde se han instalado las frida-tools no está incluida en la variables PATH, así que por comodidad la añadiremos. Buscamos el panel de edición de variables de entorno en Windows:
Seleccionamos la variable Path, la editamos y añadimos una nueva entrada indicando el path completo del warning que nos ha sacado pip mientras instalábamos frida-tools. Con esto, abrimos un nuevo cmd.exe y revisamos que podemos correr frida desde cualquier ubicación:
Necesitaremos un último elemento, un javascript que se inyectará en la app que deseamos analizar. Recomiendo éste script de propósito general:
/*
Universal Android SSL Pinning Bypass
by Mattia Vinci and Maurizio Agazzini$ frida -U -f org.package.name -l universal-ssl-check-bypass.js --no-pausehttps://techblog.mediaservice.net/2018/11/universal-android-ssl-check-bypass-2/
*/Java.perform(function() {var array_list = Java.use("java.util.ArrayList");
var ApiClient = Java.use('com.android.org.conscrypt.TrustManagerImpl');ApiClient.checkTrustedRecursive.implementation = function(a1, a2, a3, a4, a5, a6) {
// console.log('Bypassing SSL Pinning');
var k = array_list.$new();
return k;
}}, 0);
Guardamos esto en un fichero *.js dentro de nuestro C:\Android\
Con todo esto ya sólo nos falta saber qué aplicación queremos analizar. Recomiendo encarecidamente el laboratorio de Android Hacking 101 de TryHackMe para un primer contacto donde se trabaja sobre la app Hacker Tracker de la DEFCON. Descargaremos esta app desde la GooglePlayStore, desactivando el proxy del wifi puesto que el ssl pinning de la store no nos dejará navegar mediante proxy. Una vez instalada la app volvemos a activar el proxy en las settings de nuestro Android.
Para poder empezar a analizar el tráfico de una app necesitaremos conocer su package name, para esto debemos buscar en la lista de packages de nuestro dispositivo:
adb shell pm list packages
Nos aparecerán decenas de resultados, así que mejor filtrar con findstr:
adb shell pm list packages | findstr <string>
Sabiendo el package name de la aplicación ya podemos correr el cliente frida para bypassear su ssl pinning con la siguiente instrucción:
frida -U -f <package> -l <bypass JS> --no-paus
Ready! Ya tenemos frida activo y listo para bypassear todo el tráfico HTTPS de la aplicación evadiendo el ssl pinning. El resto de pentest, más allá del análisis dinámico o estático que podamos hacer sobre el APK, se asemeja bastante al pentest web clásico. A disfrutar!
NOTA: Es posible que con la app Hacker Tracker no veáis tráfico mediante Burp, es una mera app de ejemplo puesto que se utiliza en un lab de TryHackMe y el grueso de su información la tiene en local. Para evitar problemas legales se ha descartado el uso de otras apps.
