Pentesting de aplicaciones iOS: jailbreak, Frida y MASVS L1-L2 2026

Auditar una aplicación iOS no se parece a auditar una aplicación Android, aunque ambas sean móviles. El ecosistema cerrado de Apple, la firma obligatoria de binarios, el sandbox estricto del kernel XNU y la dependencia operativa del App Store imponen restricciones que cambian por completo la cadena de herramientas y el orden de las pruebas. Un pentest iOS bien hecho requiere un dispositivo físico con jailbreak, no se resuelve con un simulador, y obliga a dominar técnicas específicas como el hooking dinámico de Objective-C y Swift con Frida o el bypass de pinning a nivel runtime.

Esta guía describe cómo montar el laboratorio, qué cubren los niveles MASVS L1 y L2, los vectores que aparecen una y otra vez en informes reales y las contramedidas que sí cierran la puerta. Está pensada para equipos de seguridad, desarrolladores iOS que quieren entender qué se les va a evaluar y responsables que deben decidir el alcance de una auditoría móvil.

Lo esencial: pentest iOS exige dispositivo físico con jailbreak (checkra1n, palera1n o Dopamine según versión), Frida para análisis dinámico y Objection para automatizar tareas comunes. MASVS L1 cubre apps generales, L2 añade controles para apps que manejan datos sensibles o financieros. Los hallazgos recurrentes son keychain mal configurado, secretos hardcodeados en Info.plist o binario, almacenamiento inseguro en UserDefaults, logging sensible, pinning ausente o bypass trivial y deeplinks sin validar. El hardening efectivo combina kSecAttrAccessibleWhenUnlocked, ATS estricto, detección de jailbreak multicapa y obfuscación a nivel LLVM.

Por qué iOS pentest requiere un setup específico

iOS lleva incorporadas tres capas defensivas que no existen en Android tradicional. La primera es el sandbox por aplicación, que aísla cada binario en /var/mobile/Containers/Data/Application/{UUID} sin acceso al resto del sistema. La segunda es la firma de código obligatoria: cualquier binario que no esté firmado por Apple o por un certificado de desarrollador válido se rechaza en el momento de cargarlo. La tercera es el cifrado completo del filesystem ligado al hardware (Secure Enclave) que impide leer el contenido del disco sin descifrar primero la clave de cada fichero.

Estas tres capas hacen que un análisis sin jailbreak sea superficial. Sin acceso de root no se puede leer el binario descifrado de la app, no se puede inspeccionar el keychain, no se puede modificar el ramdisk para inyectar agentes y no se puede saltar las protecciones que la propia app implementa. El simulador de Xcode tampoco vale: ejecuta binarios x86_64 o arm64 compilados para macOS, no ARM iOS reales, y muchas APIs sensibles (keychain real, Secure Enclave, sensores biométricos) son emulaciones que no reflejan el comportamiento real.

La conclusión práctica es directa: para un pentest iOS serio necesitas un iPhone o iPad físico, jailbreakeado, dedicado al laboratorio. Comprar un dispositivo de segunda mano compatible con la versión iOS que quieras auditar es el primer gasto del proyecto.

Setup de laboratorio iOS

El stack mínimo que usamos en auditorías reales combina software de host con herramientas que viven en el dispositivo objetivo.

En el host (macOS preferido, Linux funcional con limitaciones):

Xcode con sus Command Line Tools para lldb, otool, codesign y xcrun. Necesario incluso si no se desarrolla, porque muchas utilidades dependen de su toolchain.
MobSF (Mobile Security Framework) para análisis estático automatizado de IPAs. Genera informe inicial de strings, permisos, ATS y detección de patrones inseguros conocidos.
Frida y su CLI (frida, frida-trace, frida-ps). Hooking dinámico, intercepción de funciones y manipulación de runtime.
Objection sobre Frida. Automatiza tareas habituales: dump de keychain, bypass de pinning con scripts preinstalados, exploración del filesystem del sandbox.
Hopper o Ghidra para reversing del Mach-O. Ghidra es gratis y suficiente para la mayoría de casos.
class-dump para extraer la jerarquía Objective-C del binario y entender qué clases y métodos están expuestos.
Burp Suite o mitmproxy como proxy HTTP/S de interceptación.

En el dispositivo jailbreakeado:

checkra1n para dispositivos hasta iPhone X con iOS 12 a 14 (jailbreak permanente basado en exploit de bootrom checkm8).
palera1n para iPhone X y anteriores con iOS 15, 16 y 17 (también basado en checkm8, jailbreak semi-tethered).
Dopamine para dispositivos arm64e (iPhone XS y superiores) con iOS 15 a 17 (jailbreak semi-untethered basado en exploits de kernel).
Frida server instalado vía Cydia/Sileo desde el repo oficial de Frida.
OpenSSH para conectar al dispositivo por SSH (root con password alpine por defecto, cambiar inmediatamente).
Filza o gestor de ficheros equivalente para navegar el filesystem desde el propio dispositivo.

El emparejamiento Mac-iPhone se hace por USB con idevicepair pair o se establece una sesión SSH a root@<ip-iphone> después de instalar OpenSSH. La primera acción siempre es cambiar la contraseña por defecto: dejar alpine en un dispositivo jailbreakeado conectado a red expone el dispositivo a worms históricos como Ikee.

OWASP MASVS L1 vs L2

La guía de referencia es MASVS (Mobile Application Security Verification Standard) y su acompañante operativo MASTG (Mobile Application Security Testing Guide), ambos mantenidos por OWASP. MASVS define los requisitos de seguridad en dos niveles más uno opcional de resistencia.

L1 (Standard Security). Cobertura para cualquier app móvil. Verifica que se cumplan los controles básicos: comunicaciones cifradas, no almacenamiento de datos sensibles en claro, autenticación correcta, no exposición innecesaria de funcionalidad y manejo aceptable de logs. Es el nivel adecuado para apps que no manejan datos financieros, sanitarios ni acceso a infraestructura crítica.

L2 (Defense-in-Depth). Añade controles más estrictos para apps con datos sensibles regulados: banca, salud, gobierno, identidad. Refuerza autenticación (multi-factor, biometría correctamente integrada), exige cifrado más fuerte para almacenamiento local, prohíbe ciertas APIs (clipboard sin restricciones, screenshots en pantallas sensibles), obliga a pinning de certificados y a validación estricta de deeplinks.

MASVS-R (Resilience). Capa opcional sobre L1 o L2. Se aplica cuando la app debe resistir ingeniería inversa y manipulación: detección y respuesta ante jailbreak, debugger, hooks de Frida o emulación, integridad de código en runtime, obfuscación. Es habitual en apps de banca, gaming y DRM.

MASTG es el catálogo de pruebas concretas. Cada control MASVS tiene uno o varios casos de prueba documentados con comandos, scripts y resultados esperados. Es la referencia operativa real cuando hay que decidir cómo se valida un control concreto.

Análisis estático del IPA

El IPA es un ZIP con extensión .ipa. Dentro hay un directorio Payload/{AppName}.app/ con el binario Mach-O, los nib/storyboardc, el Info.plist, recursos y la carpeta _CodeSignature.

Pasos típicos de análisis estático:

Obtener IPA descifrado. El binario del App Store está cifrado con FairPlay. Para reversing real hay que extraerlo descifrado del dispositivo. Herramientas como frida-ios-dump, bagbak o flexdecrypt lo hacen en segundos sobre un dispositivo jailbreakeado.
Descomprimir y analizar Info.plist. Convertir de binario a XML con plutil -convert xml1 Info.plist. Buscar entradas sospechosas: NSAppTransportSecurity con excepciones globales, CFBundleURLTypes con esquemas custom mal validados, claves de API embebidas en strings personalizadas.
Inspeccionar el Mach-O con otool. Comprobar arquitecturas (otool -h), librerías dinámicas enlazadas (otool -L), flags de hardening (PIE, ARC, stack canaries con otool -hv).
Dump de clases Objective-C con class-dump {binario} > classes.h. Útil para entender la superficie expuesta antes de hookear.
Strings con strings o rabin2. Búsqueda de URLs, endpoints internos, tokens, palabras clave (password, token, secret, api_key). Es trivial encontrar secretos hardcodeados así.
Reverse engineering profundo en Hopper o Ghidra para funciones críticas: validación de licencia, lógica de pinning, comprobaciones de jailbreak.

Un patrón habitual: equipos de desarrollo dejan endpoints de staging o tokens de servicios cloud en Info.plist o en constantes del binario asumiendo que "está dentro de la app, nadie lo verá". Con un strings y un grep aparecen en segundos.

Análisis dinámico con Frida

El análisis estático es necesario pero rara vez suficiente. La mayoría de hallazgos críticos vienen del runtime, donde se observa qué hace la app realmente al usuario, qué llama, qué guarda y qué envía.

Flujo Frida básico:

# Listar procesos en el dispositivo
frida-ps -Uai

# Spawn de la app con script inyectado al arrancar
frida -U -f com.empresa.app -l script.js --no-pause

# Attach a app ya corriendo
frida -U -n NombreApp -l script.js

Un script típico para tracear llamadas Objective-C:

if (ObjC.available) {
  var keychain = ObjC.classes.SecItemAdd;
  Interceptor.attach(ObjC.classes.NSURLSession['- dataTaskWithRequest:completionHandler:'].implementation, {
    onEnter: function (args) {
      var req = new ObjC.Object(args[2]);
      console.log('[NSURLSession] ' + req.URL().absoluteString());
    }
  });
}

Para Swift el hooking es más complejo porque los nombres están mangleados. Frida 16+ resuelve símbolos Swift con Swift.classes, pero suele ser más práctico hookear las funciones Objective-C subyacentes (la mayoría de APIs sensibles del SDK siguen siendo Objective-C aunque la app esté escrita en Swift).

Bypass de certificate pinning. El caso más recurrente. Objection trae un comando preparado:

objection -g com.empresa.app explore
> ios sslpinning disable

Internamente engancha las funciones de validación de NSURLSession, AFNetworking, Alamofire y TrustKit, devolviendo siempre éxito. Si la app implementa pinning custom (compara hashes manualmente contra el certificado), hay que escribir un hook específico.

Una vez deshabilitado el pinning, configurar el proxy del iPhone hacia Burp en los ajustes WiFi e instalar el certificado CA de Burp en el dispositivo (Settings, General, About, Certificate Trust Settings, enable trust). A partir de ese momento todo el tráfico HTTPS de la app se observa y se modifica desde Burp.

Vulnerabilidades comunes en apps iOS

Los hallazgos que se repiten en informe tras informe agrupados por familia.

Keychain mal configurado. El keychain es el almacén seguro de iOS para credenciales y tokens. Cada entrada tiene un atributo kSecAttrAccessible que define cuándo es legible. Valores como kSecAttrAccessibleAlways o kSecAttrAccessibleAlwaysThisDeviceOnly (deprecados pero todavía aparecen) dejan el secreto accesible incluso con el dispositivo bloqueado, lo que permite extracción tras compromiso físico. El valor correcto para datos sensibles es kSecAttrAccessibleWhenUnlockedThisDeviceOnly.

Secretos hardcodeados. API keys, tokens de Firebase, credenciales de servicios cloud o cadenas de conexión enterradas en Info.plist, en .plist adicionales o como strings del binario. Se extraen con strings o aparecen en MobSF. El patrón típico es asumir que la firma del IPA protege el contenido, lo que es falso: cualquiera con un Mac puede descifrar y leer.

Almacenamiento inseguro en UserDefaults. UserDefaults no es un almacén cifrado, es un .plist en Library/Preferences/. Guardar tokens de sesión, JSON Web Tokens o datos personales ahí los deja en claro y legibles tras jailbreak.

Logging sensible. NSLog, os_log y print quedan accesibles en consola del sistema (idevicesyslog desde el host). Loggear cuerpos de respuesta API, tokens en cabeceras o flujos de autenticación filtra credenciales en cualquier dispositivo conectado por USB.

Autenticación biométrica débil. Implementar LAContext.evaluatePolicy sin verificar LAError específicos ni validar contra el keychain con kSecAccessControl permite bypass triviales con hooks Frida que devuelven success=true. El patrón seguro vincula la operación biométrica al desbloqueo de un item keychain con SecAccessControlCreateWithFlags y flag .biometryCurrentSet.

Universal Links y deeplinks sin validar. Si la app abre URLs de su esquema custom (miapp://) sin validar origen ni firma del payload, un atacante puede forzar navegación a vistas internas, ejecutar acciones autenticadas (transferir, cambiar contraseña) o inyectar payloads en webviews internos.

WebView con bridge JavaScript expuesto. WKWebView configurado con WKUserContentController y handlers que aceptan input sin filtrar permite ejecución de funciones nativas desde JavaScript controlado. Si además el WebView carga contenido remoto sobre HTTP o de origen no controlado, el atacante MITM tiene ejecución sobre APIs nativas.

Excepciones ATS. App Transport Security obliga por defecto a HTTPS con TLS 1.2 y cifrados modernos. Las excepciones (NSAllowsArbitraryLoads, NSExceptionDomains) se ven directamente en Info.plist. Una excepción global abre la puerta a downgrade y MITM en redes hostiles.

Detección de jailbreak trivial. Comprobar /Applications/Cydia.app o /private/var/lib/apt se salta con un hook de NSFileManager.fileExistsAtPath: que devuelve false para esas rutas. Las apps de banca serias combinan diez o quince comprobaciones a niveles distintos (filesystem, sandbox escape, dyld, sysctl, fork) y responden de forma no determinista.

IPC inseguro. Esquemas URL custom registrados sin validar el origen del caller, uso del pasteboard general para datos sensibles entre apps, app extensions con permisos excesivos. Cualquier app instalada puede leer el pasteboard general; copiar contraseñas o tokens ahí es una fuga directa.

Workflow Frida típico en una auditoría real

El flujo que repetimos en cada engagement iOS se ordena así:

Spawn de la app con Frida adjunto y script de logging genérico (todas las llamadas a NSURLSession, SecItemAdd, LAContext, WKWebView).
Operativa funcional completa (login, navegación, transacción, logout). Frida loggea lo que se mueve por debajo.
Dump del keychain con objection > ios keychain dump. Inspección de qué se guarda y con qué nivel de accesibilidad.
Listado del filesystem del sandbox con objection > env. Inspección de Documents/, Library/Caches/, Library/Preferences/, tmp/.
Bypass de pinning con ios sslpinning disable y captura de tráfico en Burp.
Reverse engineering puntual de funciones críticas (validación de licencia, lógica anti-debug, comprobaciones JB) con Ghidra y hooks Frida específicos para anularlas.
Pruebas IPC lanzando URLs custom (xcrun simctl openurl en simulador, uiopen en dispositivo) y app extensions desde otras apps de prueba.
Análisis de respuestas en distintos estados (con red, sin red, con cuenta nueva, con cuenta privilegiada).

Cada hallazgo se documenta con captura, request/response y, cuando aplica, script Frida reproducible.

Hardening efectivo

Las contramedidas que sí cierran la puerta en orden de impacto:

Keychain con kSecAttrAccessibleWhenUnlockedThisDeviceOnly y SecAccessControl con biometryCurrentSet para items sensibles. Bloquea extracción offline y vincula uso a sesión desbloqueada con biometría vigente.
ATS estricto sin excepciones. Si hay que comunicar con dominios legacy, cambiar el backend antes que abrir agujero. Cualquier excepción ATS es deuda técnica que aparece en informe.
Pinning con URLSessionDelegate propio validando hash de Subject Public Key Info, no del certificado entero. Sobre URLSession estándar o sobre TrustKit correctamente configurado.
Detección de jailbreak multicapa: comprobaciones en filesystem, dyld, sandbox, fork, sysctl, integridad de funciones críticas, todas en C compilado, no en Objective-C hookable. Respuesta no determinista (no salir inmediatamente: degradar funcionalidad de forma que el atacante no localice la comprobación con bisect).
Obfuscación a nivel LLVM con pases como Hikari, Obfuscator-LLVM o equivalentes comerciales. Hace que reverse engineering tarde días en vez de horas para funciones críticas.
Runtime integrity checks: hash de secciones __TEXT del binario contra valor esperado, detección de Frida vía /proc/self/maps (sysctl en iOS) o probe de puertos comunes de frida-server.
No loggear datos sensibles. Política de logging que prohíbe cuerpos de respuesta, tokens, headers de autenticación y datos personales en cualquier nivel.
Validación estricta de URLs y deeplinks con allowlist de dominios y firma de payloads sensibles.

Ningún control aislado es suficiente. El stack se evalúa como conjunto.

App Store, MDM y distribución empresarial

El contexto de distribución importa. Una app del App Store pública pasa filtros estrictos de Apple (revisión humana, scans automáticos) pero no es inmune: hallazgos críticos aparecen igual. Las apps empresariales distribuidas vía Apple Business Manager y firmadas con certificado de desarrollador empresarial saltan revisión, lo que aumenta el riesgo de descuido.

Las soluciones MDM (Mobile Device Management) permiten políticas que cierran muchos vectores: bloqueo de jailbreak, prohibición de instalación de apps no firmadas por la organización, separación de contenedor personal y corporativo, wipe remoto. Auditar una app que se distribuye sólo vía MDM exige replicar la política en el dispositivo de laboratorio.

El sideloading vía certificado empresarial es un riesgo conocido. Apple revoca certificados que detecta abusados, pero entre revocaciones se distribuyen apps maliciosas firmadas como si fueran legítimas. Cualquier app que aparezca instalada fuera del App Store en un dispositivo corporativo es señal de investigación inmediata.

Preguntas frecuentes

Se puede hacer pentest iOS sin jailbreak

Análisis estático sí (sobre IPA extraído o descargado). Análisis dinámico real no. Sin jailbreak no hay Frida server, no hay acceso al keychain, no hay lectura del sandbox de la app y no hay forma de inspeccionar lo que guarda en disco. Una auditoría sin jailbreak detecta a lo sumo el 30 al 40 por ciento de los hallazgos que detecta una auditoría completa.

El simulador de Xcode es suficiente para auditar

No. El simulador ejecuta arquitectura del host (x86_64 o arm64 macOS), no ARM iOS real, y muchas APIs sensibles son emulaciones. Keychain, Secure Enclave, biometría y comportamientos de sandbox no son reales. Vale para desarrollo y para análisis estático complementario, no como sustituto del dispositivo físico.

Apple rechaza apps por hallazgos de seguridad en revisión

Apple revisa principalmente cumplimiento de guidelines de UX, privacidad declarada (App Privacy Report) y APIs prohibidas. No hace pentest. Rechaza apps que usan APIs privadas, que mienten en el manifiesto de privacidad o que violan políticas obvias, pero un secreto hardcodeado o un keychain mal configurado pasa la revisión sin problema.

MASVS L1 o L2, cuál elegir para una auditoría

L1 es el mínimo razonable para cualquier app. Para apps que manejan datos personales sensibles, pagos, salud, gobierno o identidad, L2 es lo esperable. Apps con riesgo de ingeniería inversa relevante (banca, gaming con compras, DRM) añaden MASVS-R sobre el nivel base. La decisión la suele guiar el regulador del sector cuando aplica.

Es legal usar Frida sobre una app comercial

Sobre tu propia app o sobre apps con autorización del propietario, sí. Sobre apps de terceros sin autorización entra en zona gris que depende de jurisdicción y propósito. En auditorías profesionales el alcance siempre va firmado y el cliente autoriza explícitamente análisis dinámico, reversing y pruebas de seguridad sobre la app objetivo.

Cuánto tarda una auditoría iOS

Una auditoría L1 sobre app de complejidad media (10 a 20 pantallas, login y funcionalidad estándar) ocupa entre 5 y 8 días de trabajo efectivo. L2 sobre app financiera con backend complejo y resistencia añadida (MASVS-R) sube a 10 a 15 días. La diferencia la marcan la cantidad de endpoints, la complejidad del flujo de autenticación y la profundidad de reversing requerida.

Recursos relacionados

Pentest iOS con Secra

En Secra ejecutamos auditorías iOS completas sobre MASVS L1 y L2 con extensión opcional MASVS-R. Combinamos análisis estático del IPA, dinámico con Frida y Objection, reversing puntual en Ghidra y revisión de la integración con el backend. El entregable incluye los hallazgos priorizados, la evidencia técnica reproducible y las recomendaciones de hardening específicas para cada control. Si tu app pasa por App Store, MDM o ambos, lo cubrimos en el mismo proyecto.

Contacta con nuestro equipo para definir el alcance y los plazos de la auditoría iOS de tu aplicación.

Sobre el autor

Equipo de Secra Solutions

Ethical hackers certificados OSCP, OSEP, OSWE, CRTO, CRTL y CARTE, con más de 7 años de experiencia en ciberseguridad ofensiva. Autores de los CVE-2025-40652 y CVE-2023-3512.

Conoce al equipo →Nuestra investigación →

Compartir artículo