Vamos a ver algunos ejemplos de controles que se llevan a cabo en un Pentesting de Aplicaciones en Android. Lo más importante en un proceso de auditoría será el hacer uso de una metodología, de tal forma que podamos llevar a cabo una serie de pasos de manera ordenada.
Os propongo que hagamos uso de la metodología OWASP, concretamente en su apartado de OWASP Mobile Security Project podemos encontrarnos con muchos recursos: herramientas, guía de desarrollo seguro, plantilla de controles, guía de testing de Apps… Centrándonos en esta última podemos dividir nuestra auditoría en tres partes: recopilar información, análisis estático y análisis dinámico.
Para llevar a cabo las diferentes fases podemos encontrarnos muchas aplicaciones que automatizan nuestro trabajo, incluso que hacen la misma tarea de diferentes formas. Lo importante es tener un laboratorio con todas las herramientas funcionando, en este caso nosotros vamos a utilizar la distribución Androl4b como vimos el pasado Martes 23 de Febrero en la MasterClass con los alumnos de los cursos de Hacking Ético. Antes de nada tenemos que tener en cuenta que tipos de Apps podemos encontrarnos:
- Nativas: la App funciona de manera independiente sin depender de servidor externo, tenemos los datos en el terminal.
- Basadas en servicios Web: la App es un mero cliente que conecta a un servicio Web y solicita datos que después nos muestra.
- Híbridas: una combinación de las dos anteriores.
Hablábamos de metodología y de pasar una serie de controles a nuestras aplicaciones móviles, por tanto vamos a llevar un control que se da también en las auditorías Web, que no es otro que el de análisis de las comunicaciones. Para llevar a cabo nuestra auditoría vamos a hacer uso de una aplicación de tipo híbrido que podemos encontrar dentro de la distribución Androl4b (InsecureBankv2), la cual nos va a servir como entrenamiento para nuestros pentest.
Análisis de las Comunicaciones
Fase 1: Arrancando nuestro AVD en Androl4b
Antes de nada haceros un apunte, puede que a la hora de descargar la distribución tengáis fallos de conexión, ya que le suele pasar a mucha gente, os recomiendo que uséis algún gestor de descarga para no tener problemas. Una vez descargada, abrimos nuestra máquina virtual de Androl4b (credenciales andro:androlab) y tenemos que arrancar el Android Device Manager como vemos en la imagen, seleccionamos el dispositivo virtual (AVD Android Virtual Device) que ya trae creado (lab con Android 4.1.2) y Start.
Caso de querer hacer pasar las conexiones de nuestro dispositivo virtual a través de un proxy como Burp Suite, el cual ya incorpora dicha distribución, simplemente tenemos que lanzar el AVD desde la línea de comandos con el parámetro -http-proxy.
También podemos configurar el proxy dentro del AVD siguiente la siguiente secuencia Setting – More… – Mobile Networks – Access Point Names – T-Mobile US (Seleccionar el APN que aparezca) – aquí configuramos el Proxy y Port, en nuestro caso la IP 192.168.41.135 y el puerto 8080.
Fase 2: Nuestro App Vulnerable con conexión al Banco
Como hemos comentado antes vamos a usar InsecureBankv2, la cual es una aplicación híbrida que consta de un cliente instalado en el terminal (en nuestro caso virtual) y un servidor que vamos a arrancar desde el terminal del sistema Androl4b.
El Server: para el cual nos vamos a la ruta donde está situado y ejecutamos con python la parte servidora. Vemos como se arrancará nuestro servidor del Banco virtual escuchando peticiones en el puerto 8888.
La App: desde el AVD ejecutamos la App (Insecure Bank v2) y nos vamos a menú preferencias para configurar la IP del Server y el puerto.
Fase 3: Análisis del Tráfico con Burp Suite
Ya tenemos todo preparado para analizar el tráfico de nuestra aplicación, pues tenemos todas las peticiones filtradas a través del proxy, de tal forma que vamos a poder ver todo el tráfico. Nos disponemos a poner nuestro usuario y contraseña y cual es nuestra sorpresa cuando vemos que el logueo en nuestra App del banco se lleva a cabo en texto plano, sin usar ningún cifrado, lo cual la hace vulnerable a ataques de MiTM.
Muchas veces los programadores añaden en el código información que les permite depurar el programa mientras está en fase de desarrollo, pero olvidan eliminar dicha información la cual puede ser útil para un atacante, llegándose a producir fugas de la misma.
Fugas de Información
Fase 1: El fichero AndroidManifest.xml
Uno de los ficheros más importantes a la hora de llevar a cabo la auditoría de una App es su fichero de manifiesto (AndroidManifest.xml), donde encontramos todas y cada unas de las funcionalidades de la App, así como los permisos y demás características. En este caso nos vamos a centrar en la característica debuggable de la App, esto puede provocar una fuga de información en su log la cual puede llegar a comprometer al sistema.
Obteniedo la APK: Lo primero será obtener la APK de la aplicación. Si no la encontramos en Internet no hay problema, para encontrarla simplemente buscamos el paquete dentro del AVD mediante ADB (Android Debug Bridge), una herramienta de línea de comandos que me permite comunicarme con el AVD en forma de terminal. Con esta herramienta también descargaremos la APK como vemos en la siguiente imagen.
Reversing a la APK: Lo siguiente será hacer un reversing a la APK con la herramienta APKTool, mediante la cual obtenemos los ficheros y el código fuente de la aplicación, entre ellos el AndroidManifest.xml.
Dentro de los fichero obtenidos abrimos el fichero AndroidManifest.xml y nos fijamos en la propiedad debuggable de la aplicación. Si está a verdadero estamos frente a un fallo de los programadores el cual va a provocar fugas de información.
Fase 2: Analizando el log con PidCat
Como hemos visto tenemos la aplicación en modo depuración, lo cual nos va a dar mucha información a través del log del sistema. Para ello con simplemente usar adb logcat podríamos ver mucha información. En este caso nosotros vamos a ver el log mediante un script en python (pidcat.py) que nos va a enriquecer el log con colores para que sea más fácil la búsqueda de información. En la siguiente imagen vemos como en el log quedaron registradas tanto las credenciales de un usuario (jack:Jack@123$) como una transacción bancaria por valor de 1000$.
Hemos visto hasta aquí un par de fallos de seguridad que puede tener cualquier aplicación móvil, pero existen muchos otros fallos como podemos ver en el OWASP Top 10 Mobile Risks. Espero que os haya resultado interesante y más adelante iremos viendo otros fallos de seguridad interesantes en Apps de Android.
Un handshake
“Un camino de 10,000 km comienza con un solo paso“