05 Auditoria de Aplicaciones Moviles

Auditoría de aplicaciones móviles
© Ediciones Roble, S.L.

Indice
Auditoría de aplicaciones móviles 3
I. Introducción a la auditoría de aplicaciones móviles 3
II. Objetivos 3
III. Metodología 3
3.1. Riesgos de seguridad en aplicaciones móviles 3
3.2. Pruebas seguridad en aplicaciones móviles 5
3.2.1. Pruebas de arquitectura, diseño y modelo de amenazas 6
3.2.2. Pruebas de almacenamiento de datos y privacidad 7
3.2.3. Pruebas de criptografía 7
3.2.4. Pruebas de autenticación y gestión de la sesión 8
3.2.5. Pruebas de comunicaciones 8
3.2.6. Pruebas de interacción con la plataforma 9
3.2.7. Pruebas de calidad de código 9
3.2.8. Pruebas de resiliencia 9
IV. Aplicaciones móviles Android 10
4.1. Tipos de análisis 10
4.2. Análisis estático de la aplicación 11
4.2.1. Obtención del APK 11
4.2.2. Decompilación del APK 15
4.2.3. Obtención del código fuente 16
4.2.4. Reglas de detección y pruebas 19
4.2.5. Herramientas y frameworks 28
4.3. Análisis dinámico 30
4.3.1. Configuración del entorno 30
4.3.2. Análisis dinámico de la aplicación 35
4.3.3. Evasión de las principales contramedidas 35
4.4. Aplicaciones vulnerables 38
V. Aplicaciones móviles iOS 38
5.1. iOS (iPhone OS) 38
5.2. Entorno de pruebas para el análisis de aplicaciones iOS 39
5.3. Análisis estático 40
5.3.1. Archivo IPA 40
5.3.2. Estructura del aplicativo en el dispositivo local 43
5.3.3. Información almacenada en el dispositivo local 44
5.3.4. Análisis del binario 47
5.3.5. Frameworks para el análisis del archivo IPA 50
5.4. Análisis dinámico de la aplicación móvil 53
5.4.1. Instalación del certificado para el análisis del tráfico con Burp Suite 54
5.4.2. Bypass de los controles para dificultar el análisis dinámico 55
5.5. Aplicaciones vulnerables 56
VI. Resumen 57
Recursos 58
Enlaces de Interés 58
Bibliografía 58
Glosario. 60
2/61
I. Introducción a la auditoría de aplicaciones móviles
Con la continua evolución tecnológica, el entorno empresarial ha integrado las aplicaciones

móviles en su modelo de negocio para interactuar tanto con los servicios internos, como para
proveer de aplicaciones comerciales. Estas aplicaciones manejan información sensible y, en
algunos casos, acceden a los recursos internos de la organización, por lo que es necesario realizar
auditorías de seguridad antes de la puesta en producción.
En los siguientes apartados, se exponen las diferentes pruebas que deben constituir una
auditoría de aplicaciones móviles, para garantizar la confidencialidad de la información
adaptándose al escenario cambiante de las amenazas y poder adelantarse al riesgo.
II. Objetivos
Al igual que en la unidad anterior, en esta parte del módulo de Hacking Ético se pretende conseguir que
el estudiante aplique el conocimiento aprendido a la auditoría específica de aplicaciones móviles
centrándonos, sobre todo, en aplicaciones iOS y Android.
Para ello es necesario tener un conocimiento adecuado sobre la estructura de estas aplicaciones, así
como de la guía OWASP Mobile Security Testing Guide que utilizaremos frecuentemente en este tipo de
auditorías.
A lo largo de la unidad, el estudiante aprenderá cómo realizar diferentes técnicas necesarias para la
auditoría de seguridad como el análisis estático o dinámico de aplicaciones de iOS y Android, además del
uso de herramientas específicas para trabajar con aplicaciones de cada sistema operativo.
III. Metodología
Las revisiones de seguridad sobre aplicaciones móviles siguen las pautas marcadas por la guía de
pruebas de OWASP Mobile Security Testing Guide . Esta guía está destinada a proporcionar a los equipos
de seguridad los recursos necesarios para verificar si las aplicaciones móviles no constituyen un riesgo
capaz de comprometer la seguridad de la información almacenada en el dispositivo móvil, la información
transmitida y los recursos gestionados por la aplicación.
3.1. Riesgos de seguridad en aplicaciones móviles
3/61
El objetivo de esta metodología es clasificar los riesgos de seguridad en aplicaciones móviles y

proporcionar controles para reducir su impacto o probabilidad de explotación.
Antes de profundizar en las pruebas de seguridad, resulta oportuno exponer el top ten de riesgos en
aplicaciones móviles definido por OWASP:
Imagen 5.1. OWASP Top 10 Riesgos Móviles.

Fuente: OWASP.
M1 – Uso no adecuado de la plataforma
Los vectores de ataque se corresponden con los vectores tradicionales de OWASP, las llamadas al
API y los servicios web expuestos que utilizan las aplicaciones móviles, constituyen puntos de entrada
de los vectores de ataque.
M2 – Almacenamiento inseguro de datos
Si los datos almacenados en el dispositivo no han sido correctamente securizados, sería posible
acceder a la información sensible mediante el acceso físico al dispositivo o haciendo uso de software
malicioso.
M3 – Comunicaciones inseguras
El vector de explotación consiste en monitorizar la red para detectar comunicaciones inseguras

mediante ataques de Man-in-the-Middle que permitan capturar el tráfico entre la aplicación y el servidor.
M4 – Autenticación no segura
Se identifican vulnerabilidades en el proceso de autenticación, para engañar o evitar la autenticación

enviando peticiones al servidor e interactuar directamente con los servicios publicados.
4/61
M5 – Criptografía insuficiente
Los vectores de ataque incluyen el descifrado de los datos almacenados en el dispositivo, así como
los datos capturados a través de la red, debido al uso de protocolos no seguros o algoritmos de cifrado
deprecados.
M6 – Autorización no segura
Se identifican vulnerabilidades en el proceso de autorización, para autenticarse en el aplicativo como

un usuario legítimo evadiendo el control de autenticación de forma satisfactoria.
M7 – Mala calidad del código
Se explotan las vulnerabilidades mediante el envío de parámetros no controlados por la aplicación y

así provocar desbordamientos de búfer y errores a nivel de código.
M8 – Manipulación del código
Una vez que la aplicación se instala en el dispositivo, el código y los datos residen en él. Se podría
alterar el comportamiento del mismo, modificar directamente el código, los datos contenidos de la
memoria de forma dinámica, reemplazar las API del sistema que utiliza la aplicación o modificar los
datos y recursos de la aplicación.
M9 – Ingeniería inversa
Se analiza el código fuente del aplicativo para identificar las librerías, algoritmos y recursos
embebidos en la aplicación mediante el uso de herramientas de desensamblado de código y debuggers .
M10 – Funcionalidad extraña
Se identifican funcionalidades ocultas o puertas traseras en las aplicaciones móviles, así como
funcionalidades o características que no deberían estar presentes en entornos de producción, habiendo
sido incluidas de forma accidental por los desarrolladores.
3.2. Pruebas seguridad en aplicaciones móviles

En el siguiente apartado, se abordarán sobre una perspectiva general las pruebas de seguridad sobre
aplicaciones móviles, las cuales incluyen:
Revisión de la aplicación móvil implementada en el dispositivo móvil del usuario final.
5/61
2
Revisión de los datos transmitidos entre el aplicativo y el servidor.
3
Revisión de la infraestructura en el lado del servidor con la que se comunica la aplicación.
La OWASP Mobile Security Testing Guide (MSTG) es una guía de pruebas para evaluar la seguridad de
las aplicaciones móviles en la cual se describen los procesos técnicos para verificar los requerimientos
definidos en Mobile Application Security Verification Standard (MASVS), que establece el nivel de
confidencialidad en la seguridad de las aplicaciones móviles.
Esta guía incluye una lista de pruebas agrupadas en las siguientes categorías:
Imagen 5.2. OWASP Mobile Security Testing Guide (MSTG).

Fuente: OWASP.
3.2.1. Pruebas de arquitectura, diseño y modelo de amenazas
Esta categoría cubre los requerimientos correspondientes a la arquitectura y el diseño de las aplicaciones
móviles.
Verificar si los componentes de la aplicación han sido identificados y son necesarios.

Verificar si todos los componentes de terceros utilizados por la aplicación móvil, como librerías
y frameworks , han sido identificados y chequeados por si presentan vulnerabilidades.
Verificar si la arquitectura a alto nivel del aplicativo móvil, y los servicios a los que invoca,
presentan requerimientos de seguridad.
6/61
Verificar si todos los componentes de la aplicación han sido definidos de acuerdo al modelo de
negocio y las prestaciones de seguridad que proveen.
Verificar si se ha establecido el modelado de amenazas para el aplicativo móvil y los servicios
remotos, que presenta amenazas potenciales y contramedidas.
Verificar si todos los controles de seguridad tienen una implementación centralizada.
Verificar si los componentes que no forman parte de la aplicación, pero que son necesarios para
su operativa, han sido claramente identificados y se conocen las implicaciones de seguridad
debido a su uso.
Verificar si los endpoints remotos comprueban que el usuario está empleando la última versión
del aplicativo.
Verificar si ha sido establecida una política para la gestión de llaves criptográficas y se hace
cumplir el ciclo de vida de las mismas, siguiendo el estándar NIST SP 800-57.
Verificar si se han ejecutado las pruebas de seguridad como parte del ciclo de vida del desarrollo
del aplicativo.
3.2.2. Pruebas de almacenamiento de datos y privacidad
El almacenamiento de datos sensibles, como credenciales o información privada, es un aspecto clave en

la seguridad móvil. En este sentido, se abordarán los requerimientos correspondientes al almacenamiento
de datos y la privacidad de los mismos.
Verificar si las capacidades para el almacenamiento de credenciales que provee el sistema se

utilizan adecuadamente para almacenar información sensible, como son las credenciales de
usuario o llaves criptográficas.
Verificar que no se almacenan datos sensibles en los registros de log del aplicativo.
Verificar que no se comparten datos sensibles con terceras partes, salvo que sea necesario como
parte de la arquitectura.
Verificar si el almacenamiento caché del teclado está deshabilitado en las entradas de texto que
procesan información sensible.
Verificar si el portapapeles ha sido desactivado en las entradas de texto que contienen
información sensible.
Verificar si los mecanismos IPC (Interprocess communication) no exponen información sensible.
Verificar que las contraseñas y los números de tarjetas de crédito no se muestran en la interfaz de
usuario o resultan en fugas de información mediante capturas de pantalla.
Verificar que no hay datos sensibles incluidos en la información de backup .
Verificar que la aplicación elimina la información sensible de las vistas cuando está en
background.
Verificar que la aplicación no almacena datos sensibles en memoria más tiempo del necesario y
se limpia explícitamente después de su uso.
3.2.3. Pruebas de criptografía
7/61
La criptografía es un ingrediente esencial en materia de protección del almacenamiento de datos en el

dispositivo. El propósito de estas pruebas es asegurar que el aplicativo utiliza la criptografía acorde a las
buenas prácticas definidas en esta industria.
Verificar que la aplicación no utiliza algoritmos de cifrado simétricos, con claves hardcodeadas
en el código como único método de cifrado.
Verificar que la aplicación utiliza primitivas criptográficas demostradas científicamente.
Verificar que la aplicación utiliza primitivas criptográficas que son apropiadas para cada caso de
uso en particular, configuradas con parámetros que se ajusta a las buenas prácticas de la
industria.
Verificar que la aplicación no utiliza algoritmos de cifrado deprecados o inseguros.
Verificar que la aplicación no reutiliza la misma clave de cifrado para múltiples funcionalidades.
Verificar que los valores aleatorios han sido generados utilizando algoritmos de generación de
números aleatorios seguros.
3.2.4. Pruebas de autenticación y gestión de la sesión
Esta sección define los requerimientos básicos en relación a la gestión de las cuentas de usuario y las
sesiones.
Verificar que la aplicación implementa un método de autenticación seguro con el servicio remoto.
Verificar que el servidor remoto genera de forma aleatoria tokens de acceso para autenticar las
peticiones del usuario, sin enviar constantemente las credenciales del usuario.
Verificar que el servicio remoto finaliza la sesión una vez que el usuario cierra su sesión en el
aplicativo.
Verificar que existe una política de contraseñas robusta ejecutada por el servicio remoto.
Verificar que el servicio remoto implementa una política de bloqueo de usuario de forma
temporal, cuando se realizan numerosos intentos de inicio de sesión fallidos comprendidos en un
periodo de tiempo.
Verificar que la autenticación biométrica no ha sido implementada mediante una API que
devuelve “verdadero” o “falso” según sea válida o no la comprobación, sino que esté basada en
desbloqueos del keychain/keystore.
Verificar que la sesión de usuario finaliza pasado un tiempo de inactividad.
3.2.5. Pruebas de comunicaciones
El propósito de los controles definidos en esta sección es asegurar la confidencialidad y la integridad de

la información intercambiada entre el aplicativo móvil y los servicios remotos.
Verificar que los datos transmitidos en la red van cifrados utilizando TLS. Se debe utilizar un
canal seguro en las transmisiones de datos.
Verificar que la aplicación comprueba el certificado X.509 del servidor remoto al establecerse la
comunicación segura. Solo serán válidos aquellos certificados firmados por una CA válida.
8/61
Verificar que la aplicación no confía únicamente en canales como email o SMS, para realizar
operaciones críticas, como, por ejemplo, para la recuperación de contraseñas.
3.2.6. Pruebas de interacción con la plataforma
Esta sección asegura que la aplicación utiliza las API de la plataforma y los componentes estándar de
forma segura.
Verificar que la aplicación solo requiere un mínimo número de permisos necesarios.

Verificar que todos los parámetros de entrada que maneja el usuario son debidamente validados
y sanitizados, lo que incluye los datos recibidos en la interfaz de usuario, mecanismos IPC, URL,
y recursos de red. También se debe verificar que no se exporta información sensible a través de
los esquemas URL o mecanismos IPC, sin estar estos mecanismos debidamente protegidos.
Verificar que se ha deshabilitado JavaScript en las WebViews, salvo que sea estrictamente
necesario.
Verificar que las WebViews han sido debidamente configuradas permitiendo únicamente el
mínimo número de protocolos (HTTPS).
Verificar que la aplicación detecta si está siendo ejecutada en un dispositivo rooteado o con
jailbreak. Dependiendo de los requerimientos del negocio, la aplicación terminará en caso de que
se esté ejecutando en un dispositivo con root o jailbreak.
3.2.7. Pruebas de calidad de código
El objetivo de estas pruebas es asegurar que se cumplen las prácticas de código seguro.
Verificar que la aplicación ha sido firmada y provisionada con un certificado válido.

Verificar que la aplicación ha sido generada en modo productivo, con la configuración
correspondiente (non-debuggable).
Verificar que los símbolos y el código de debugging han sido eliminados de los binarios nativos.
Verificar que la aplicación realiza un correcto manejo de las excepciones.
Verificar que han sido activadas las protecciones de pila, PIE, etc.
3.2.8. Pruebas de resiliencia
Esta sección cubre las medidas de resiliencia contra la ingeniería inversa, dificultando a los atacantes el
acceso y entendimiento del aplicativo.
Verificar que la aplicación implementa funcionalidades para detectar si el dispositivo ha sido

rooteado o tiene jailbreak, alterando el flujo o terminando la aplicación.
Verificar que la aplicación detecta el uso de herramientas de ingeniería inversa, o herramientas de

inyección de código, frameworks de hooking o servidores de debugging.
9/61
IV. Aplicaciones móviles Android

Android es un sistema operativo basado en el núcleo de Linux diseñado originalmente para dispositivos
móviles, como smartphones y tablets , y que posteriormente expandió su desarrollo para soportar otros
dispositivos como netbooks , televisores, lectores de e-books , PCs, etc. Android fue presentado en 2007
por la Open Handset Aliance (consorcio de compañías tecnológicas dedicado a desarrollar estándares
abiertos para dispositivos móviles), liderada por Google, como un producto Open Source y con una
licencia Apache de código libre. Google había comprado previamente el producto a sus desarrolladores
originales, AndroidInc , en 2005.
Actualmente se trata del sistema operativo más extendido en dispositivos móviles, llegando a una cuota
de mercado de alrededor del 80 %.
Por otro lado, se trata de un sistema operativo que soporta aplicaciones desarrolladas habitualmente en
Java, C o C++ a través del Android SDK ( Android Software Development Kit), ofreciendo la posibilidad
de que cualquier usuario pueda desarrollar su propia aplicación y ponerla a disposición de cualquier otro
usuario de forma gratuita o de pago.
Las aplicaciones pueden ser descargadas desde la tienda oficial de Google Play, conocida actualmente
como Play Store, e instaladas automáticamente en el dispositivo en cuestión. Es preciso mencionar que,
aunque Android solo cuente con una tienda oficial, es posible instalar aplicaciones móviles en el dispositivo
de forma manual, hecho que provoca la aparición de mercados “alternativos” en los que frecuentemente se
encuentran aplicaciones maliciosas que ponen en riesgo la confidencialidad y la integridad de los datos del
usuario, así como del propio dispositivo. Algunos ejemplos de estos mercados alternativos son “Black
Market” o “F-droid”.
4.1. Tipos de análisis

A la hora de realizar una revisión de seguridad de una aplicación móvil, se deberán diferenciar dos tipos
de análisis siguiendo la metodología anteriormente explicada:
Análisis estático de la aplicación
El análisis estático consiste en analizar el comportamiento de la aplicación sin que ésta se encuentre en
ejecución, observando, a partir de la información y código fuente, cómo se comportaría la aplicación y
qué partes de código son susceptibles de ser vulnerables en función de los datos de entrada o
variaciones que sufren en tiempo de ejecución.
Análisis dinámico de la aplicación
El análisis de vulnerabilidades dinámico se caracteriza por estudiar el comportamiento que presenta la

aplicación cuando se encuentra en ejecución. Durante esta fase se analizarán las comunicaciones cliente-
servidor, el acceso a escritura de ficheros, la interacción con diferentes componentes, etc. Para ello, se
hará uso de la información detectada en la fase de obtención de información y, especialmente, del
análisis estático.
Cabe destacar que, si se lleva a cabo un análisis estático en profundidad de la aplicación, se facilitará su
posterior proceso de análisis dinámico.
10/61
4.2. Análisis estático de la aplicación

Para llevar a cabo el análisis estático de la aplicación se deberá acceder al código fuente de la aplicación,
así como a los archivos que la conforman. Para ello, en primer lugar, se deberá obtener el archivo que
contiene la aplicación, comúnmente conocido como APK ( Android Application Package ). Se trata de un
archivo comprimido, muy similar al formato JAR de Java o ZIP, que contiene una estructura de ficheros
que se descomprimirá y replicará en el dispositivo móvil una vez el usuario haya decidido instalar la
aplicación en cuestión.
4.2.1. Obtención del APK
El primer paso será por tanto obtener el fichero .apk de la aplicación; para ello existen varios métodos:
11/61
Si la aplicación se encuentra instalada en el dispositivo móvil, es posible obtener el fichero APK

mediante el uso de la aplicación “APK Extractor” (https://play.google.com/store/apps/details?id=com.ex
t.ui&hl=es). Esta aplicación nos permite listar las aplicaciones instaladas en el dispositivo y obtener el
archivo APK de forma sencilla, pudiendo compartirla, por ejemplo, a través de e-mail. Por otro lado,
siempre se almacenarán en el directorio “ /storage/emulated/0/ExtractedApks/(nombre_del_paquete)” del
dispositivo, al que se podrá acceder si se conecta el dispositivo móvil al ordenador mediante USB y se
accede al directorio, “ \\GT-I9505\Almacenamiento interno compartido\ExtractedApks” , tal y como se
puede observar en las siguientes imágenes:
Imagen 5.3. Obtención de archivo APK mediante APKExtractor.

Fuente: captura de la herramienta APKExtractor.
12/61
Se trata de una herramienta multiplataforma que permite la comunicación remota de un emulador o

dispositivo Android conectado. Generalmente se utiliza un dispositivo físico conectado mediante USB
con las funciones de desarrollo activadas. Para ello se deberá acceder al apartado
“ Configuración>Información del teléfono ” y pulsar 7 veces sobre el “ Número de Compilación” tal y
como se observa a continuación:
Imagen 5.4. Activación de las opciones de desarrollo.

Fuente: configuración de opciones de desarrollo en dispositivo móvil.
Tras realizar estos pasos, se deberá comprobar que en las “Opciones de desarrollador” se cuenta con
la opción “Depuración por USB” activada. De ser así, se deberá conectar el USB al PC y mediante el
siguiente comando se listarán los dispositivos accesibles:
Imagen 5.5. Comandos adb para conectarse al dispositivo móvil.

Fuente: captura de Kali Linux.
Como se puede observar, con el uso del comando adb shell se obtiene acceso remoto al dispositivo.
Mediante ADB es posible realizar la instalación y depuración de aplicaciones en tiempo de ejecución.

En el caso de que el archivo APK se haya obtenido a través de terceros y se desee instalar en el
dispositivo se realizará a través del siguiente comando:
Imagen 5.6. Proceso de instalación de apk mediante adb.
13/61
A través de adb es posible obtener el archivo APK de una aplicación instalada en el dispositivo. Las
aplicaciones se encuentran instaladas en el directorio /data/app/<package_name_app>/ y cuentan con el
archivo APK. Listar directamente estos directorios requiere que el dispositivo se encuentre rooteado.
Para listar los paquetes de aplicación instalados sin permisos de root se utilizará el siguiente comando:
pm list packages -f
En el siguiente ejemplo se puede observar el contenido del directorio donde se aprecia el archivo
APK.
Imagen 5.7. Listado de contenido del directorio de la apk.

Mediante el siguiente comando se obtendrá la APK del dispositivo en el directorio indicado:
Imagen 5.8. Proceso descarga del archivo APK de una aplicación instalada.
ADB se puede descargar desde el siguiente enlace:
https://developer.android.com/studio/releases/platform-tools#download
14/61
Finalmente es posible descargar las aplicaciones desde páginas de terceros proporcionando

solamente el enlace de la aplicación en el Play Store. Las aplicaciones se descargan a un Device ID del
dispositivo donde se instalarán, por lo que estas páginas cuentan con varios Device ID de esta forma
realizarán la descarga a través de la API de Play Store sin necesidad de instalar la aplicación. A
continuación, se presentan algunos ejemplos:
https://apkpure.com/app
https://apps.evozi.com/apk-downloader/
Imagen 5.9. Obtención de APK a través de APK Downloader.

Fuente: captura de la herramienta APK Downloader.
Esta opción resulta útil si no se desea instalar la aplicación en el dispositivo.
4.2.2. Decompilación del APK
Una vez se ha obtenido el fichero APK de la aplicación, es preciso descomprimirlo para obtener los
directorios y archivos que conforman la aplicación. A continuación, se detallan varios métodos para
realizar este proceso:
Uso de la herramienta Apktool. Se trata de una herramienta multiplataforma desarrollada en Java

que permite no solo descomprimir el archivo APK sino obtener el código SMALI comentado
anteriormente. Apktool puede ser descargado a través del enlace https://ibotpeaches.github.io/Ap
ktool/install/ .
A continuación se puede observar como mediante el siguiente comando se obtiene los archivos de la
aplicación:
java –jar apktool_2.3.2.jar d <nombre_apk>
15/61
Imagen 5.10. Decompilación de archivo APK mediante Apktool.

Cabe mencionar que Apktool permite obtener el archivo APK a partir de los archivos que lo conforman
mediante el comando:
java –jar apktool_2.3.2.jar b <directorio_código> <nombre_apk>
4.2.3. Obtención del código fuente
Una vez se ha descomprimido los archivos de la APK se puede observar como el código fuente se
encuentra en los archivos binarios con extensión .dex conocidos como “ Dalvik Executable” con estructura
similar a ASM (Assembly language).
Llegados a este punto, mediante la herramienta dex2jar se deberá convertir el código DEX en JAR y
posteriormente decompilarlo en Java para su entendimiento. Mediante el siguiente comando se obtendrá el
JAR a partir del archivo APK:
sh d2jar-dex2jar.sh -f <nombre_app.apk>
16/61
Imagen 5.11. Obtención del código fuente en formato JAR mediante dex2jar.
La herramienta dex2jar puede descargarse a través del siguiente enlace:
https://sourceforge.net/projects/dex2jar/files/latest/download
Cabe mencionar que, debido a las limitaciones de la propia herramienta, o si se han utilizado técnicas
avanzadas de ofuscación del código fuente, se puede dificultar el proceso de ingeniería inversa. En este
caso, se deberá recurrir a más bajo nivel y examinar el código SMALI, lenguaje de ensamblador utilizado
en DEX basado en JASMIN, el código de ensamblador para la máquina virtual de Java (JVM). Estas
representaciones quedarán fuera del alcance de este apartado, pero se presentan como alternativa a técnicas
avanzadas de análisis.
Una vez se han obtenido los archivos .jar se deberá obtener el código Java, por lo que se hará uso de la
herramienta jd-gui (http://jd.benow.ca/) para su conversión. Esta herramienta ofrece una interfaz gráfica para
visualizar el código fuente y un buscador que puede resultar útil para establecer patrones de búsqueda
dentro del código fuente de la app.
JD-GUI se ejecutará mediante el comando:
java -jar jd-gui-1.4.0.jar
Posteriormente, se abrirá el archivo .jar y se mostrará el código fuente de la aplicación, tal y como se
observa a continuación:
Imagen 5.12. Visualizar el código Java mediante jd-gui.
17/61
Fuente: captura de Java Decompiler.
Imagen 5.13. Visualizar el código Java mediante jd-gui.

Fuente: captura de Java Decompiler.
Es posible que el auditor desee obtener el código Java sin necesidad de una interfaz gráfica para realizar
patrones de búsqueda por línea de comandos con el uso, por ejemplo, de la herramienta nativa “grep”. En
este caso, se podría utilizar la herramienta jd-cmd (https://github.com/kwart/jd-cmd) para su obtención:
java -jar jd-cli.jar Droid-dex2jar.jar -od src/
El código decompilado se almacenará en el directorio indicado y podrá ser utilizado para realizar
búsquedas en todos los ficheros mediante el uso de la herramienta “grep”.
18/61
Imagen 5.14. Obtención de código java a través de jd-cli.

4.2.4. Reglas de detección y pruebas
Una vez descompilada la aplicación, se procederá a analizar su contenido. A continuación, se detallan

los archivos y directorios a analizar:
4.2.4.1. AndroidManifest.xml
Se trata del fichero XML de configuración donde se especifica toda la información que el dispositivo
precisa para poder determinar las acciones que llevará a cabo la aplicación en base a los permisos
(etiquetas XML definidas que indican las acciones permitidas por parte de la aplicación), requisitos de
software o hardware que se utilizarán durante la aplicación, la versión del sistema operativo y los
diferentes componentes que se ejecutarán en función de las notificaciones o eventos que se produzcan
en el sistema.
Puntos a revisar:
Permisos de la aplicación. En el archivo AndroidManifest.xml se definirán una serie de

permisos que permitirán a la aplicación interactuar tanto con componentes del hardware como
del software del dispositivo, véase la cámara, la tarjeta SD, el GPS, los contactos y sms del
dispositivo, archivos temporales (a veces compartidos con otras aplicaciones), etc. Si bien es
cierto que a partir de la versión de Android 6.0 se permite al usuario elegir de forma individual
qué permisos ofrece a la aplicación cuando esta se instala, es conveniente revisar si dichos
permisos son realmente necesarios.
A continuación, se detallarán algunos permisos susceptibles de ser utilizados de forma maliciosa:
19/61
Imagen 5.15. Permisos.

Fuente: elaboración propia.
Se requiere verificar si existe el atributo android:allowBackup=”false”. En caso de que no se

encuentre definido o cuente con el valor “true” se podrán realizar backups de la aplicación
mediante el siguiente comando adb:
adb backup –f <nombre_backup> <nombre_apk>
El hecho de que se puedan realizar backups de la aplicación permite a un tercero obtener una copia de
la aplicación y los datos que utiliza como por ejemplo bases de datos locales.
Se deberá revisar si existe el atributo android:debuggable=”true” lo que indicará que la

aplicación se encuentra en modo debug y cualquier persona con acceso físico al dispositivo
puede ejecutar código arbitrario en función de los permisos de esa aplicación sin necesidad de
obtener privilegios de root.
20/61
Se deberá comprobar que los elementos “ intent-filters ” que permiten la interacción entre los
diferentes componentes Activity de la aplicación cuentan con el atributo
android:exported=”false” definido. Por defecto, si no se encuentran definidos con este
atributo, se comportarán como si el valor fuese “true” y podrán ser utilizados por otras
aplicaciones, pudiendo exponer, modificar o eliminar la información o acciones que llevan a
cabo.
4.2.4.2. Certificado digital de la aplicación
CERTIFICADO.RSA: Para poder definir un propietario de la aplicación, esta deberá firmarse con un
certificado digital que se adjuntará en la aplicación (archivo con extensión .rsa en la mayoría de los
casos o .dsa) para poder verificar su firma. Google requiere que, para poder subir una aplicación en su
repositorio de aplicaciones (market), estas se encuentren firmadas y con un certificado adjunto.
Este certificado permitirá relacionar diferentes aplicaciones con un mismo propietario, en el caso de
que este haya utilizado el mismo certificado. También se deberá tener muy en cuenta la fecha de validez
de este certificado o si se encuentra revocado.
Para obtener información sobre el certificado, se deberá descomprimir el archivo apk como si se
tratase de un ZIP (es posible que previamente se deba cambiar la extensión a .zip). A continuación, se
utilizará la herramienta keytool mediante el siguiente comando:
Keytool –printcert –file META-INF/CERT.RSA
Imagen 5.16. Visualizar información de certificado mediante keytool.

Adicionalmente, es posible que la aplicación cuente con un directorio donde almacenar los
certificados de las aplicaciones web a las que realiza consultas o envía información como una medida de
protección a ataques “Man-in-the-Middle”. Durante el análisis estático es necesario identificar si cuenta
con certificados almacenados para poder evitar este tipo de protección, la cual será explicada en detalle
a lo largo de este módulo.
4.2.4.3. Recursos de la aplicación
21/61
En relación al resto de la aplicación, es necesario detectar si se hace uso de bases de datos locales
(archivos .db) que podrán ser consultados mediante sqlite browser. Las bases de datos suelen
encontrarse almacenadas en el directorio “/data/data/<package_name>/databases”.
Adicionalmente, es necesario identificar si la aplicación cuenta con archivos “ Shared Preferences ”

mediante los cuales se define la configuración de la aplicación en función de los datos del usuario, por
lo que pueden contener información sensible. Se trata de archivos XML almacenados en texto plano y
sin protección por defecto en el directorio “/data/data/<package name>/shared_prefs” para verificar si
cuentan con datos sensibles almacenados.
Finalmente, mediante la shell que proporciona adb, se deberá acceder a los datos de la aplicación
almacenados en el dispositivo, tanto en el directorio cache como donde se encuentre instalada la
aplicación (generalmente en /data/data/<package_name>), revisando los permisos de lectura, escritura y
ejecución de los archivos que la conforman.
NOTA: Es posible que para acceder a los directorios indicados se requieran permisos de root. En el
apartado de análisis dinámico se adjunta una guía para rootear el dispositivo Android.
4.2.4.4. Análisis de código fuente
A continuación, basándonos en la metodología explicada en el Módulo II, se presentan varios

ejemplos de análisis del código fuente con el fin de identificar patrones de búsqueda.
Credenciales en texto plano
Se deberán realizar búsquedas de usuario/contraseña, API Key o tokens de autenticación. Las

credenciales pueden estar definidas en variables tipo string, concatenadas en URL, en sentencias
SQL, etc.
Cabe mencionar que, si se encuentran escritas en comentarios, no podrán obtenerse al decompilar

la aplicación.
URL o IP expuestas en el código fuente
Recogen direcciones IP o URL que se encuentren escritas y permitan la identificación de

conexiones o recursos a los que accede la aplicación. De esta forma, es posible identificar si la
aplicación se conecta a un servidor externo no identificado para enviar información o descargar
archivos maliciosos que comprometan el dispositivo sobre el que se encuentra instalada la aplicación.
22/61
Salidas de Logs sin validar
Es bastante común que los desarrolladores hagan uso de mensajes de control y logs de la
aplicación para analizar su comportamiento, pudiendo filtrar información sensible. A continuación, se
muestran ejemplos de este tipo de mecanismos de control:
Log.i(...+var+...) Log.w(...+var+...)
Log.e(...+var+...) Log.d(...+var+...)
Log.wtf(...+var+...) Log.v(...+var+...)
System.out.print(“STRING”+var);
Cabe mencionar que, si el Log contiene el valor de una variable concatenado en un string y dicha
variable proviene de datos introducidos por el usuario, solo podrán ser obtenidos en tiempo de
ejecución durante el análisis dinámico.
Uso de cifrados de algoritmos débiles
Es preciso revisar si la aplicación hace uso de algoritmos de cifrado débil, especialmente si estos
se utilizan para almacenar o transmitir credenciales o datos sensibles. A continuación, se muestran
varios ejemplos de métodos que se verían afectados:
DESKeySpec des = new DESKeySpec();
MessageDigest digest = java.security.MessageDigest.getInstance(MD5);
MessageDigest digest = java.security.MessageDigest.getInstance(sha-1);
Cabe destacar que es muy común que las aplicaciones móviles utilicen codificaciones en Base64
para que la información no se altere al ser enviada a través del protocolo HTTP. Una mala práctica es
utilizar la codificación Base64 sobre datos sensibles en sustitución de algoritmos de cifrado por lo
que es conveniente revisar qué datos se codifican en Base64.
Algunas de las comprobaciones podrían ser las siguientes:
import android.util.Base64;
byte[] data = text.getBytes("UTF-8");
String base64 = Base64.encodeToString(data, Base64.DEFAULT);
byte[] data = Base64.decode(base64, Base64.DEFAULT);
String text = new String(data, "UTF-8");
23/61
Permisos definidos desde el própio código de la aplicación.
Tal y como se ha expuesto anteriormente, los permisos de la aplicación quedarían definidos en el

archivo AndroidManifest.xml; no obstante, es posible invocar permisos de los ficheros de
almacenamiento mediante el objeto Context desde el propio código fuente de la aplicación. Por tanto,
es necesario revisar el código fuente en busca de la siguiente estructura:
Context cx = new Context(Context.MODE_WORLD_READABLE);
Ficheros temporales
Es conveniente revisar si la aplicación crea ficheros temporales y qué información almacena en

éstos. En primer lugar, se deberá comprobar si cuenta con el permiso para escribir en la tarjeta SD o
en el dispositivo del teléfono y, posteriormente, si hace uso de métodos de escritura, como por
ejemplo la siguiente estructura:
Manifest permission: WRITE_EXTERNAL_STORAGE
File file;
file = File.createTempFile(filename, null, this.getCacheDir());
Implementación insegura de WebView
El componente WebView se utiliza en las aplicaciones Android para cargar contenido HTML de
forma dinámica. A través de WebView la aplicación puede ser susceptible a ataques de MITM o
XSS. Es preciso mencionar que, para verificar si este componente es vulnerable, se deberá realizar un
análisis dinámico de la aplicación. A continuación, se presentan varios ejemplos:
WebView habilita JavaScript (susceptible a XSS):
WebView webView = (WebView) findViewById(R.id.webView);
webView.getSettings().setJavaScriptEnabled(true);
webView.addJavascriptInterface(interface)
WebView omite los errores SSL, por lo que, si un certificado digital deja de ser válido, la
aplicación continuará su flujo de ejecución (susceptible a MitM):
public void onReceivedSslError(WebView view, SslErrorHandler handler, SslError

error) {
handler.proceed();
24/61
SQL Injection
Es posible detectar vectores potenciales de inyección SQL analizando el código fuente de la

aplicación. En primer lugar, se comprobará si la aplicación hace uso de librerías de gestión de bases
de datos, como por ejemplo “android.database.sqlite”. A continuación, se deberá detectar si las
consultas SQL cuentan con parámetros concatenados dentro de la instrucción y verificar si dichos
parámetros provienen directamente del usuario. Si esa sucesión de pasos se cumple, al realizar el
análisis dinámico es probable que sea vulnerable.
import android.database.sqlite;
cr = mDB.rawQuery( "SELECT * FROM sqliuser WHERE user = ’" + var + "’", null);
query = mDB.execSQL( "SELECT * FROM sqliuser WHERE user = ’" + var2 + "’", null);
Ejecución de comandos de sistema
Las aplicaciones Android pueden ejecutar comandos del sistema sobre el dispositivo en el que se
encuentran instaladas, pudiendo acceder a información del dispositivo, imágenes, datos que generan
otras aplicaciones, etc. A continuación, se muestra un ejemplo del método utilizado para la ejecución
de comandos:
getRuntime().exec(“ls -la”);
La criticidad aumenta cuando se concatena este tipo de métodos con una variable de tipo string
que recoge los datos que introduce el usuario.
Detección de dispositivo rooteado
La detección de dispositivo rooteado por parte de una aplicación puede ser una contramedida de
seguridad mediante la cual, si una aplicación es instalada en un dispositivo rooteado, ésta no permita
su ejecución.
Por otro lado, es lógico pensar que una aplicación maliciosa pueda realizar también
comprobaciones sobre el dispositivo rooteado para obtener información de éste, interactuar con
otras aplicaciones, acceder a sus datos, etc. Por este motivo, se deberá realizar un análisis en
profundidad de las partes del código involucradas en la detección de root, analizando por ejemplo si
la aplicación hace uso de las siguientes librerías o búsquedas en el dispositivo:
import com.noshufou.android.su;
import com.thirdpary.superuser;
import eu.chainfire.supersu;
isDeviceRooted();
RootTools.isAccessGiven();
25/61
.contains("test-keys");
/system/sd/xbin/su
/system/app/Superuser.apk
/system/bin/failsafe/su
En los próximos apartados se explicará cómo evadir la detección de dispositivo rooteado.
Aceptación de todos los certificados digitales
Con el fin de evitar errores a la hora de realizar conexiones HTTPS entre la aplicación móvil y la
aplicación web, debido a que el certificado digital no coincide con el nombre de dominio, no se
verifica el hostname del certificado. Este procedimiento se considera una mala práctica, puesto que
facilita que la aplicación móvil sea susceptible de ataques MitM. A continuación, se muestra un
ejemplo de detección de esta estructura:
import javax.net.ssl ;
private void untrust() {
HttpsURLConnection.setDefaultHostnameVerifier(NullHostnameVerifier);
}
Algoritmos inseguros de generación de números aleatorios
En referencia al uso de algoritmos de generación de números aleatorios, es conveniente revisar si la

aplicación hace uso de métodos inseguros especialmente para la generación de códigos OTP o PIN,
así como contraseñas de usuarios.
Un ejemplo de método aleatorio inseguro:
Math.random();
26/61
Obtención de datos del dispositivo
Es posible que la aplicación esté recolectando datos del dispositivo sin que el usuario sea
consciente. Entre esos datos podríamos destacar el IMEI del dispositivo donde se encuentra
instalada la aplicación o el número de la tarjeta SIM. Para ello se deberían verificar los siguientes
puntos:
import android.telephon.TelephonyManager
getSimSerialNumber();
getDeviceId();
Envío de SMS/MMS por parte de la aplicación
Es posible que la aplicación envíe SMS/MMS sin el consentimiento del usuario o bién se encuentre
mal implementado y pueda ser objeto de explotación para un envío masivo. Por este motivo es
recomendable revisar este tipo de funcionalidades. En primer lugar, se deberá revisar si cuenta con el
permiso correspondiente y si se hace uso de alguna estructura similar a las siguientes:
import android. telephony.SmsManager ;
sendTextMessage("phoneNo", null, "sms message", null, null);
sendIntent.setType("vnd.android-dir/mms-sms");
Localización activada
La aplicación puede estar consultando la geolocalización del dispositivo sin que el usuario sea
consciente. A continuación, se muestran diferentes ejemplos para localizar el dispositivo móvil:
27/61
GPS Estación Base
import import
com.android.location; android.telephony.TelephonyManager;
getLastKnownLocation(); import
android.telephony.gsm.GsmCellLocation;
requestLocationUpdates(); getCellLocation();
getLatitude();
getLongitude()
Campos ocultos
Las aplicaciones pueden contener campos ocultos en los que se puede almacenar información para
la gestión de sesiones, por ejemplo, tokens o API-Keys, que se enviarán junto con el usuario y la
contraseña.
Por otro lado, es posible que la aplicación cuente con elementos ocultos, por ejemplo, botones,
que el usuario esté accionando sin conocimiento alguno. A continuación, se presentan algunos
métodos o atributos para revisar su funcionalidad:
setVisible(View.invisible);
android:visibility=invisible
android:background=@null
4.2.5. Herramientas y frameworks
En este apartado se presentan varias herramientas que facilitan la obtención del código fuente y realizan
un análisis estático de la aplicación de forma automática basándose en reglas similares a las expuestas en el
apartado anterior:
Mobile Security Framework (MOBSF)
Se trata de una herramienta multiplataforma desarrollada en Python que permite tanto el análisis
28/61
Se trata de una herramienta multiplataforma desarrollada en Python que permite tanto el análisis
estático como el dinámico.
Comandos de instalación:
git clone https://github.com/MobSF/Mobile-Security-Framework-MobSF.git
cd Mobile-Security-Framework-MobSF
python3 -m pip install -r requirements.txt
Para ejecutarlo se utilizará el comando “python3 manage.py runserver” que creará un servidor web en
el puerto 8000 por defecto.
Finalmente, el usuario solo deberá acceder a la URL http://127.0.0.1:8000 y subir el archivo APK para
su análisis. Una vez finalizado mostrará un panel donde se detallan las vulnerabilidades, se permite
realizar búsquedas en el código fuente de la aplicación, etc.
Imagen 5.17. Análisis estático con MobSF.

Fuente: captura de la herramienta MobSF.
29/61
SUPER Android Analyzer
Se trata de una herramienta multiplataforma de análisis estático desarrollada en Rust. Cuenta con unos
tiempos de análisis muy cortos debido a que pretende realizar todas las fases de decompilación y
obtención del código sin dependencias externas.
Para descargarlo e instalarlo en función de la plataforma: http://superanalyzer.rocks/download.html
Para su ejecución :
super {apk_file}
La aplicación será decompilada en el directorio dist/, mientras que el informe de resultados se

generará en HTML en el directorio results/{package_name}. El informe cuenta con una opción de
visualizar el código con un snippet del código que ha detectado vulnerable tal y como se muestra a
continuación:
Imagen 5.18. Informe de análisis estático SUPER.

Fuente: captura de la herramienta SUPER Android Analyzer.
Anotación: Otras herramientas
Existen múltiples herramientas automáticas para análisis de aplicaciones Android. En el siguiente

enlace se recogen varias herramientas categorizadas por tipos de análisis y funcionalidades:
https://mobilesecuritywiki.com/
4.3. Análisis dinámico
4.3.1. Configuración del entorno
30/61
Para realizar un análisis dinámico de la aplicación es necesario que se configure el dispositivo o emulador
para poder interceptar el tráfico que genere la aplicación y poder así revisar las acciones y peticiones que
ésta realiza. Para ello se hará uso del proxy inverso utilizado anteriormente para las aplicaciones web Burp
Suite.
En este caso se debe diferenciar entre las versiones de Android anteriores a la 7.0 y las posteriores,
puesto que el proceso de configuración varía.
Adicionalmente, si se utiliza un dispositivo físico es posible que se requiera que este cuente con
permisos de root para ejecutar o instalar ciertos comandos adb. A continuación, se adjunta una guía para
poder rootear el dispositivo:
https://www.xda-developers.com/root/
Interceptación del tráfico en versiones de Android anteriores a 7.0
Como se ha explicado anteriormente, para interceptar el tráfico HTTPS es preciso instalar el

certificado de Burp como certificado de confianza en el dispositivo y redirigir todo el tráfico a través a
la interfaz de escucha.
Para ello, en primer lugar, se obtendrá la IP del host donde se ejecuta Burp y el puerto de escucha;
para ello se deberá seleccionar la opción de habilitar todas las interfaces de red en el proxy.
Imagen 5.19. Configuración de interfaz externa del proxy de Burp.

Fuente: captura de Burp Suite.
Posteriormente, se conectará el dispositivo a la misma red wifi que el host que ejecuta Burp y en
opciones avanzadas se configurará el proxy con la IP y el puerto, tal y como se muestra a continuación:
31/61
Imagen 5.20. Configuración del dispositivo móvil para redirigir el tráfico al proxy de Burp.
Fuente: captura de la configuración de un dispositivo móvil con Android.
Llegados a este punto, si se accede a la url “http://bup” se podrá descargar el certificado con la
extensión “.der”, que el dispositivo no puede reconocer. Por ese motivo es necesario cambiar la
extensión a “.cer” y posteriormente instalar el certificado como se observa a continuación:
Imagen 5.21. Instalación de certificado de Burp en dispositivo Android 6.0.

Fuente: captura de un dispositivo móvil con Android.
Finalmente, si se navega a una página web con HTTPS o si una aplicación realiza conexiones a un
servidor web con HTTPS, el tráfico será redirigido e interceptado por Burp, pudiendo cambiar los
parámetros antes de ser enviados.
Interceptación del tráfico en versiones de Android posteriores a 7.0
32/61
A partir de la versión 7.0 de Android, se ha introducido un mecanismo para evitar que las
aplicaciones consulten certificados instalados en el dispositivo por parte del usuario y dificultar de esta
forma el uso de proxies inversos para interceptar el tráfico. Por defecto, todas las aplicaciones utilizarán
únicamente certificados digitales de autoridades de certificación instalados en el dispositivo.
De esta forma, si se desea utilizar un certificado instalado por el usuario, se deberá indicar dentro de
la propia aplicación, en el archivo AndroidManifest.xml a través del uso del atributo
“ android:networkSecurityConfig” indicando la ruta al certificado digital o si se permite el uso de
certificados de usuario, tal y como se observa en el siguiente ejemplo:
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
<domain-config>
<domain includeSubdomains="true">example.com</domain>
<trust-anchors>
<certificates src="user"/>
</trust-anchors>
</domain-config>
</network-security-config>
Para realizar este proceso se deberá decompilar la aplicación, modificar AndroidManifest.xml y

volver a compilar la aplicación para su posterior instalación. Este proceso se puede llevar a cabo
mediante la herramienta Apktool, tal y como se ha explicado anteriormente. Con el fin de agilizar el
proceso y llevarlo a cabo de forma automática, se utilizará la siguiente herramienta:
https://github.com/levyitay/AddSecurityExceptionAndroid
Se ejecutará el script indicando la ruta al archivo APK. Si es la primera vez que se ejecuta y no se
cuenta con una clave de debugging en Android, se creará un par de claves RSA junto con el
correspondiente keystore para firmar la aplicación una vez se haya recompilado.
Una vez haya finalizado la ejecución del script, se creará una copia de la aplicación con el nombre
“_new.apk” que contará con el AndroidManifest.xml modificado. Llegados a este punto, solo restará
instalar la aplicación en el dispositivo tal y como se ha explicado anteriormente.
33/61
Imagen 5.22. Ejecución de script para recompilar la aplicación y que utilice certificados de usuario.
Como alternativa al proceso anterior, si a partir de Android 7.0 solo se admiten certificados digitales
instalados como autoridades de certificación, es posible instalar el certificado de Burp como tal
mediante el uso de los siguientes comandos. Es preciso indicar que se requiere privilegios de root sobre
el dispositivo.
Obteniendo el certificado de Burp como cacert.cer, se ejecutará el siguiente comando:
openssl x509 -inform PEM -subject_hash_old -in cacert.cer | head -1
En este caso se obtiene como output “ 9a5ba575” por lo que se renombra el certificado de la siguiente
forma:
mv cacert.cer 9a5ba575.0
A continuación, se deberá introducir el certificado en el dispositivo, por ejemplo, a través de la tarjeta

SD en el directorio “ Downloads ” para instalar el certificado en el dispositivo:
adb shell
su
mount –o remount,rw /system
mv /sdcard/Downloads/9a5ba575.0 /system/etc/security/cacerts
chmod 644 /system/etc/security/cacerts/9a5ba575.0
Imagen 5.23. Instalación de certificado de Burp en dispositivo Android 7.0 (sistema).

Fuente: captura de la configuración de un dispositivo móvil con Android.
34/61
Información de ejecución con adb
Mediante adb se pueden obtener los logs de la aplicación en tiempo de ejecución. Para ello, se hace
uso de la funcionalidad logcat para observar las acciones, mensajes de depuración, llamadas internas e
información del dispositivo que se genera tras las interacciones del usuario con la aplicación. Si bien es
cierto que la velocidad y la cantidad de registros puede ser elevada, se recomienda obtener la salida en
un archivo para su posterior análisis. El comando es el siguiente:
adb shell
jfltexx:/ $ logcat -f /sdcard/Download/output.txt
4.3.2. Análisis dinámico de la aplicación
Para llevar a cabo el análisis dinámico de la aplicación se deberá revisar la interacción de la aplicación en
dos fases:
Interacción de la aplicación con el dispositivo interno
Se deberá revisar qué tipo de información almancena la aplicación en el dispositivo, tal y como se ha
mencionado en el apartado de metodología. Se deberá prestar especial atención a los datos almacenados
relacionados con credenciales, archivos de configuración, perfilados de usuarios, archivos temporales, etc.
Interacción de la aplicación con servidores web externos
La mayoría de aplicaciones móviles interactúan con un servidor externo para intercambiar información.
En este apartado se utilizarán los campos de datos de la aplicación para analizar la respuesta del servidor
externo.
Llegados a este punto, la aplicación se analizará como si se tratase de una aplicación web donde el
navegador en este caso es la propia aplicación móvil, a través de la que se interactuará con el servidor. Por
este motivo, la metodología de análisis a seguir será la misma que la que se ha explicado en el módulo de
aplicaciones web.
4.3.3. Evasión de las principales contramedidas
En este apartado se plantean las principales contramedidas para evitar que las aplicaciones Android
puedan ser analizadas y susceptibles de interceptar las comunicaciones que realizan con el servidor web
correspondiente. De esta forma, se dificultarían varios de los puntos explicados en este módulo.
Certificate Pinning
Esta contramedida se basa en asegurar que la aplicación móvil únicamente realiza el intercambio de
información con el servidor web legítimo. De esta forma se dificulta la intercepción del tráfico mediante
el uso de proxies inversos, como se ha explicado en anteriores apartados.
35/61
Para ello se requiere que la aplicación verifique que el certificado del servidor al que se realizan las
peticiones coincide el certificado digital que tiene precargado dentro del APK.
Para poder evitar esta contramedida, se deberá modificar en tiempo de ejecución las partes de código
que llevan a cabo dicha comprobación. Para ello se hará uso de la herramienta Frida
(https://www.frida.re/), que permite la inyección de código JavaScript en tiempo de ejecución de las
aplicaciones.
A continuación se especifican los comandos para realizar la instalación y el código JavaScript que se
utilizará para evitar el certificate pinning. Previamente, se debe descargar la última versión de frida-server
para la arquitectura correspondiente al dispositivo desde la siguiente url: https://github.com/frida/frida/rel
eases
Una vez más, se requiere un dispositivo virtualizado o con permisos de root para su ejecución.
sudo pip install Frida
adb push ~/Downloads/frida-server-XX.X.XX-android-arm /data/local/tmp/frida-server
adb shell
su
setenforce 0
cd /data/local/tmp
chmod 755 frida-server
./frida-server &
A continuación, se deberá crear el archivo JavaScript que realizará la evasión. A grandes rasgos, la
evasión se lleva a cabo al monitorizar la ejecución del código de la aplicación y, por ejemplo, si se
ejecuta el método de verificación del certificado y este devuelve un valor “true” si es correcto, el código
JavaScript se encargará de devolver un valor “true” sin realizar la ejecución del método.
El código JavaScript para esta evasión se puede obtener de la siguiente URL y se deberá almacenar
en el código un fichero con extensión “ .js ”:
https://codeshare.frida.re/@pcipolloni/universal-android-ssl-pinning-bypass-with-frida/
Finalmente, se ejecutarán los siguientes comandos para utilizar el certificado de Burp en lugar del
certificado que utilice la aplicación para su comprobación:
adb push burpca-cert-der.crt /data/local/tmp/cert-der.crt
frida -U -f <package_name> -l <certificatePinningBypass.js> --no-pause
Detección de dispositivo rooteado
36/61
Esta contramedida pretende detectar si el dispositivo se encuentra rooteado con el fin de evitar que
otras aplicaciones puedan acceder a los datos que genere la aplicación o evitar que se pueda hacer uso
de software para interceptar las comunicaciones y/o acciones que se realicen. Estas medidas se basan en
que la aplicación solicita permisos de root: si el dispositivo se los concede, se detectará que el
dispositivo se encuentra rooteado. Adicionalmente, se suele realizar una búsqueda de las aplicaciones
comunes que otorgan dichos permisos, tal y como se ha explicado en el apartado de análisis del código
fuente.
En el caso de que la aplicación esté comprobando si aplicaciones como “ Superuser.apk” se

encuentran instaladas, una contramedida simple es renombrar el archivo de la aplicación, por ejemplo
como “ Superuser0.apk” en el directorio “ /system/app ” mediante adb.
Si se utiliza la herramienta Frida explicada anteriormente, se deberá analizar previamente el código

fuente de la aplicación para detectar en qué clases y qué métodos se utilizan para realizar la verificación
de root. A continuación, se presenta el código JavaScript para devolver un valor “false” cada vez que se
ejecuten métodos como “isDeviceRooted” o “checkRootMethod1”. Cabe mencionar que los métodos
que aparecen a continuación se han detectado en la clase “utils.RootUtil”, que se almacenará en la
variable Activity.
Java.perform(function () {
var Activity = Java.use(<package_name>.utils.RootUtil')
Activity.isDeviceRooted.implementation = function (){
console.log('Patch isDeviceRooted');
return false;
Activity.checkRootMethod1.implementation = function (){
console.log('Patch checkRootMethod1');
return false;
Activity.checkRootMethod2.implementation = function (){
console.log('Patch checkRootMethod2');
return false;
});
37/61
Este código deberá ser almacenado como un archivo .js y ejecutar el siguiente comando una vez se ha
configurado el servidor de frida, tal y como se ha especificado anteriormente:
frida --no-pause -U -l rootDetectionBypass.js –f <package_name>
Adicionalmente, se puede hacer uso de aplicaciones como RootCloak, incluida en el módulo del
framework Xposed. La instalación de Xposed, así como de los módulos que lo conforman, se
consideran fuera del alcance de este módulo, por lo que en los siguientes enlaces se puede obtener
información sobre este punto:
https://www.xda-developers.com/xposed-framework-for-android-oreo-beta/
https://techviral.net/install-xposed-framework-in-android/
4.4. Aplicaciones vulnerables
A continuación, se presentan varias aplicaciones Android vulnerables para poder realizar

pruebas siguiendo la metodología y los conceptos explicados en los apartados anteriores:
GoatDroid (https://github.com/jackMannino/OWASP-GoatDroid-Project/tree/android).
Diva (https://github.com/payatu/diva-android).
InsecureBanking2 (https://github.com/dineshshetty/Android-InsecureBankv2).
DVHA (https://github.com/logicalhacking/DVHMA)
V. Aplicaciones móviles iOS

En este apartado se desarrollan las actividades que involucran el análisis de las aplicaciones móviles de
iOS.
Desde el punto de vista del análisis estático, se examinarán todos los archivos que constituyen el
aplicativo móvil, profundizando en el análisis del código, los archivos de configuración y la información
almacenada en el dispositivo durante su ejecución (como, por ejemplo, información de la sesión del
usuario, información almacenada en bases de datos, etc.).
En relación al análisis dinámico, se mostrarán las técnicas para capturar el tráfico en tiempo real y se
analizarán las distintas herramientas y los métodos que permiten eludir las medidas de evasión
implementadas en el aplicativo para dificultar su análisis.
5.1. iOS (iPhone OS)
38/61
iOS es el sistema operativo utilizado en los dispositivos móviles de Apple, incluyendo el iPhone, iPad y
iPod Touch. iOS está basado en Darwin, cuyo kernel híbrido combina componentes de FreeBSD y Mach.
Las aplicaciones se ejecutan en un entorno restrictivo (sandbox) aisladas unas de otras y del sistema de
archivos.
Las aplicaciones se distribuyen a través de la Apple Store y son sometidas a un proceso de revisión de
código (App Review) https://developer.apple.com/app-store/review/ para asegurar su fiabilidad,
funcionamiento esperado y cumplimiento del código ético.
Además, es posible instalar aplicaciones que no provienen de la Apple Store en un dispositivo sin
jailbreak:
Mediante Enterprise Mobile Device Management (MDM), que requiere un certificado empresarial
firmado por Apple https://developer.apple.com/programs/enterprise/
Aplicaciones firmadas con un certificado de tipo desarrollador
https://developer.apple.com/support/certificates/
5.2. Entorno de pruebas para el análisis de aplicaciones iOS

En este apartado se introducen los procesos y las técnicas básicas para analizar los fallos de seguridad
en aplicaciones iOS.
Los requisitos mínimos para construir un entorno de pruebas son los siguientes:
Ordenador con privilegios de administrador.

Red wifi.
Dispositivo iOS con jailbreak:
Cydia.
OpenSHH.
Frida.
BigBoss Tools.
adv-cmds.
Class Dump.
Substrate.
AppSync.
Radare2 Suite.
iOS SSL Kill Switch.
Keychain Dumper.
Clutch.
Dumpdecrypted.
39/61
IPAinstaller.
Burp Suite Proxy.
Puede encontrar más información sobre la instalación de los componentes en el siguiente enlace:
https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06b-Basic-Security-Testing.
md
5.3. Análisis estático

Durante la fase de análisis estático se examinan los componentes de la aplicación sin llegar a ejecutarse.
Para realizar el análisis estático del aplicativo es necesario disponer del archivo IPA. Este formato de
archivo es utilizado por las aplicaciones de Apple en los dispositivos iPhone, iPad y iPod Touch.
5.3.1. Archivo IPA
Una vez instalada la aplicación en el dispositivo, se puede extraer el archivo IPA para su posterior
análisis, mediante diversas técnicas:
Obtener el archivo IPA vía iTunes:
1. Descargar la aplicación vía iTunes y realizar la sincronización de las aplicaciones.

2. Acceder a la ruta donde se almacenan las aplicaciones IPA (es posible realizar una
búsqueda, en el sistema de archivos, de la extensión .ipa para localizar la ubicación
exacta).
/Users/<usuario>/Music/iTunes/iTunes Media/Mobile Applications
Imagen 5.24. Aplicaciones de iOS IPA.

Fuente: captura de la herramienta iTunes.
Realizar un backup del dispositivo vía iTunes y extraer el archivo IPA de la siguiente ruta:
/Users/<user>/Library/Application\ Support/MobileSync/Backup/
40/61
En caso que se disponga del archivo IPA (sin que haya sido descargado de la Apple Store) y sea
necesario instalarlo en el dispositivo, se puede utilizar la herramienta CydiaImpactor
http://www.cydiaimpactor.com la cual permite instalar aplicaciones en dispositivos que no tengan realizado
el jailbreak.
Las aplicaciones para dispositivos iOS se distribuyen en archivos IPA (iOS App Store Package), cuyo
formato ZIP comprimido contiene el código y los recursos necesarios para su ejecución (el archivo binario
de la aplicación, los archivos de configuración, las librerías e imágenes necesarias para su funcionamiento).
La estructura de directorios del archivo IPA es la siguiente:
/Payload/: carpeta que contiene todos los archivos que constituyen la aplicación.
/Payload/Application.app: contiene el código ARM compilado y los recursos estáticos.
/iTunesArtwork: imagen de la aplicación.
/iTunesMetada.plist: información que incluye el identificador del desarrollador, bundle ID,
información de copyright, fecha de lanzamiento, etc.
/WatchKitSupport/WK: extensiones para interactuar con Apple Watch.
Imagen 5.25. Contenedor del archivo IPA.

Examinando más detenidamente los archivos incluidos en el contenedor Application.app:
41/61
Imagen 5.26. Mostrar contenido archivo IPA.

Apple define una estructura de directorios y archivos para las aplicaciones, en las que se encuentran:
MyApp: binario ARM compilado con el código de la aplicación.

Application: Iconos de la aplicación.
Info.plist: archivo de configuración que contiene el bundle ID, número de versión, nombre de la
aplicación, etc.
Imágenes: Imágenes de la interfaz de la aplicación.
MainWindow.nib: objetos cargados al lanzar la aplicación.
Settings.bundle: preferencias de la aplicación.
Recursos adicionales: subdirectorios que incluyen diccionarios de lenguaje, archivos de sonido,
archivos de configuración, imágenes, archivos con strings de texto, etc.
42/61
Imagen 5.27. Contenido de Application.app.

Fuente: captura de directorios y archivos en Apple.
5.3.2. Estructura del aplicativo en el dispositivo local
Mediante acceso vía SSH al dispositivo móvil, es posible examinar los archivos almacenados de forma
local en el dispositivo.
Para identificar la ruta donde está ubicada la aplicación, se puede ejecutar el siguiente comando:
# find / -type f -iname “*APP_NAME*”
Dentro del directorio /var/mobile/Containers/ se encuentran las aplicaciones instaladas mediante Apple
Store, IPA Installer y Cydia.
Las aplicaciones se identifican mediante UUID (Universal Unique Identifier).
Una vez localizada la aplicación, el contenido se desglosa en los siguientes directorios:
43/61
/var/mobile/Containers/Bundle/Application/[UUID]/Application.app
/var/mobile/Containers/Data/Application/[UUID]/Documents
/var/mobile/Containers/Data/Application/[UUID]/Library
/var/mobile/Containers/Data/Application/[UUID]/tmp
Imagen 5.28. Contenido de la Aplicación.

Fuente: captura del desglose de la Aplicación en Apple.
5.3.3. Información almacenada en el dispositivo local
La protección de la información sensible (credenciales de usuario, capturas de pantalla con información

sensible, bases de datos con información confidencial, tokens de sesión, etc.) es un aspecto fundamental
para la seguridad en dispositivos móviles.
iOS pone a disposición de los desarrolladores varias API para el almacenamiento de datos y hacen uso
del hardware criptográfico disponible en los dispositivos con sistema operativo iOS.
5.3.3.1. Archivos de configuración
Los archivos de configuración (o propiedades) se identifican mediante la extensión .plist, y se

almacenan tanto en el archivo IPA como en el contendor sandbox dentro del dispositivo móvil.
44/61
Para localizar los archivos de configuración en el sistema de archivos del dispositivo, se puede
ejecutar el siguiente comando:
# find * . -name *.plist
Los archivos de propiedades .plist tienen un formato binario y requieren de utilidades específicas
para poder leer su contenido. La siguiente utilidad permite convertirlos a xml:
# plutil -convert xml1 <file>.plist
# plutil -p Info.plist
De igual forma, se pude emplear para mostrar el contenido de archivos que contienen cadenas o
strings del aplicativo.
# plutil -p *.app/en.lproj/Localizable.strings
En caso que no se disponga de acceso al sistema de ficheros del dispositivo (por ejemplo, si el
dispositivo no tiene jailbreak), existen herramientas que permiten recuperar la información almacenada en
los backups de iTunes y iCloud:
iPhone Backup Extractor https://www.iphonebackupextractor.com/
5.3.3.2. Bases de datos
Es importante revisar las bases de datos que utiliza la aplicación para almacenar la información en
local e identificar si contienen información sensible sin cifrar.
Para ello, se buscan extensiones del tipo: *.sqlite, *.dat , *.db
# find . -name *.db
# sqlite3 <base_datos>.db
Se pueden extraer mediante SFTP las bases de datos del dispositivo y utilizar un cliente de SQLite htt
p://sqlitebrowser.org/ para mostrar su contenido.
5.3.3.3. Keychain
El Keychain se utiliza para almacenar datos sensibles como son las llaves de cifrado, tokens de sesión
o la información de autenticación. Su implementación es similar a una base de datos SQLite, y solo se
puede acceder a través de las API específicas para Keychain.
Esta base de datos está localizada en la siguiente ruta:
/private/var/Keychains/keychain-2.db
Para extraer el contenido almacenado en Keychain, se puede ejecutar la siguiente utilidad en el

dispositivo móvil https://github.com/ptoomey3/Keychain-Dumper:
45/61
# ./keychain_dumper
Imagen 5.29. Extracción de contenido en Keychain.

Fuente: github.com/ptoomey3/Keychain-Dumper.
Se debe revisar que la información sensible ha sido configurada con las clases Data Protection
adecuada.
kSecAttrAccessibleAfterFirstUnlock
kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly
kSecAttrAccessibleAlways
kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly
kSecAttrAccessibleAlwaysThisDeviceOnly
kSecAttrAccessibleWhenUnlocked
kSecAttrAccessibleWhenUnlockedThisDeviceOnly
El siguiente enlace muestra información más detallada respecto las clases de acceso de Data
Protection:
https://developer.apple.com/documentation/security/keychain_services/keychain_items/item_attribute
_keys_and_values#1679100
Por otra parte, si una aplicación se desinstala en el dispositivo, la información permanece almacenada
en el Keychain.
Por ello, se debe comprobar que los datos no se mantienen tras volver a reinstalar la aplicación. Para
ello está disponible needle framework https://github.com/mwrlabs/needle permitiendo la lectura del
Keychain, como se muestra a continuación:
46/61
Imagen 5.30. Lectura del Keychain en needle framework.

Fuente: https://github.com/mwrlabs/needle.
5.3.3.4. Cookies de sesión
Las cookies de sesión se encuentran almacenadas en el fichero llamado Cookies.binarycookies.
Para poder acceder a su contenido se puede ejecutar el siguiente script en Python.
# python BinaryCookieReader.py
Adicionalmente, se puede extraer el archivo mediante SFTP y utilizar un editor hexadecimal para
acceder a su contenido, o mediante una de las funcionalidades que incluye el framework needle.
Imagen 5.31. Framework needle.

Fuente: https://github.com/mwrlabs/needle.
5.3.4. Análisis del binario
Desde la perspectiva de la ingeniería inversa, se pone especial énfasis en el análisis del binario, para
entender cómo funciona la aplicación. Para ello es necesario:
Identificar la información general del binario.

Identificar la arquitectura para la que fue compilado.
Identificar las clases.
47/61
Identificar los símbolos.

Identificar los strings.
Verificar si los flags de seguridad han sido activados.
5.3.4.1. Descifrado y extracción del binario
Las aplicaciones descargadas de la Apple Store vienen cifradas con un par de claves
públicas/privadas generadas al crear la cuenta en iTunes y, posteriormente, son transferidas al
dispositivo tras el proceso de autenticación en iTunes.
Para analizar el archivo ejecutable, es necesario descifrarlo desde el dispositivo móvil y así poder
extraerlo para su posterior análisis.
En primer lugar, se debe identificar si la aplicación está cifrada, identificado el bit de cifrado. El
campo cryptid de la propiedad LC_ENCRYPTION_INFO identifica si la aplicación ha sido cifrada o
no.
cryptid 1: Aplicación cifrada
cryptid 0: Aplicación no cifrada
Ejecutando el siguiente comando, se identifica el valor del campo cryptid:
# otool -l <binary> | grep LC_ENCRYPTION_INFO -A5
Una vez se ha identificado si el binario está cifrado o no, hay disponibles varias utilidades para
descifrar el binario. Entre ellas se encuentran Clutch y dumpdecrypted.
Estas herramientas han de ser instaladas en un dispositivo con jailbreak.
https://github.com/stefanesser/dumpdecrypted
https://github.com/KJCracks/Clutch
Imagen 5.32. Clutch.
48/61
Fuente: https://github.com/KJCracks/Clutch.
5.3.4.2. Extracción de información del binario
Para identificar la arquitectura para el que fue compilado el binario, los símbolos o strings y para
identificar si el binario ha sido cifrado, etc., se puede utilizar la herramienta rabin2 dentro de la suite de
radare2 https://github.com/radare/radare2
Los siguientes comandos permiten obtener la información del binario, el listado de los sub-binarios y
extraerlos para su posterior análisis:
$ rabin2 -I <APP>
$ rabin2 -A <APP>
$ rabin2 -x <APP>
Para extraer los símbolos y strings , se pueden ejecutar los siguientes comandos:
$ rabin2 -s <APP>
$ rabin2 -z <APP>
5.3.4.3. Extracción de las clases del binario
Para realizar el volcado de las clases se puede utilizar la herramienta Class Dump.
https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/networkpx/class
-dump-z_0.2a.tar.gz
# /usr/bin/class-dump-z <APP> > file
La herramienta Clutch (https://github.com/KJCracks/Clutch) es muy completa y facilita las tareas, ya

que permite descifrar el binario, extraer información y realizar el volcado de las clases.
Para obtener un listado de las aplicaciones dispones:
Imagen 5.33. Listado de aplicaciones.

Para realizar un volcado de la aplicación:
49/61
Imagen 5.34. Volcado de aplicación.

En el siguiente enlace se encuentra disponible un tutorial sobre la herramienta:
https://github.com/KJCracks/Clutch/wiki/Tutorial
5.3.5. Frameworks para el análisis del archivo IPA
Hay disponibles varios frameworks que permiten realizar el análisis estático de la aplicación.
Estas herramientas permiten obtener información de los archivos de configuración, las clases de las que
hace uso el binario, librerías, strings , etc., e identifican posibles vulnerabilidades y/o errores de
configuración.
50/61
Mobile Security Framework (MobSF)
https://github.com/MobSF/Mobile-Security-Framework-MobSF
MobSF permite llevar a cabo análisis estático y dinámico (este caso solo está disponible para
aplicaciones Android) y ejecutar pruebas sobre la API web.
Además, extrae información de la aplicación y ejecuta un análisis del binario, de los ficheros que
componen la aplicación, las librerías, etc.
Imagen 5.35. Análisis estático MobSF.

Fuente: captura de la herramienta MobSF.
51/61
Passionfruit
https://github.com/chaitin/passionfruit
Passionfruit es una herramienta que permite analizar desde una perspectiva de caja negra aplicaciones
móviles iOS.
Soporta dispositivos sin jailbreak y ofrece una consola web como interfaz de usuario.
Extrae información de la aplicación, del archivo de configuración y de capturas de pantalla

almacenadas en el dispositivo y comprueba si la aplicación ha sido cifrada y tiene habilitados los flags
de seguridad (PIE, ARC y stack canary).
Imagen 5.36. Análisis estático Passionfruit.

Fuente: captura de la herramienta Passionfruit.
Así mismo, esta herramienta permite mostrar las bases de datos y archivos de configuración “plist”
almacenados en el dispositivo móvil, BinaryCookies o descargar el Keychain y el resto de archivos para
su posterior análisis.
52/61
Brida
https://github.com/federicodotta/Brida
https://techblog.mediaservice.net/2018/04/brida-a-step-by-step-user-guide/
Brida es una extensión de Burp Suite que trabaja como puente entre Burp Suite y Frida, permitiendo
manipular el tráfico entre el aplicativo móvil y los servicios publicados en el backend .
Imagen 5.37. Interfaz de Brida.

Fuente: captura de la herramienta Brida.
5.4. Análisis dinámico de la aplicación móvil

En la fase de análisis dinámico se analiza la aplicación en tiempo de ejecución. El análisis dinámico
engloba las pruebas manuales y/o automáticas y su objetivo es analizar las peticiones y respuestas entre la
API del aplicativo y los servicios web del backend .
El análisis dinámico se utiliza para asegurar que los mecanismos de seguridad poseen las protecciones
suficientes contra los ataques más frecuentes, como, por ejemplo, revelación de información sensible
transmitida por los canales de comunicación, fallos en la autenticación y autorización y/o errores de
configuración en el servidor.
En este apartado no se tratará el análisis de vulnerabilidades contra los servicios web publicados en el
backend, debido a que la información correspondiente se puede encontrar en el Unidad 2 de este módulo.
En cambio, se centrará en la instalación del certificado para capturar el tráfico del aplicativo y en las
técnicas para evadir contramedidas implementadas para dificultar el análisis del tráfico.
53/61
5.4.1. Instalación del certificado para el análisis del tráfico con Burp Suite
Una vez se ha iniciado Burp Proxy en el ordenador, se debe visitar la siguiente ruta desde el dispositivo
móvil http://<IP_Ordenador>:<Puerto> (IP y puerto donde está el proxy iniciado), y hacer clic en el
enlace “CA Certificate” para descargar el certificado raíz CA de Burp e instalarlo en el dispositivo móvil.
Imagen 5.38. Proceso de instalación del certificado raíz CA de Burp Proxy.

Fuente: captura de Burp Suite Professional.

Fuente: captura de la interfaz de un dispositivo con sistema operativo iOS.

54/61
Figura 30 – Proceso de instalación del certificado raíz CA de Burp Proxy
Para interceptar el tráfico HTTP(S), se configura el proxy en el dispositivo móvil que apuntará a la IP y
puerto en el que está funcionando Burp Proxy.
Imagen 5.41. Configuración del proxy.

Navegando por la aplicación, el tráfico es capturado por el proxy, mediante el cual se pueden interceptar
y modificar peticiones de la misma forma que durante un análisis de tráfico web.
5.4.2. Bypass de los controles para dificultar el análisis dinámico
Con más frecuencia los desarrolladores incluyen controles en las aplicaciones para obstaculizar el
análisis dinámico, como son SSL Pinning o cifrado End-to-End (E2E), los cuales previenen la
interceptación y manipulación del tráfico del aplicativo.
Otro mecanismo es la detección de jailbreak, el cual impide que la aplicación sea ejecutada en un
dispositivo con jailbreak, dificultando así el uso de herramientas avanzadas.
Para deshabilitar la validación de SSL Pinning, se puede utilizar la herramienta SSL Kill Switch 2 https://g
ithub.com/nabla-c0d3/ssl-kill-switch2 que parchea las funcionalidad de SSL a bajo nivel y también
deshabilita la verificación del certificado SSL.
5.4.2.1. Frida
55/61
Frida https://www.frida.re/ es un framework de instrumentación dinámica que permite inyectar código

en los procesos, modificar funciones o trazar el código privado de la aplicación.
Es te framework es útil, ya que permite saltar la detección de jailbreak reemplazando la función

implementada por la aplicación.
Mediante el siguiente comando se trazan las llamadas que realiza el aplicativo cuando invoca a la
función que comprueba si el dispositivo tiene jailbreak o no.
$ frida-trace -U -f /Applications/DamnVulnerableIOSApp.app/DamnVulnerableIOSApp -m
"-[JailbreakDetectionVC isJailbroken]"
El comando arranca la aplicación y se crea un script en JavaScript, que permite modificar los
métodos onEnter y onLeave, modificando el valor de la función para la que devuelve (0), es decir,
isJailbroken a “false”.
onLeave: function (log, retval, state) {
console.log("Function [JailbreakDetectionVC isJailbroken] originally returned:"+ retval);
retval.replace(0); //Se modifica el valor de la función
console.log("Changing the return value to:"+retval);
Se ejecuta de nuevo el comando inicial, con el resultado de la función isJailbroken modificado en

tiempo de ejecución.
Instrumenting functions... `... -[JailbreakDetectionVC isJailbroken]: Loaded handler at

"./__handlers__/__JailbreakDetectionVC_isJailbroken_.js" Started tracing 1 function. Press
Ctrl+C to stop.
Function [JailbreakDetectionVC isJailbroken] originally returned:0x1 Changing the return

value to:0x0
/* TID 0x303 */
6890 ms -[JailbreakDetectionVC isJailbroken]
Function [JailbreakDetectionVC isJailbroken] originally returned:0x1
Changing the return value to:0x0
22475 ms -[JailbreakDetectionVC isJailbroken]
5.5. Aplicaciones vulnerables
56/61
Estas aplicaciones pueden servir al alumno como práctica y entrenamiento de esta unidad:
Damn Vulnerable iOS Application (DVIA)
Damn Vulnerable iOS Application (DVIA) (http://damnvulnerableiosapp.com/) es una aplicación

vulnerable para evaluar las habilidades de Pentesting en aplicaciones móviles.
Su principal objetivo es proporcionar una plataforma legal a entusiastas y profesionales de seguridad

para poner a prueba su destreza.
Damn Vulnerable Hybrid Mobile App (DVHMA)
Damn Vulnerable Hybrid Mobile App (DVHMA) (https://github.com/logicalhacking/DVHMA) es

una aplicación móvil híbrida para Android que contiene vulnerabilidades de forma intencionada. Su
propósito es permitir a los profesionales de seguridad probar sus herramientas y técnicas legalmente,
ayudar a los desarrolladores a comprender mejor los fallos más comunes en el desarrollo de
aplicaciones móviles híbridas de forma segura.
Esta aplicación está desarrollada para estudiar las "trampas" en el desarrollo de aplicaciones híbridas,
por ejemplo, utilizando Apache Cordova o SAP Kapsel de forma segura. Actualmente, el enfoque
principal es desarrollar una comprensión más profunda de las vulnerabilidades de inyección que
explotan el nexo de unión entre JavaScript y Java.
VI. Resumen
De manera similar en la que hemos estudiado la auditoría de aplicaciones web, en esta unidad nos hemos
centrado en la auditoría de aplicaciones móviles.
Para establecer una metodología efectiva, hemos aprendido que podemos basarnos en la guía de
OWASP Mobile Security Testing Guide , ya que clasifica los riesgos de seguridad en aplicaciones móviles
y proporciona controles para reducir su impacto o probabilidad de explotación.
Para este tipo de auditoría, hemos estudiado aplicaciones móviles de diferentes sistemas operativos
como Android, iOS y, dentro de cada sistema operativo, los tipos de análisis existentes (estático o
dinámico), aplicaciones vulnerables para poder realizar pruebas.
En conclusión, para poder llevar a cabo una auditoría de seguridad completa, es importante conocer de
forma detallada los tipos de aplicaciones con las que vamos a trabajar, así como sus características
específicas que las diferencian de las aplicaciones web, por ejemplo.
57/61
Recursos
Enlaces de Interés
[1] Mobile Security Testing Guide
https://github.com/OWASP/owasp-mstg
[2] OWASP Mobile Security Project – Top 10 Mobile Risks

https://www.owasp.org/index.php/OWASP_Mobile_Security_Project
[3] Mobile Application Security Verification Standard

https://www.owasp.org/images/6/61/MASVS_v0.9.4.pdf
[4] iOS/macOS penetration testing cheatsheet

https://github.com/ansjdnakjdnajkd/iOS
Bibliografía
Hacking Android. 1st ed. Birmingham: Packt Publishing Ldt. : Kotipalli, S. and A. Imran,
M. (2016). Hacking Android . 1st ed. Birmingham: Packt Publishing Ldt.
Hacking de dispositivos iOS: iPhone & iPad. : Alonso Cebrián, J. (2016). Hacking de
dispositivos iOS: iPhone & iPad. OxWORD Computing.
ADB. : https://developer.android.com/studio/releases/platform-tools#download
AddSecurityExceptionAndroid. : https://github.com/levyitay/AddSecurityExceptionAndroid
APKTool. : https://ibotpeaches.github.io/Apktool/install/
App Review. : https://developer.apple.com/app-store/review/
Brida. : https://github.com/federicodotta/Brida
Certificados de Apple. : https://developer.apple.com/support/certificates/
Clutch. : https://github.com/KJCracks/Clutch
Cydia Impactor. : http://www.cydiaimpactor.com
Dex2jar. : https://sourceforge.net/projects/dex2jar/files/latest/download
Diva Android. : https://github.com/payatu/diva-android
Dumpdecrypted. : https://github.com/stefanesser/dumpdecrypted
DVHA. : https://github.com/logicalhacking/DVHMA
Enterprise Mobile Device Management (MDM). :
https://developer.apple.com/programs/enterprise/
58/61
Frida. :
https://www.frida.re/
https://github.com/frida/frida/releases
GoatDroid. : https://github.com/jackMannino/OWASP-GoatDroid-Project/tree/android
Guía de Brida. : https://techblog.mediaservice.net/2018/04/brida-a-step-by-step-user-guide/
InsecureBanking2. : https://github.com/dineshshetty/Android-InsecureBankv2
Instalación de Xposed. : https://techviral.net/install-xposed-framework-in-android/
iOS/macOS penetration testing cheat sheet. : https://github.com/ansjdnakjdnajkd/iOS
iPhone Backup Extractor. : https://www.iphonebackupextractor.com/
Java Decompiler. : http://jd.benow.ca/
jd-cmd. : https://github.com/kwart/jd-cmd
Keychain Accessibility Values. :
https://developer.apple.com/documentation/security/keychain_services/keychain_items/item_attribute_keys_an
Keychain-Dumper. : https://github.com/ptoomey3/Keychain-Dumper
Lista de herramientas de análisis Android. : https://www.xda-developers.com/root/
Mobile Security. : https://mobilesecuritywiki.com/
Mobile-Security-Framework-MobSF. : https://github.com/MobSF/Mobile-Security-
Framework-MobSF
Needle. : https://github.com/mwrlabs/needle
OWASP Mobile App Security Checklist. : https://github.com/OWASP/owasp-
mstg/blob/master/Checklists/Mobile_App_Security_Checklist.xlsx
OWASP Mobile Application Security Verification Standard. :
https://www.owasp.org/images/6/61/MASVS_v0.9.4.pdf
OWASP Mobile Security Project – Top 10 Mobile Risks. :
https://www.owasp.org/index.php/OWASP_Mobile_Security_Project
OWASP Mobile Security Testing Guide. : https://github.com/OWASP/owasp-mstg
https://github.com/OWASP/owasp-
mstg/blob/master/Checklists/Mobile_App_Security_Checklist.xlsx
OWASP owasp-mstg. : https://github.com/OWASP/owasp-
mstg/blob/master/Document/0x06b-Basic-Security-Testing.md
passionfruit. : https://github.com/chaitin/passionfruit
Project: Universal Android SSL Pinning Bypass with Frida. :
https://codeshare.frida.re/@pcipolloni/universal-android-ssl-pinning-bypass-with-frida/
radare2. : https://github.com/radare/radare2
SQLite Browser. : http://sqlitebrowser.org/
ssl-kill-switch2. : https://github.com/nabla-c0d3/ssl-kill-switch2
SUPER Android Analyzer. : http://superanalyzer.rocks/download.html
59/61
Tutorial Clutch. : https://github.com/KJCracks/Clutch/wiki/Tutorial

Xposed framework for Android. : https://www.xda-developers.com/xposed-framework-for-
android-oreo-beta/
Glosario.
Análisis dinámico: Estudiar el comportamiento que presenta la aplicación cuando se

encuentra en ejecución. Durante esta fase se analizarán las comunicaciones cliente-servidor, el
acceso a escritura de ficheros, la interacción con diferentes componentes, etc. Para ello, se hará
uso de la información detectada en la fase de obtención de información y, especialmente, del
análisis estático.
Análisis estático: Analizar el comportamiento de la aplicación sin que ésta se encuentre en

ejecución, observando, a partir de la información y código fuente, cómo se comportaría la
aplicación y qué partes de código son susceptibles de ser vulnerables en función de los datos de
entrada o variaciones que sufren en tiempo de ejecución.
Android: Sistema operativo basado en el núcleo de Linux diseñado originalmente para

dispositivos móviles, como smartphones y tablets, y que posteriormente expandió su desarrollo
para soportar otros dispositivos como netbooks, televisores, lectores de e-books, PCs, etc.
AndroidManifest.xml: Fichero XML de configuración donde se especifica toda la

información que el dispositivo precisa para poder determinar las acciones que llevará a cabo la
aplicación en base a los permisos (etiquetas XML definidas que indican las acciones permitidas
por parte de la aplicación), requisitos de software o hardware que se utilizarán durante la
aplicación, la versión del sistema operativo y los diferentes componentes que se ejecutarán en
función de las notificaciones o eventos que se produzcan en el sistema.
APK (Android Application Package): Archivo comprimido, muy similar al formato JAR de
Java o ZIP, que contiene una estructura de ficheros que se descomprimirá y replicará en el
dispositivo móvil una vez el usuario haya decidido instalar la aplicación en cuestión.
Código SMALI: Lenguaje de ensamblador utilizado en DEX basado en JASMIN, el código

de ensamblador para la máquina virtual de Java (JVM).
Frameworks de análisis de archivos IPA: Herramientas que permiten obtener información

de los archivos de configuración, las clases de las que hace uso el binario, librerías, strings, etc.
e identifican posibles vulnerabilidades y/o errores de configuración.
IOS: Sistema operativo utilizado en los dispositivos móviles de Apple, incluyendo el iPhone,
iPad y iPod Touch. iOS está basado en Darwin, cuyo kernel híbrido combina componentes de
FreeBSD y Mach.
60/61
61/61

05 Auditoria de Aplicaciones Moviles

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

05 Auditoria de Aplicaciones Moviles

Cargado por

Copyright:

Formatos disponibles

Auditoría de aplicaciones móviles

© Ediciones Roble, S.L.

Auditoría de aplicaciones móviles

I. Introducción a la auditoría de aplicaciones móviles

Con la continua evolución tecnológica, el entorno empresarial ha integrado las aplicaciones

3.1. Riesgos de seguridad en aplicaciones móviles

El objetivo de esta metodología es clasificar los riesgos de seguridad en aplicaciones móviles y

Imagen 5.1. OWASP Top 10 Riesgos Móviles.

M2 – Almacenamiento inseguro de datos

El vector de explotación consiste en monitorizar la red para detectar comunicaciones inseguras

Se identifican vulnerabilidades en el proceso de autenticación, para engañar o evitar la autenticación

Se identifican vulnerabilidades en el proceso de autorización, para autenticarse en el aplicativo como

M7 – Mala calidad del código

Se explotan las vulnerabilidades mediante el envío de parámetros no controlados por la aplicación y

M8 – Manipulación del código

M10 – Funcionalidad extraña

3.2. Pruebas seguridad en aplicaciones móviles

Revisión de la aplicación móvil implementada en el dispositivo móvil del usuario final.

Imagen 5.2. OWASP Mobile Security Testing Guide (MSTG).

3.2.1. Pruebas de arquitectura, diseño y modelo de amenazas

Verificar si los componentes de la aplicación han sido identificados y son necesarios.

3.2.2. Pruebas de almacenamiento de datos y privacidad

El almacenamiento de datos sensibles, como credenciales o información privada, es un aspecto clave en

Verificar si las capacidades para el almacenamiento de credenciales que provee el sistema se

3.2.3. Pruebas de criptografía

La criptografía es un ingrediente esencial en materia de protección del almacenamiento de datos en el

3.2.4. Pruebas de autenticación y gestión de la sesión

3.2.5. Pruebas de comunicaciones

El propósito de los controles definidos en esta sección es asegurar la confidencialidad y la integridad de

3.2.6. Pruebas de interacción con la plataforma

Verificar que la aplicación solo requiere un mínimo número de permisos necesarios.

3.2.7. Pruebas de calidad de código

Verificar que la aplicación ha sido firmada y provisionada con un certificado válido.

3.2.8. Pruebas de resiliencia

Verificar que la aplicación implementa funcionalidades para detectar si el dispositivo ha sido

Verificar que la aplicación detecta el uso de herramientas de ingeniería inversa, o herramientas de

IV. Aplicaciones móviles Android

4.1. Tipos de análisis

Análisis estático de la aplicación

Análisis dinámico de la aplicación

El análisis de vulnerabilidades dinámico se caracteriza por estudiar el comportamiento que presenta la

4.2. Análisis estático de la aplicación

4.2.1. Obtención del APK

Si la aplicación se encuentra instalada en el dispositivo móvil, es posible obtener el fichero APK

Imagen 5.3. Obtención de archivo APK mediante APKExtractor.

Se trata de una herramienta multiplataforma que permite la comunicación remota de un emulador o

Imagen 5.4. Activación de las opciones de desarrollo.

Imagen 5.5. Comandos adb para conectarse al dispositivo móvil.

Mediante ADB es posible realizar la instalación y depuración de aplicaciones en tiempo de ejecución.

Imagen 5.6. Proceso de instalación de apk mediante adb.

Fuente: captura de Kali Linux.

Imagen 5.7. Listado de contenido del directorio de la apk.

Mediante el siguiente comando se obtendrá la APK del dispositivo en el directorio indicado:

ADB se puede descargar desde el siguiente enlace:

Finalmente es posible descargar las aplicaciones desde páginas de terceros proporcionando

Imagen 5.9. Obtención de APK a través de APK Downloader.

Esta opción resulta útil si no se desea instalar la aplicación en el dispositivo.

4.2.2. Decompilación del APK

Uso de la herramienta Apktool. Se trata de una herramienta multiplataforma desarrollada en Java

java –jar apktool_2.3.2.jar d <nombre_apk>

Imagen 5.10. Decompilación de archivo APK mediante Apktool.

java –jar apktool_2.3.2.jar b <directorio_código> <nombre_apk>

4.2.3. Obtención del código fuente