Seguridad Móvil: Un Ecosistema Diferente

Objetivo de esta Guía

Romper la ilusión de que un celular es solo "una computadora pequeña". Hackear una aplicación móvil requiere un conjunto de habilidades totalmente distinto al de hackear una página web. Un analista de ciberseguridad moderno debe entender por qué las reglas del juego cambian drásticamente cuando pasamos de Windows/Linux a Android e iOS.

---

1. El Mito de la "Mini-Web"

aqui está uno de los errores más grandes que comete la gente. Mucha gente asume que una aplicación móvil (como la app del banco) es simplemente una página web disfrazada con botones más grandes. Esto es un error GRAVE.

• En la Web: Tu navegador web (Google Chrome) es un intermediario ciego. Descarga el código HTML/JavaScript del servidor en tiempo real, lo muestra, y cuando cierras la pestaña, lo destruye. Tú no posees el código del servidor del banco.
• En Móvil: Cuando descargas la App del banco de la Play Store, estás descargando todo el código fuente del cliente directamente a tu disco duro físico. Tú eres el dueño de ese código. Puedes abrirlo, desarmarlo, leerlo y modificarlo antes de ejecutarlo.

Por qué esto importa: Esta diferencia cambia toda la estrategia del atacante. El atacante móvil tiene la aplicación en la palma de su mano para experimentar de forma offline, sin que el servidor del banco lo detecte. Es como si el banco te entregará las llaves de su caja fuerte para que las estudies.

---

2. Android (El Mundo de Java/Kotlin)

Android está construido sobre un núcleo modificado de Linux, pero las aplicaciones se escriben en lenguajes como Java o Kotlin (y más recientemente con frameworks híbridos como Flutter o React Native).

• El Archivo APK: Cuando descargas una app, descargas un archivo con extensión .apk (Android Package Kit).
• El Gran Secreto: Un archivo .apk no es código alienígena. Es literalmente un archivo comprimido .zip. Si tomas la app del banco (banco.apk), le cambias el nombre a banco.zip y lo descomprimes, podrás ver todos los archivos de sonido, las imágenes y el código empaquetado adentro.

Estructura Interna del APK

Un APK descomprimido revela los siguientes componentes críticos:

• classes.dex (Dalvik Executable): Contiene el bytecode compilado de la aplicación. En apps modernas con métodos múltiples, pueden existir classes2.dex, classes3.dex, etc.
• AndroidManifest.xml: Manifiesto en formato binario XML que declara permisos, actividades, servicios, receptores de broadcast y proveedores de contenido. Es la primera fuente de reconocimiento para un atacante.
• resources.arsc: Tabla de recursos compilados que contiene strings, layouts y valores. Las cadenas de texto aquí pueden filtrar URLs, endpoints de API y rutas.
• lib/: Bibliotecas nativas compiladas para distintas arquitecturas ARM (armeabi-v7a, arm64-v8a, x86). Usualmente escritas en C/C++ y empaquetadas como archivos .so. Aquí se suele ocultar la lógica más sensible.
• META-INF/: Certificados y firmas del APK: MANIFEST.MF, CERT.SF y CERT.RSA. Contienen los hashes de cada archivo para verificar la integridad del paquete.
• res/: Recursos compilados (imágenes, layouts XML compilados, etc.).

Proceso de Compilación y Ejecución

Android utiliza el runtime ART (Android Runtime) desde Android 5.0 (Lollipop), reemplazando al antiguo Dalvik. ART compila el bytecode .dex a código nativo ARM durante la instalación (AOT - Ahead-of-Time) o utiliza una combinación de AOT con interpretación/JIT (Just-In-Time) en versiones recientes.

El pipeline de compilación es:

1. Código fuente (.java/.kt) → Compilador de Java/Kotlin → Bytecode .class (JVM)
2. .class → d8 (herramienta de DX reemplazada) → classes.dex (Dalvik bytecode)
3. classes.dex + recursos → aapt2 (Android Asset Packaging Tool) → APK firmado con apksigner

Android Security Model: Aislamiento por UID

Android implementa sandboxing a nivel de kernel Linux. Cada aplicación recibe un UID (User ID) único de Linux en el momento de la instalación. La aplicación se ejecuta como ese usuario en un proceso separado, con su propio directorio de datos (/data/data/<package>/) al que ninguna otra app puede acceder sin permisos explícitos.

• SELinux (Security-Enhanced Linux): Desde Android 4.3, SELinux opera en modo enforcing. Define políticas de seguridad obligatorias que restringen incluso al usuario root. Un proceso con UID system_server no puede acceder a archivos del UID u0_a123 aunque tenga privilegios elevados.
• Verified Boot: Android verifica criptográficamente la integridad del sistema operativo en cada arranque. Si la partición del sistema ha sido modificada, el dispositivo muestra una advertencia y puede negarse a arrancar.
• Keystore y KeyChain: Almacenamiento criptográfico respaldado por hardware (TEE - Trusted Execution Environment) en dispositivos compatibles. Las claves privadas generadas aquí nunca salen del entorno seguro.

Firmado de APK (App Signing)

El esquema de firmado ha evolucionado en tres versiones:

Versión	Introducción	Características
v1 (JAR signing)	Android 1.0	Firma basada en META-INF/. Vulnerable a manipulaciones porque los archivos ZIP pueden reorganizarse sin invalidar la firma.
v2 (APK Signature Scheme)	Android 7.0	Firma de todo el APK como un bloque binario. Inválida cualquier manipulación de bytes.
v3 (APK Signature Scheme)	Android 9.0	Similar a v2 pero permite rotación de claves de firma mediante certificados de prueba.
v4	Android 11	Diseñada para actualizaciones incrementales (APK patches).

El Riesgo del Android Abierto

por diseño, Android permite a los usuarios habilitar opciones de desarrollador e instalar aplicaciones fuera de la tienda oficial (sideloading). Esto lo hace un ecosistema increíblemente fértil para el malware, ya que un usuario puede ser engañado fácilmente para descargar un "juego gratis" desde una página rusa.

Por qué esto importa: Es como si tu casa tuviera una puerta trasera que tu decides si abrir o no. El problema es que la mayoría de la gente no sabe cuando la esta abriendo.

Rooteo (Superuser Privileges)

Rootear un Android implica explotar vulnerabilidades del kernel (CVE-2016-5195, Dirty COW, etc.) para escalar privilegios a root (UID 0). Una vez rooteado:

• Magisk es el método moderno de root "sin sistema" (systemless), que modifica el arranque (boot.img) en lugar de la partición del sistema, permitiendo ocultar el root de aplicaciones que lo detectan.
• SuperSU (deprecado) modificaba archivos del sistema directamente (/system/xbin/su).
• Las aplicaciones financieras implementan detección de root verificando: la presencia del binario su, paquetes de Magisk/SuperSU en el sistema, montaje del sistema en modo lectura/escritura, integridad del archivo build.prop, y acceso a particiones protegidas.

---

3. iOS (El Fuerte Sandboxing)

Cuando una empresa diseña un sistema operativo desde cero pensando en seguridad? Pasa iOS. Apple diseñó iOS con la paranoia militar en mente. Mientras que en Android tú tienes el control (si lo deseas), en iOS el usuario no tiene control de su propio dispositivo. Apple dicta qué corre y qué no.

• El Sandboxing (La Cárcel de Arena): En iOS, cada aplicación vive en una celda de aislamiento virtual absoluta (Sandbox). La app de Facebook no puede leer los archivos que están guardados en la app de WhatsApp. No tienen forma de comunicarse entre sí sin pasar por el permiso explícito de Apple.
• El Archivo IPA: El equivalente al APK en Apple es el .ipa (iOS App Store Package).

Arquitectura de Seguridad iOS

iOS implementa una arquitectura de seguridad en múltiples capas:

1. Secure Enclave: Coprocesador de hardware aislado del procesador principal (Apple A7 en adelante). Maneja operaciones criptográficas sensibles: Touch ID, Face ID, claves de cifrado de dispositivo. No es accesible desde el kernel principal. Su firmware está firmado y verificado en cada arranque.

2. Kernel Integrity Protection (KPP) / Kernel Text Readonly Region (KTRR): Protege la memoria del kernel contra modificaciones en caliente. Impide que incluso el kernel se modifique a sí mismo una vez arrancado.

3. Pointer Authentication Codes (PAC): Desde el chip A12, iOS implementa PAC (ARMv8.3). Cada puntero de retorno de función lleva una firma criptográfica de 16 bits. Si un atacante modifica la dirección de retorno (técnica clásica de ROP/JOP), la firma se inválida y el procesador crashea intencionalmente.

4. Page Protection Layer (PPL): Protege páginas de memoria del kernel contra escritura incluso desde código kernel comprometido.

5. Code Signing: iOS aplica firma de código y políticas de ejecución. Las vías de distribución, perfiles y requisitos dependen del programa y la región; consulta la documentación vigente de Apple. Existen mecanismos controlados para código generado o interpretado, por lo que no conviene expresarlo como una prohibición absoluta.

6. App Store Review: Apple revisa manualmente cada aplicación antes de publicarla. Sin embargo, esto no es infalible: ha habido casos de malware aprobado como XcodeGhost (2015) o Lightspy (2020) que engañaron el proceso de revisión.

Estructura del IPA

Un archivo .ipa es también un archivo ZIP que contiene:

• Payload/: Directorio principal que contiene el bundle de la aplicación (AppName.app).
• Info.plist: Metadatos de la aplicación: bundle identifier, versión, permisos declarados, URL schemes soportados.
• _CodeSignature/CodeResources: Hashes de todos los archivos del bundle para verificación de integridad.
• embedded.mobileprovision: Perfil de aprovisionamiento que asocia la app con un desarrollador y dispositivos autorizados.
• Frameworks/: Frameworks embebidos (dylibs) que la aplicación utiliza.
• Mach-O Executable: El binario principal en formato Mach-O (Mach Object), no ELF como en Linux/Android. Contiene segmentos __TEXT, __DATA, __LINKEDIT, __OBJC.

Sandboxing Técnico

Cada aplicación en iOS se ejecuta bajo un perfil de sandbox (definido por Apple en sandbox.plist) que restringe:

• Acceso al sistema de archivos: solo su propio directorio Container/.
• Acceso de red: controlado por el firewall del kernel (socket_filter).
• Acceso a hardware: cámara, micrófono, Bluetooth requieren aprobación explícita del usuario en tiempo de ejecución desde iOS 10+.
• Comunicación entre procesos (IPC): extremadamente limitada. XPC (XNU IPC) está disponible solo para servicios del sistema.
• Archivos compartidos: solo a través de UIActivityViewController o App Groups (configurados por el desarrollador).

El Jailbreak

Para hackear aplicaciones en iOS (o para investigar malware en iPhones), los analistas de seguridad se ven obligados a hacer un Jailbreak (Fuga de la cárcel). Esto es un proceso de explotación física del teléfono que rompe el sistema operativo para permitir que las aplicaciones salgan de su "sandbox" y el investigador tenga permisos de Dios (Root).

Tipos de jailbreak:

Tipo	Característica	Persistencia
Tethered	Requiere conexión a PC en cada reinicio	No persiste
Semi-tethered	Puede reiniciar, pero pierde jailbreak hasta re-ejecutar exploit	Parcial
Untethered	Persiste a través de reinicios	Total
Semi-untethered (moderno, ej: unc0ver, Taurine, Fugu15)	Jailbreak no persiste en reinicio, pero se re-aplica con una app	Bajo demanda

Armas modernas como Corellium (virtualización de iOS) permiten emular dispositivos iOS hardware-acelerados sin necesidad de jailbreak, utilizados por equipos de seguridad empresarial.

Sin un iPhone con Jailbreak, el Mobile Pentesting en Apple es casi imposible.

---

4. Diferencias Clave Android vs iOS para el Pentester

Aspecto	Android	iOS
Acceso al código	APK descompila fácil (Java/Kotlin bytecode)	IPA requiere extraer Mach-O (Objective-C/Swift)
Root/Jailbreak	Relativamente fácil (Magisk, exploits conocidos)	Muy difícil en versiones recientes (PAC, PPL)
Sideloading	Permitido por defecto	No permitido (solo desarrolladores con certificado)
Análisis dinámico	Posible con dispositivo root	Requiere jailbreak o Corellium
Frameworks nativos	NDK (C/C++) a través de JNI	Metal, CoreML, nativos en Objective-C/Swift
Restricciones de red	Frida + iptables fácil	Requiere proxy configurado o VPN
Costo de entrada	Dispositivo económico + Frida	Dispositivo Apple + certificado desarrollador

---

5. Superficie de Ataque Móvil

Android

1. Intent Hijacking: Una aplicación maliciosa puede registrar un intent-filter que intercepte intents explícitos de otra app. Por ejemplo, interceptar un intent de cámara que devuelve la foto a la app bancaria.
2. Content Provider Leak: Proveedores de contenido mal configurados exponen bases de datos SQLite locales a otras aplicaciones.
3. WebView Vulnerabilities: WebViews mal configurados con setJavaScriptEnabled(true) y sin deshabilitar file:// access permiten XSS y robo de archivos locales.
4. Dex Class Loading dinámico: Aplicaciones que cargan código DEX desde servidores remotos sin verificar la firma.
5. Backup Exfiltration: Si android:allowBackup="true" en el manifiesto, cualquier app de backup (como adb backup) puede extraer datos de la aplicación.

iOS

1. URL Scheme Hijacking: Si una app registra un URL scheme personalizado (mybank://transfer?to=...), otras apps pueden invocarlo o un malware puede registrar el mismo scheme.
2. UIPasteboard Leak: El portapapeles de iOS es global. Apps pueden leer lo que otra app copió (contraseñas, direcciones).
3. Keychain Access Groups: Si dos apps comparten el mismo access group en el keychain, una puede leer los secretos de la otra.
4. Certificate Transparency checks: Algunas apps implementan verificaciones de CT que pueden ser eludidas por proxies de intercepción si no están correctamente implementadas.

---

6. Herramientas del Ecosistema Móvil

Análisis Estático

Herramienta	Plataforma	Función
Jadx-GUI	Android	Descompilación DEX → Java
APKTool	Android	Decompila recursos y smali
MobSF	Android + iOS	Framework automatizado de análisis estático + dinámico
Ghidra	Multiplataforma	Reverse engineering de binarios nativos (ARM64)
Hopper	iOS	Descompilador Mach-O para macOS
class-dump	iOS	Extrae encabezados Objective-C del binario Mach-O
Radare2 / rizin	Multiplataforma	Framework de RE para terminal

Análisis Dinámico

Herramienta	Plataforma	Función
Frida	Android + iOS	Instrumentación dinámica cross-platforma
Objection	Android + iOS	Frida wrapper para exploración runtime
Drozer	Android	Marco de evaluación de seguridad para Android
Burp Suite	Proxy	Interceptación de tráfico HTTPS
mitmproxy	Proxy	Interceptación programable Python
Xposed / LSPosed	Android	Hooks a nivel de framework Java

Plataformas de Análisis Automatizado

• MobSF (Mobile Security Framework): Plataforma open-source que integra análisis estático y dinámico. Escanea APK/IPA en busca de hardcoded secrets, permisos excesivos, vulnerabilidades WebView, esquemas de cifrado inseguros.
• NowSecure / Quokka: Plataformas comerciales para análisis continuo en pipelines CI/CD.
• Appknox / Data Theorem: Soluciones SAST/DAST específicas para móvil.

---

7. Técnicas de Detección Anti-Análisis (Evasión)

Las aplicaciones financieras implementan protección en tiempo de ejecución:

• Root Detection: Verifica su, Magisk, paquetes root, montaje del sistema.
• Emulator Detection: Detecta QEMU, Genymotion, BlueStacks verificando propiedades del build (ro.kernel.qemu, goldfish), números IMEI falsos, sensores ausentes.
• Debugger Detection: android:debuggable="false", verifica TracerPid en /proc/self/status.
• Tamper Detection: Verifica la suma de verificación (checksum) de classes.dex y recursos contra valores esperados.
• Certificate Pinning: Previene la interceptación de tráfico SSL incluso con un proxy instalado.
• Obfuscation: ProGuard/R8 renombra clases y métodos. DexGuard aplica cifrado de strings y ofuscación de flujo de control.
• Anti-Frida: Detecta el puerto de Frida (27042), verifica nombres de hilos, busca la biblioteca frida-agent en memoria.

---

Criterio de Dominio (Autoevaluación)

1. En una auditoría de Red Team, ¿Por qué tienes una ventaja táctica mucho mayor al auditar la Aplicación Móvil del banco frente a auditar su Página Web oficial? (Piensa en la propiedad del código).
2. Si sospechas que una aplicación descargada en tu Android es un malware que roba las fotos de tu cámara, ¿Cuál es el primer paso rudimentario que podrías hacer en tu propia computadora para ver los archivos internos de esa aplicación?
3. Explica el concepto de "Sandboxing" en iOS y por qué un analista defensivo no puede instalar un software "Antivirus" tradicional en un iPhone para escanear otras aplicaciones.
4. ¿Cuál es la diferencia entre un APK firmado con v2 vs v1, y por qué la firma v2 es más segura contra manipulaciones del paquete?
5. Describe el propósito del archivo AndroidManifest.xml dentro de un APK y qué riesgos de seguridad se pueden identificar al inspeccionarlo.