Análisis de vulnerabilidades en aplicaciones Android (2)
1. Introducción y objetivos
En este artículo vamos a continuar con el análisis de aplicaciones Android. Los objetivos y el laboratorio son los mismos que los de la primera parte.
Para más información sobre el montaje del laboratorio de análisis se puede consultar en la primera parte: «Análisis de vulnerabilidades en aplicaciones Android (1)».
En los siguientes puntos, vamos a realizar un breve análisis de «InsecureBankV2». Como su propio nombre indica, se trata de una app bancaria que presenta ciertas vulnerabilidades que deberemos encontrar.
Como podemos ver en su repositorio oficial, esta aplicación cuenta con gran cantidad de vulnerabilidades. No obstante, en este artículo únicamente vamos a ceñirnos a estudiar algunas de ellas, a modo de prueba de concepto.
Ya que el análisis estático lo hemos tratado con cierta profundidad en DIVA, aquí vamos a realizar un análisis estático más superficial.
Posteriormente, realizaremos un breve análisis dinámico de la aplicación, para conocer su funcionamiento y características, y poder hacerlo así en aplicaciones futuras, con la finalidad de medir comportamientos sobre todo en aquellas aplicaciones que traten de mantener conexiones con el exterior.
2. Análisis estático de «InsecureBankV2«
En este apartado vamos a estudiar cómo evadir el sistema de ingreso («login») de la aplicación. De esta manera accederemos a otras credenciales, y podremos realizar trasferencias bancarias, entre otras cosas, todo ello mediante la línea de comandos.
a) Obtención de archivos fuente
Al igual que en el artículo anterior, lo primero que debemos hacer es “desempacar” y “desamblar” el “.apk” para poder tener acceso a su código fuente. Esto lo podemos hacer a través de líneas de comandos con “apktools” y otras herramientas, pero también lo podemos hacer de manera mucho más cómoda, automática y fácil con la aplicación gráfica de “APKStudio”.
b) Vulnerando la aplicación
Echando un breve vistazo al código de “AndroidManifest.xml”, nos percatamos de lo siguiente:
De esta manera, a través de “adb shell” podemos ver cómo nos saltamos («bypass») la pantalla de autenticación, al hacer una llamada directa a la actividad “PostLogin” a través del comando:
“am start –n com.android.insecurebankv2/com.android.insecurebankv2.PostLogin”
Vemos cómo efectivamente nos saltamos la pantalla de autenticación y entramos directamente como autenticados.
De la misma manera podemos acceder directamente a realizar una transferencia bancaria, llamando a la actividad “DoTransfer” desde “adb shell” con el comando:
“am start -n com.android.insecurebankv2/com.android.insecurebankv2.DoTransfer”
Como ya hemos visto en el anterior artículo con DIVA, también podemos hacer esas mismas llamadas a actividades y otros recursos usando “drozer”.
Ej. “run app.activity.start –component com.android.insecurebankv2 com.android.insecurebankv2.PostLogin”.
c) Mitigación de las vulnerabilidades encontradas
Hay un par de maneras de prevenir este tipo de vulnerabilidades:
- En primer lugar, la propiedad “android:exported” siempre debe estar en FALSE a menos que sea realmente necesario.
- En segundo lugar, si la aplicación necesita ser llamada desde aplicaciones externas específicas, se pueden agregar permisos personalizados a la actividad, con la finalidad de permitir únicamente que accedan a los recursos aquellas aplicaciones que soliciten permiso para llamar a la actividad.
3. Análisis dinámico de «InsecureBankV2«
El análisis dinámico consiste en estudiar el comportamiento de la aplicación en plena ejecución. Cuando una aplicación se ejecuta, pasa a ser un «proceso» del sistema. Para realizar este tipo de análisis se debe ejecutar la aplicación a analizar, en un entorno controlado, pudiéndola monitorizar a tiempo real, observando de esta manera todos los recursos a los que accede y los cambios que realiza en el sistema.
Para llevar a cabo esta parte del análisis vamos a hacer uso de varias herramientas, como «MobSF» y «Wireshark».
Para realizar un análisis de vulnerabilidades de la aplicación, además de obtener información sobre sus archivos y permisos, vamos a usar MobSF.
Mobile Security Framework (MobSF) lo podemos descargar desde su repositorio oficial. Lo podríamos definir como un framework destinado principalmente al análisis de vulnerabilidades de aplicaciones móviles (Android / iOS / Windows). Entre sus funcionalidades se encuentran: análisis de malware y evaluación de seguridad. Es capaz de realizar análisis estáticos y dinámicos. Admite binarios de aplicaciones móviles junto con el código fuente comprimido. Permite realizar evaluaciones de seguridad muy ajustadas en tiempo de ejecución y pruebas instrumentadas interactivas
Mediante el empleo de “Wireshark” vamos a estudiar el comportamiento de la aplicación a nivel de las comunicaciones de red que realiza.
a) Instalación de MobSF en nuestra máquina
Lo primero que debemos hacer es instalar el framework MobSF de su repositorio oficial.
En esta caso en particular lo vamos a instalar sobre un Windows 10 que tiene la particularidad de estar orientado a la seguridad ofensiva. Se trata de «Windows Commando».
La instalación no tiene mayor complicaciones, como podemos ver a continuación.
Una vez haya finalizado la instalación, procedemos a ejecutar MobSF mediante el lanzamiento de su script «run.bat». De esta manera se nos iniciará un servidor web en el puerto 8000 de nuestra máquina, donde se nos presentará una interfaz muy intuitiva.
Ya estamos listos para usar MobSF.
b) Iniciando la aplicación a analizar
Para dar comienzo al ejercicio, primeramente debemos poner en marcha el servidor que simulará la conexión al banco, cuando introduzcamos las credenciales. En las preferencias de la app debemos especificar host de la máquina (192.168.1.107 en mi caso), y puerto del servidor (8888).
c) Analizando la App con MobSF
Tras subir la «apk» para su análisis por MobSF, hemos obtenido la siguiente información, válida para un análisis estático. Podemos complementar la información del apartado anterior con estos resultados.
Para llevar a cabo el análisis dinámico bajo entorno Windows, donde hemos instalado MobSF, primeramente debemos instalar un emulador. Lo recomendable es instalar Genymotion. Lo podemos descargar de su web oficial.
Tras su instalación veremos que requiere que VirtualBox esté instalado en nuestra máquina. Atención a esto, porque a día de hoy Genymotion Desktop 3.1 no funciona correctamente con la última versión de VirtualBox, sino que debemos instalar la versión 6.0.24, como vemos a continuación.
Una vez instalado VirtualBox en su versión 6.0.24, ya podemos iniciar Genymotion sin problemas. Es muy intuitivo, pasamos a montar el emulador que queramos según las características que le indiquemos.
Una vez iniciado el emulador, no tenemos más que arrastrar al emulador la aplicación que queremos auditar posteriormente con MobSF, para que esta se instale automáticamente en el terminal.
Como podemos ver en la siguiente imagen, tras la instalación de la aplicación en el emulador, ésta se inicia automáticamente.
En este momento ya podemos pasar a la interfaz de MobSF y ejecutar el análisis dinámico.
Para la ejecución de este análisis, MobSF nos proporciona varias herramientas con las que poder interaccionar y ver su comportamiento en tiempo real.
Mientras realizamos nuestras pruebas de penetración a la aplicación, podemos ver el registro de eventos con «logcat», el cual nos da la opción de poder pararlo, al final de la página. Esto es muy útil para poder ver si la aplicación presenta fallos de seguridad en el código a nivel de registros de eventos, ya que en numerosas ocasiones los desarrolladores compilan las aplicaciones en modo «debug» dejando sin proteger cierta información sensible.
Finalmente podemos obtener un informe detallado de todo el análisis realizado.
d) Analizando el tráfico de red
Entre las opciones del análisis dinámico que nos proporciona MobSF, podemos encontrar la del análisis del tráfico que genera la aplicación a auditar. Como vemos a continuación, nos da la capacidad de poder montar un entorno conjunto con «OWASP-ZAP» o «BurpSuite» de proxy, para capturar los paquetes de red y realizar peticiones a la app. Este entorno lo vamos a complementar con «Wireshark» para el estudio del tráfico de red.
Tras el estudio del informe generado, vemos que cuando la app realiza la conexión al servidor para comprobar las credenciales de acceso, realiza una conexión a una base de datos.
No hace falta indagar mucho entre el código fuente para llegar a «TrackUserContentProvider«, donde observamos que para realizar la conexión a la BBDD no hacen falta credenciales de acceso. Además, obtenemos el nombre y la tabla de la BBDD en texto claro, donde se almacena la información sensible. Gran fallo de seguridad.
Como podemos observar, al introducir nuestro usuario y contraseña se envía la petición al servidor, y tras varias comprobaciones que podemos ver sin problemas en el código fuente de la aplicación, nos devuelve el mensaje de error “Invalid Credentials!!!”
Pero, ¿qué pasa si vemos el flujo de red? Como podemos observar en los paquetes capturados con “wireshark”, el envío de la información al servidor se hace en texto plano, sin cifrar. De esta manera cualquier atacante que realice un MITM para capturar tráfico de red, puede obtener las credenciales de acceso a la app bancaria, con las consecuencias que todo ello puede conllevar. Esto es un fallo de seguridad gravísimo.
e) Otras herramientas de análisis
Podemos encontrar múltiples herramientas para realizar análisis dinámico.
Si queremos hacer un análisis dinámico a nivel “privado” bajo nuestro propio entorno seguro, podemos apostar por “DroidBox” y “AndroidSwissKnife”. Esta última es una muy buena opción, ya que además de incluir «DroidBox» también tiene otras muchas herramientas interesantes.
No voy a mostrar cómo desarrollar un entorno particular de análisis dinámico, porque no es el objetivo de este ejercicio. No obstante, os animo a que lo hagáis y experimentéis con todos estos tipos de entornos. De la misma manera, os animo a que realicéis cambios en sus códigos fuente (Open Source) y desarrolléis vuestras propias herramientas.
Podemos destacar los siguientes motores y herramientas «online», para llevar a cabo un análisis de estas características:
f) Muestra de análisis con Virustotal
A continuación vamos a ver el análisis automático que ha realizado la plataforma «Virustotal» de la aplicación en cuetión. Los resultados los podemos encontrar en:
Además, podemos comprobar que la información obtenida en el análisis «online» es cotejada con otros “motores de análisis”, ofreciendo casi idénticos resultados.
4. Conclusiones
Hemos realizado un breve análisis de «InsecureBankV2”. El análisis estático se ha llevado a cabo mediante el estudio del código fuente de la aplicación. Posteriormente hemos realizado el análisis dinámico mediante el empleo de MobSF y Genymotion, analizando el comportamiento de la aplicación. Posteriormente hemos analizado el comportamiento de la app a nivel de red, mediante la monitorización y captura de tráfico. De esta manera hemos averiguado que la app no realiza un cifrado de las comunicaciones, pudiendo obtener información sensible en texto claro.
En el “Mobile_Top_10” de OWASP podemos comprobar que esta aplicación presenta las siguientes vulnerabilidades:
1. Improper Platform Usage
2. Insecure Data Storage
3. Insecure Communication
5. Insufficient Cryptography
6. Insecure Authorization
7. Client Code Quality
8. Code Tampering
10. Extraneous Functionality
Para concluir, insistir a los desarrolladores de la importancia de crear funciones de sanitización de caracteres de entrada en formularios de las aplicaciones, además de establecer comunicaciones de red por protocolos seguros (SSL/TLS).
Para los pentester, insistir en la importancia de una buena disciplina de uso de “OWASP Mobile Checklist» para poder realizar un buen trabajo de análisis de vulnerabilidades de aplicaciones móviles.
