Tema 7

Hacking Ético

Hacking en sistemas y
aplicaciones móviles
 Índice
Esquema 3

Ideas clave 4
7.1. Introducción y objetivos 4
7.2. Principios de seguridad en sistemas Android e
iOS 4
7.3. Vulnerabilidades en sistemas Android e iOS 9
7.4. Análisis estático en aplicaciones móviles 12
© Universidad Internacional de La Rioja (UNIR)

7.5. Análisis dinámico en aplicaciones móviles 16

7.6. Herramientas de análisis. MobSF 19
7.7. Lecciones magistrales 22
7.8. Referencias bibliográficas 22

A fondo 23

Test 24
 © Universidad Internacional de La Rioja (UNIR)

Tema 7. Esquema
Esquema

Hacking Ético
3
 Ideas clave

7.1. Introducción y objetivos

Una vez hemos estudiado cómo tener acceso dentro de una infraestructura interna
a través de dispositivos perimetrales, es momento de conocer cómo encontrar y
explotar vulnerabilidades en otro tipo de sistemas, como es el caso de los dispositivos
móviles. En este tema, el estudiante aprenderá cómo encontrar vulnerabilidades en
dispositivos móviles Android e iOS y cómo llevar a cabo una auditoría técnica en
aplicaciones móviles.

Objetivos:

 Introducir al alumno en los sistemas Android e iOS.

 Conocer los principios de seguridad de sistemas móviles.
 Análisis y detección de vulnerabilidades en sistemas móviles.
 Conocer los fundamentos básicos de los análisis estáticos y dinámicos en
aplicaciones móviles.
 Conocer las diferentes herramientas para auditar aplicaciones móviles.

7.2. Principios de seguridad en sistemas Android e

iOS
© Universidad Internacional de La Rioja (UNIR)

Como veremos a continuación, los entornos móviles no tienen la misma versatilidad

que los equipos personales o los servidores. Estos sistemas están diseñados
generalmente para realizar funciones muy acotadas, lo que reduce
considerablemente la superficie de ataque.

Hacking Ético
4
Tema 7. Ideas clave
 Al margen de que pueden tener vulnerabilidades explotables a nivel de plataforma
(en última instancia son ordenadores y pueden existir vulnerabilidades más cercanas
al exploiting), la principal fuente de vulnerabilidades en los dispositivos móviles son
sus aplicaciones: un fallo de diseño en una aplicación puede permitir acceder a todas
las funcionalidades que el usuario le haya otorgado de una forma difícil de detectar.

Además, la evolución de las tecnologías de desarrollo y la necesidad de cubrir

múltiples plataformas móviles que no comparten tecnologías (mayoritariamente
Android y iOS, programados principalmente en Java y Objective-C, respectivamente)
ponen en auge la aparición de frameworks de desarrollo basado en tecnologías web.

En consecuencia, las vulnerabilidades explotables en estas plataformas serán,

además de las propias de la plataforma, las relacionadas con ingeniería social o los
fallos de diseño; las propias de las tecnologías web. Así, diferenciaremos entre tres
tipos de aplicaciones:

 Aplicaciones nativas: aplicaciones programadas para una tecnología móvil

concreta, utilizando sus API, pero que tiene un diseño diferente en cada
plataforma (no es portable).

 Web-based: aplicaciones web orientadas a ser cargadas en el dispositivo móvil a

través de un visor, de tal forma que pueden operar en cualquier plataforma sin
realizar ninguna modificación.

 Híbridas: aplicaciones web desarrolladas utilizando frameworks de portabilidad,

como Cordova o Ionic, de tal forma que puedan operar en múltiples plataformas,
pero también integrarse con sus API.
© Universidad Internacional de La Rioja (UNIR)

Hacking Ético
5
Tema 7. Ideas clave
 Android

El sistema operativo Android consiste en la instalación de una capa de abstracción a

nivel de usuario sobre un kernel de Linux con el módulo SELinux activado. Para ello,
se desarrolla un ecosistema propio de aplicaciones (las que podemos ver como
usuarios en cualquier móvil Android) que trabajan dentro de un entorno virtual,
comunicándose exclusivamente con las API ofrecidas por Android, en lugar de
hacerlo con el sistema operativo.

Estas aplicaciones están programadas en Java y, en función de la versión de Android,

este entorno de ejecución será:

 Máquina virtual Dalvik: un sustituto de la clásica máquina virtual de Java para

sistemas Android, que hace de intérprete entre el bytecode y el código máquina
propio del dispositivo.

 Android Runtime: sustituto moderno a la máquina Dalvik, orientado a mejorar el

rendimiento de las aplicaciones mediante el precompilado (en lugar de la
compilación en tiempo de ejecución).

Además, Android cuenta con un entorno de desarrollo nativo en C++ con el que
pueden construirse módulos y librerías para las aplicaciones, de cara a realizar
procesos a bajo nivel que no serían viables en Java en términos de tiempo, o
consumo.

Cada aplicación se instala con un usuario propio dentro del sistema y se ejecuta
dentro de una sandbox, para utilizar solo las funciones de la API que el usuario
© Universidad Internacional de La Rioja (UNIR)

permita (permisos a la cámara, al sistema de archivos, a la agenda de contactos, etc.).

A la hora de establecer comunicaciones entre las distintas aplicaciones, lo harán a

través del componente IPC ubicado en el kernel (Figura 1).

Hacking Ético
6
Tema 7. Ideas clave
 Figura 1. Arquitectura de Android. Fuente: Tally Ho, s. f.

De esta forma, la superficie de ataque queda restringida a:

 Fallos en la lógica de las aplicaciones que dejen expuestos activos de la propia

aplicación o del sistema a través de sus permisos.
 Fallos en la intercomunicación con otros procesos o con sistemas externos.
 Ingeniería social.
 Exploits que puedan saltar al sistema operativo.

iOS

Por su parte, iOS está construido, al igual que su homólogo para ordenadores macOS,
sobre un kernel derivado de FreeBSD. Sin embargo, al igual que Android, despliega
un entorno de usuario basado en la utilización de aplicaciones aisladas del resto del
sistema operativo.
© Universidad Internacional de La Rioja (UNIR)

Desde el punto de vista de las aplicaciones, iOS se organiza de una forma similar a
Android: las aplicaciones se ejecutan dentro de una sandbox que, en este caso,
además de aislarlas, ejerce como sistema de control de accesos a los recursos.

Hacking Ético
7
Tema 7. Ideas clave
 Estas aplicaciones, sin embargo, sí que se ejecutarán de forma nativa. Las
aplicaciones para iOS están desarrolladas en los lenguajes Objective-C y Swift y,
gracias a que Apple controla toda la pila de ejecución (la compañía decide tanto el
software como el hardware), no requiere de un intérprete que permita portar las
aplicaciones entre diferentes arquitecturas. Estas aplicaciones también contarán
con un sistema de permisos que determinará qué funciones de las API, y
componentes de la arquitectura (Figura 2) pueden utilizar.

Figura 2. Arquitectura de iOS. Fuente: DotNetTricks, 2018.

El control sobre el hardware y que las aplicaciones se distribuyan y ejecuten

compiladas para trabajar en nativo se traducen en dos nuevos aspectos para tener
en cuenta cuando trabajemos con sistemas iOS: las aplicaciones nativas no pueden
© Universidad Internacional de La Rioja (UNIR)

decompilarse como las aplicaciones Java, y su análisis es más difícil.

Hacking Ético
8
Tema 7. Ideas clave
 Procedimiento de análisis

La guía de análisis de vulnerabilidades móviles de OWASP define un procedimiento

para efectuar tests de penetración en entornos móviles a través de tres prácticas:

 Análisis de vulnerabilidades.
 Análisis estático.
 Análisis dinámico.

7.3. Vulnerabilidades en sistemas Android e iOS

Mientras que la tecnología de cada una de las plataformas puede variar, existen
ciertos elementos clave que debemos tener en cuenta a la hora de realizar nuestro
análisis de vulnerabilidades y están presentes en todos los entornos.

Almacenamiento

Cualquier elemento persistente entre sesiones u offline (tokens de autenticación,

información del usuario, etc.) debe estar almacenado en un dispositivo de
almacenamiento y, por lo tanto, es susceptible de ser exfiltrado.
El análisis de este aspecto parte del análisis de cómo gestionan las aplicaciones sus
activos persistentes:

 A través de API seguras.

 A través de API no centradas en la seguridad del almacenamiento.
© Universidad Internacional de La Rioja (UNIR)

 A través de llamadas al sistema operativo.

Hacking Ético
9
Tema 7. Ideas clave
 También requiere la evaluación de las restricciones que tiene el sistema operativo
con respecto al uso de disco. Por ejemplo, el directorio/system de Android no debería
ser accesible desde una terminal. También es posible que la propia aplicación escriba
en un path que no esté protegido.

Por último, cabe la posibilidad de que si el dispositivo de almacenamiento no ha sido

protegido (no está cifrado), podamos acceder a él sin necesidad de pasar por el
control de acceso del sistema operativo.

Comunicación con sistemas finales

Uno de los elementos más característicos de los dispositivos móviles son las
capacidades de conexión por radio. En este sentido, debemos tener en cuenta que
todas estas tecnologías de conexión suponen también una superficie de ataque:

 Wifi: a través de la creación de rogue AP, ataques Mitm o directamente

accediendo a servicios del dispositivo desde otro equipo en el mismo segmento
de red. Por ejemplo, esta es una puerta de entrada bastante común en los
sistemas móviles integrados en los vehículos.

 Bluetooth: tanto la tecnología clásica como la nueva implementación bluetooth

LE suelen presentar carencias, especialmente en las implementaciones. Así, por
ejemplo, puede ser relativamente fácil suplantar un dispositivo manos libres con
acceso a los contactos.

 Ataque a protocolos: se debe evaluar si la protección de las aplicaciones en las

capas de aplicación es correcta. Por ejemplo, si se implementa correctamente TLS
© Universidad Internacional de La Rioja (UNIR)

(última versión, HSTS, HPKP, etc.) o si se está utilizando algún otro protocolo
(protocolos propios desarrollados con protobuf, los protocolos Signal y Noise
utilizados en WhatsApp, etc.).

Hacking Ético
10
Tema 7. Ideas clave
  Ataques a sistemas de autenticación y autorización: por último, se deben auditar
los procedimientos de control de acceso contra los sistemas finales. Dos de las
tecnologías más utilizadas, en parte debido a la íntima relación entre aplicaciones
móviles y aplicaciones web, son OAuth2 y JWT. En ocasiones no se almacenan
correctamente (de forma segura) los tokens de OAuth2 o incluso se llegan a
exponer tokens de desarrollo. Por otro lado, buscando mejorar la eficiencia de los
sistemas, o simplemente por desconocimiento, la configuración de JWT no
siempre es la más segura, lo que puede dejar expuestos los sistemas finales
(OWASP, s. f.).

Interacción entre procesos

La comunicación entre distintos procesos del sistema suele ser una fuente de
vulnerabilidades. Revisar los puntos de entrada de la aplicación desde una
perspectiva de modelado de amenazas permite encontrar puntos de fuga.

Una antigua vulnerabilidad de Android permitía obtener la ubicación sin

concederle dicho permiso, si la aplicación tenía permisos de acceso al sistema
de archivos y acceso a la cámara de Google. Como la cámara automáticamente
guardaba la ubicación de dónde se había capturado la fotografía, simplemente
leyendo el fichero, la aplicación podía ubicar al usuario.

También ha habido vulnerabilidades similares en iOS 15 que permitían realizar

tareas saltándose el bloqueo de pantalla.

Fallos en la lógica de la aplicación

Aunque algunos de los fallos comentados anteriormente encajarían también en esta

© Universidad Internacional de La Rioja (UNIR)

categoría, dentro de la propia aplicación podremos encontrar fallos relacionados

con una mala implementación: el mal uso de los framework de desarrollo o incluso
el uso de la criptografía (algoritmos, gestión de claves, etc.).

Hacking Ético
11
Tema 7. Ideas clave
 En el caso de las aplicaciones basadas en web o híbridas, encontraremos fallos
relacionados exclusivamente con las tecnologías web, especialmente
vulnerabilidades de inyección de contenido. Al aumentar la complejidad de la
aplicación (mezclar lenguajes como javascript con la lógica de acceso a las API del
sistema, con la interacción con servidores, etc.), aumenta la superficie de ataque.

Para terminar, una implementación de la lógica de llamadas a las distintas interfaces

de la aplicación puede convertirla en susceptible para ser parte de un ataque de
ingeniería social, permitiendo aprovechar, por ejemplo, su acceso al sistema de
notificaciones, o imitando su forma de operar con las alertas y mensajes en pantalla.

7.4. Análisis estático en aplicaciones móviles

El análisis estático consiste en la obtención y análisis de aplicaciones sin llegar a

ejecutarlas. Mediante el estudio de elementos clave de sus archivos de
configuración, o de su código fuente, podremos encontrar vulnerabilidades que
dejen expuesto el sistema.

Android

Las aplicaciones de Android tienen generalmente la extensión .apk y podemos

obtenerlas:

 Instalándolas a través del market oficial (Google Play) y extrayéndolas del

dispositivo con adb (Figura 3)
© Universidad Internacional de La Rioja (UNIR)

 Descargándolas de markets alternativos, como Apkpure.

Hacking Ético
12
Tema 7. Ideas clave
 Figura 3. Código: extracción de apk utilizando adb. Fuente: elaboración propia.

A efectos prácticos son un fichero ZIP, por lo que podemos hacer un primer análisis
simplemente descomprimiendo su contenido. La estructura canónica de un apk
descomprimido contiene principalmente los siguientes ficheros y directorios:

 AndroidManifest.xml. Fichero principal de configuración de la aplicación.

 META-INF. Meta información del fichero, como firmas y certificados.
 assets. Imágenes, iconos y archivos multimedia que utilizará la aplicación.
 res. Ficheros y librerías de código nativo (C++).
 classes.dex. Código ejecutable en formato dex (una transformación del código java
para ejecutarse en la máquina virtual de Android).

Cuando descomprimamos la aplicación, obtendremos una versión binaria de dichos

ficheros, que no nos permitirá hacer un buen análisis. Para poder comprender mejor
su contenido, recurriremos a herramientas como apktool (que permite obtener estos
ficheros en claro e, incluso, recompilar la aplicación modificada) o, idealmente, el
framework de trabajo conocido como jadx.
© Universidad Internacional de La Rioja (UNIR)

Con la herramienta jadx podemos abrir directamente el fichero apk y acceder a todo
su contenido (código fuente incluido). A la hora de realizar el análisis estático,
debemos centrarnos, principalmente, en los siguientes elementos:

Hacking Ético
13
Tema 7. Ideas clave
  Análisis del manifiesto. El fichero AndroidManifest.xml contiene la especificación
de actividades que ejecutará la aplicación. Además, define los permisos que debe
tener para ejecutarse (qué API puede utilizar). La Figura 4 muestra el manifiesto
de una aplicación que requiere acceso a la cámara y permisos de accesibilidad.

Figura 4. Código: ejemplo de AndroidManifest.xml. Fuente: elaboración propia.

 Uso de certificados. Las aplicaciones de Android deben ir firmadas, pero no hay

ningún requisito con respecto a la generación de sus certificados (no se requiere
© Universidad Internacional de La Rioja (UNIR)

una CA válida como en los navegadores web). Por lo tanto, en ocasiones, se puede
detectar una copia fraudulenta de una aplicación porque su certificado no es el
de la aplicación legítima.

Hacking Ético
14
Tema 7. Ideas clave
  Assets. Algunas muestras de malware contienen, junto con los iconos e imágenes,
ficheros que pueden llegar a ejecutarse (normalmente ofuscados o cifrados).

 Análisis del código fuente. El código Java de las aplicaciones Android puede leerse
sin problemas utilizando herramientas como jadx (o decompilándolo con dex2jar,
y utilizando herramientas más clásicas, como jd-gui). El código desarrollado para
la API nativa (el código C++) también podrá analizarse utilizando herramientas de
reversing, como IDA o Ghidra, pero normalment estará preparado para
plataformas tipo ARM.

iOS

El análisis estático en iOS es ligeramente más complicado. La obtención de las

aplicaciones .ipa en un formato analizable ya supone un reto frente al mismo
proceso en Android.

Si intentásemos extraer el .ipa del teléfono (extraer del almacenamiento, de alguna

forma, el fichero descargado desde la App Store) obtendríamos un archivo cifrado.
En esta plataforma, cuando se instala una aplicación, esta se cifra en la nube con una
clave de tal forma que solo podrá descifrarse en nuestro dispositivo. La única forma
de obtenerlo será ejecutándolo y extrayéndolo de memoria con herramientas de
instrumentación de binarios, como bfinject, Frida, etc.

Una vez en posesión del fichero .ipa, observaremos que también es un zip con una
estructura definida para la plataforma. Al abrirlo, nos encontraremos con los
siguientes elementos clave:
© Universidad Internacional de La Rioja (UNIR)

 Directorio Payload/<NOMBRE_APP>.app/
• <NOMBRE_APP> Binario con el contenido ejecutable
• Info.plist Propiedades como iconos, strings utilizados por la aplicación, etc.
• **.nib Ficheros de interfaz

Hacking Ético
15
Tema 7. Ideas clave
 Para realizar el análisis estático de estas aplicaciones, deberemos comenzar
analizando el fichero Info.plist con herramientas como plistutil o la librería plistlib de
Python. Este fichero, que hará las veces del manifest de Android, nos permitirá saber
la metainformación de la aplicación (nombre, versión, etc.), pero nos interesará
especialmente porque identificará los permisos que necesita.

A la hora de analizar la lógica de la aplicación, nos encontraremos con un escollo más:

no podemos decompilar el código porque está programado en un lenguaje nativo
(ObjectiveC, o Swift). Tendremos que interpretarlos con software de ingeniería
inversa, como IDA o Ghidra, identificando correctamente que el binario con el que
trabajamos está preparado para trabajar en arquitecturas ARM (mientras que en
nuestros ordenadores normalmente trabajamos con x86/x64). También, para el caso
concreto de aplicaciones para macOS e iOS, se utiliza a menudo el software Hopper.

7.5. Análisis dinámico en aplicaciones móviles

En ocasiones, las aplicaciones (especialmente las aplicaciones maliciosas) utilizan

técnicas de ofuscación para complicar su análisis y así ocultar funcionalidades
críticas. La Figura 5 muestra un ejemplo de funcionalidades solo detectables a través
del análisis dinámico.
© Universidad Internacional de La Rioja (UNIR)

Hacking Ético
16
Tema 7. Ideas clave
 Figura 5. Análisis estático vs. Dinámico. Fuente: elaboración propia.

Algunas veces contendrán toda la lógica ofuscada, pero, en otras, recurrirá incluso a
recursos externos o a la interacción con librerías del dispositivo, que no podremos
conocer más que ejecutando la aplicación.

Para ello, debemos construir un entorno virtual:

 Máquina virtual.
 Emulador (Android Studio / Xcode). Ambos entornos de desarrollo oficiales de
Android y iOS (respectivamente) permiten desarrollar, construir y testear
aplicaciones. Mientras que Android es mucho más versátil, Xcode es una de las
pocas formas de trabajar con desarrollos iOS e interactuar con dispositivos reales.
 Dispositivo con root / jalbreak.

Herramientas de análisis
© Universidad Internacional de La Rioja (UNIR)

A continuación, enumeraremos algunas herramientas utilizadas comúnmente para

analizar aplicaciones móviles:

Hacking Ético
17
Tema 7. Ideas clave
  Adb. Es una interfaz CLI de comunicación con dispositivos móviles (o emuladores
de dispositivos móviles) de Android.

 JADX. Nos permite obtener el código fuente de una aplicación Android sin tener
que realizar procesos tediosos de decompilado dentro de un entorno destinado a
la ingeniería inversa con herramientas de búsqueda, de relación entre archivos
interdependientes, etc.

 Frida. Es un framework de instrumentación de binarios (tanto de Android como

de iOS) a través de la inyección en sus procesos. Cuando queremos analizar el
comportamiento de un programa con Frida, inyectamos su agente y, mediante
javascript, podemos extraer información del proceso generado por el programa
e, incluso, manipular su funcionamiento.

 ZAP / Burp. Tanto ZAP como Burp son dos herramientas que pueden actuar de
proxy para analizar, manipular y repetir peticiones HTTP. Podemos utilizar
cualquiera de las dos para hacer ingeniería inversa de las peticiones que hacen
las aplicaciones, una vez sorteados los controles criptográficos de la conexión.

 Bfinject. Cuando se descarga una aplicación en iOS, esta tiene un cifrado especial
destinado a nuestro dispositivo. Con Bfinject podemos, mediante la inyección de
una librería en una aplicación de iOS (de forma similar a como opera Frida),
obtener el binario de la aplicación desde memoria (donde lo ha descifrado el
propio sistema operativo para poder ejecutarlo).

 Cydia. Sistema que permite instalar aplicaciones desde fuera del AppStore de
iOS. Por defecto, si una aplicación no se descarga de la AppStore, no se pueden
© Universidad Internacional de La Rioja (UNIR)

instalar en el dispositivo. Cydia actúa como un middleware para sortear este

control.

 SSL Kill Switch v2. Para lidiar sencillamente con SSL y HPKP en iOS. Actualmente
se puede hacer con Frida, y un proxy normal (Burp, ZAP, MiTM Proxy, etc.).

Hacking Ético
18
Tema 7. Ideas clave
 7.6. Herramientas de análisis. MobSF

Mobile Security Framework (MobSF) es un sistema open source destinado a facilitar

las labores de análisis de aplicaciones móviles. Para ello, cuenta con varios sistemas
que permiten tanto la exploración manual de aplicaciones móviles (el análisis estático
y dinámico, de aplicaciones Android e iOS), como su uso a través de API REST para la
integración continua en el ciclo de desarrollo de una organización.

Aunque las funcionalidades que provee MobSF pueden ser cubiertas utilizando
muchas otras herramientas, el hecho de que estas funcionalidades estén integradas
dentro de un marco de trabajo facilita enormemente la gestión de evidencias
forenses (muestras maliciosas), así como la obtención de elementos clave.

Instalación

Para la instalación lo ideal es seguir la documentación oficial, disponible en su

repositorio de GitHub para diferentes plataformas. El proceso está bien
automatizado (el propio repositorio tiene scripts de instalación en un entorno virtual
de python) e, incluso, existen imágenes de docker que podemos utilizar. Pero, según
el uso que queramos darle (si queremos o no utilizarlo para hacer análisis dinámicos)
y el entorno concreto en el que estemos trabajando, tendremos que atender a
ciertas particularidades en la instalación.

Sin perder de vista los documentos oficiales, que pueden cambiar a medida que
evolucionen las versiones, para poder hacer análisis dinámico necesitaremos:
© Universidad Internacional de La Rioja (UNIR)

 Instalar MobSF de forma nativa (no nos vale una imagen de docker).
 Un hipervisor que emule sistemas Android, como Genymotion, dispositivos
virtuales de Android Studio, etc.

Hacking Ético
19
Tema 7. Ideas clave
 Además, para que MobSF pueda cargar todos los elementos de instrumentación, será
necesario poder iniciar shell como root en el dispositivo.

Análisis estático

Cuando carguemos la aplicación, MobSF generará un informe exhaustivo de los

principales elementos que nos permiten interpretar su objetivo. Así, categorizará
los resultados en las siguientes secciones:

 Información genérica (icono, hashes, y otros elementos que permiten caracterizar

el fichero introducido).
 Información sobre permisos por la aplicación.
 Información del certificado con el que ha sido firmada.
 Análisis de seguridad y del malware, utilizando fuentes externas.

Además, nos permitirá acceder al código fuente de la aplicación desde la interfaz

web.

Análisis dinámico

Hay información que no podremos conocer si no recurrimos a la ejecución de las

aplicaciones. La Figura 5 ilustraba un ejemplo de cómo un troyano bancario solo
muestra la comunicación con su C2 al ejecutarlo.

Para poder utilizar el análisis dinámico de MobSF, es imprescindible ejecutarlo desde

un sistema nativo (en lugar de virtualizado o dockerizado). Una vez cargada la
© Universidad Internacional de La Rioja (UNIR)

aplicación en MobSF e iniciado el análisis dinámico (Figura 6), se monitorizará la

ejecución mediante la inyección de un script de Frida que permite instrumentalizar:

Hacking Ético
20
Tema 7. Ideas clave
  Uso de la API del sistema móvil.
 Bypass de SSL pinning.
 Captura de Strings utilizadas por la aplicación.
 Uso de determinadas clases nativas de Java (File, Sockets, etc.) que evidencian la
lógica de la aplicación.

Figura 6. Análisis dinámico en MobSF. Fuente: elaboración propia.

Además, incluye un proxy que permite, mediante la instalación de una CA falsa,

analizar todas las operaciones de red (incluso si están cifradas con TLS). De esta
forma, podremos acceder al contenido de las comunicaciones y probar nuevas vías
de ataque contra el cliente (introduciendo fallos en las respuestas a sus peticiones)
como contra el servidor (modificando las peticiones legítimas para evaluar el control
de acceso, la resistencia frente a fallos, etc.).
© Universidad Internacional de La Rioja (UNIR)

Hacking Ético
21
Tema 7. Ideas clave
 7.7. Lecciones magistrales

En estos vídeos, titulados Análisis estático con MobSF y Análisis dinámico con MobSF,
se presentan soluciones para realizar un análisis estático y dinámico de manera
automatizada con la herramienta pública MobSF. Gracias a la información que nos
arrojará tendremos una visión de las vulnerabilidades en estos aplicativos.

7.8. Referencias bibliográficas

DotNetTricks. (2018, Agosto 6). Understanding Xamarin iOS - Build Native iOS App.
https://www.dotnettricks.com/learn/xamarin/understanding-xamarin-ios-build-
native-ios-app

Tally Ho. (s. f.). KindPNG. https://www.kindpng.com/imgv/hThmohT_screenshot-hd-

png-download/

OWASP. (s. f.). Mobile App Security Testing. https://mobile-

security.gitbook.io/mobile-security-testing-guide/overview/0x04b-mobile-app-
© Universidad Internacional de La Rioja (UNIR)

security-testing

Hacking Ético
22
Tema 7. Ideas clave
 A fondo
OWASP Mobile Security Testing Guide

OWASP. (s. f.). OWASP Mobile Security Testing Guide. https://owasp.org/www-project-

mobile-security-testing-guide/

Guía desarrollada por OWASP con procedimientos de análisis de seguridad sobre

plataformas móviles y uso de herramientas específicas para estas plataformas.
Además, ofrece una amplia, profunda y actualizada documentación sobre la
arquitectura de los principales sistemas móviles.

Android Hacking Workshop organizado por Hacker One

Hacker One (2021, febrero 24). Android Hacking Workshop by @B3nac Sec [Vídeo].
Youtube. https://www.youtube.com/watch?v=lhRXV9LZ7bY

Taller práctico en el que se desarrollan técnicas que permiten abordar el análisis de

aplicaciones Android, así como la explotación de la plataforma a través de estas.
© Universidad Internacional de La Rioja (UNIR)

Hacking Ético
23
Tema 7. A fondo
 Test
1. ¿Cuál es la extensión de las aplicaciones de iOS?
A. fichero .ios.
B. fichero .ipa.
C. fichero .apk.
D. No tiene extensión, en UNIX se utiliza el número mágico.

2. Para realizar análisis dinámico de aplicaciones Android:

A. Debemos contar con un dispositivo compatible.
B. Podemos emular el entorno con Android Studio.
C. Basta con el uso de un proxy socks.
D. Son aplicaciones nativas Java, así que necesitaremos sólo Java instalado.

3. Para realizar análisis dinámico de aplicaciones Ios:

A. Podemos emular el entorno con Apple Studio.
B. Debemos contar con un dispositivo compatible.
C. Basta con el uso de un proxy socks.
D. Son aplicaciones nativas, podremos ejecutarlas en nuestro mac.

4. Las aplicaciones de Android:

A. Corren aisladas en una sandbox virtual.
B. Están aisladas a través del sistema de permisos de Linux.
C. Son compatibles con iOS.
D. Pueden ejecutarse en Cydia.
© Universidad Internacional de La Rioja (UNIR)

Hacking Ético
24
Tema 7. Test
 5. Para obtener una aplicación de iOS:
A. La descargaremos de Apkpure.
B. Debemos extraerla del teléfono cuando se ejecute.
C. Bastará con descargarla del playstore y sacarla de disco.
D. No se puede por copyright.

6. El sistema adb:
A. Es el equivalente a gdb en Android.
B. Es una herramienta de comunicación con sistemas Android para su
administración.
C. Permite desarrollar aplicaciones para Android.
D. No es compatible con teléfonos reales.

7. El principal vector de ataque de los sistemas móviles:

A. Son las teleoperadoras.
B. Son las aplicaciones.
C. Es el bluetooth.
D. Es el sistema operativo.

8. El permiso de accesibilidad en Android es peligroso porque:

A. Hace accesible el sistema sin autenticación.
B. Permite acceder a todo el contenido de la pantalla.
C. No es en absoluto peligroso.
D. Levanta sistemas de acceso remoto por red.

9. Frida es:
A. Un sistema de fuzzing de aplicaciones móviles.
© Universidad Internacional de La Rioja (UNIR)

B. Una librería gratuita.

C. Un sistema de instrumentación de aplicaciones móviles.
D. Una técnica de análisis estático.

Hacking Ético
25
Tema 7. Test
 10. Señale la respuesta falsa. Podemos tratar de evadir las verificaciones HPKP:
A. Instalando una CA propia.
B. Con SSL Kill Switch.
C. Con un certificado válido.
D. Con Frida.
© Universidad Internacional de La Rioja (UNIR)

Hacking Ético
26
Tema 7. Test