Parte: 13 — Seguridad móvil, IoT e inalámbrica · Fuente: Apple Platform Security Guide y The Mobile Application Hacker's Handbook (Chell et al.) ⏱️ Duración estimada: 90 min · Nivel: Intermedio
Entender la arquitectura de seguridad de iOS —una de las más cerradas y robustas del mercado— para razonar sobre qué defiende y por qué el pentest de iOS difiere tanto del de Android. Cubriremos la cadena de arranque seguro, el Secure Enclave, la protección de datos por clases, el sandbox de apps, el cifrado de código y el modelo de jailbreak, dejando el terreno preparado para el pentest práctico de la siguiente clase.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | Cadena de arranque seguro | Ancla la confianza en hardware |
| 2 | Secure Enclave (SEP) | Aísla claves y biometría |
| 3 | Data Protection por clases | Cifra datos ligados al passcode |
| 4 | Sandbox y entitlements | Aísla apps y restringe capacidades |
| 5 | Code signing y FairPlay | Solo corre código firmado por Apple |
| 6 | Keychain | Almacén de secretos del sistema |
| 7 | Jailbreak | Qué habilita y qué rompe |
iOS verifica una cadena de componentes al iniciar y exige firma para el código ejecutable. En runtime, la sandbox restringe archivos y servicios; los entitlements conceden capacidades específicas; ASLR y protecciones de memoria elevan el coste de explotación. Apple documenta estas capas como controles separados: una app firmada tiene procedencia aceptada para ejecución, no una garantía de ausencia de defectos.
Data Protection asocia clases de archivo con el estado de bloqueo y las claves del dispositivo. Keychain almacena elementos con políticas de accesibilidad y, cuando corresponde, control de acceso. Elegir una clase demasiado disponible puede exponer información tras reinicio o bloqueo; elegir una demasiado restrictiva puede romper tareas en segundo plano. La decisión depende de cuándo necesita el dato y qué consecuencia tendría su acceso.
Los grupos de acceso, extensiones y esquemas URL crean comunicación intencional entre componentes. Universal links incorporan asociación con dominios; un esquema personalizado puede ser reclamado por otra app en ciertos contextos. La app receptora valida origen, estado y autorización, no confía solo en haber sido invocada.
Un token se guarda en Keychain con una clase apropiada, pero la respuesta completa de login termina en un log y en una copia de preferencias. La fortaleza del Keychain no cubre duplicados. El equipo inventaría todas las representaciones, elimina logging, aplica minimización y prueba comportamiento bloqueado/desbloqueado.
| Término | Definición útil |
|---|---|
| Entitlement | Capacidad firmada que autoriza acceso a determinados servicios. |
| Sandbox | Restricción del proceso a su contenedor e interfaces permitidas. |
| Data Protection class | Política que liga acceso a archivos con claves y estado del dispositivo. |
| Keychain | Almacén de credenciales con clases de accesibilidad y controles. |
| Team ID | Identidad del equipo firmante usada en controles de plataforma. |
El alumno domina la arquitectura si explica qué demuestra cada capa, selecciona una clase de protección según uso, rastrea datos duplicados y analiza una comunicación entre apps sin asumir que firma equivale a seguridad.
Complete, CompleteUntilFirstUserAuthentication, None). Característica: las claves se derivan del passcode y del UID de hardware.checkm8, hardware antiguo) — solo en dispositivo propio.# Con dispositivo jailbroken y SSH habilitado
ssh root@<ip-dispositivo> # contraseña por defecto 'alpine' — CÁMBIALA
uname -a # kernel
ls /var/mobile/Containers/ # contenedores de apps
⚠️ Usa exclusivamente dispositivos de tu propiedad dedicados a laboratorio.
/var/containers/Bundle/Application/ y /var/mobile/Containers/Data/Application/.class-dump para ver interfaces Objective-C.ios keychain dump) observa qué entradas guarda una app propia y su clase de accesibilidad.checkm8 y por qué no puede parchearse por software.Elabora una ficha técnica de arquitectura de seguridad iOS que, para un dato sensible concreto (p. ej. un token de sesión), explique dónde debería almacenarse, con qué clase de Data Protection/Keychain, y qué lo protegería frente a un atacante con acceso físico al dispositivo bloqueado. Criterio de aceptación: la ficha distingue correctamente el escenario "dispositivo bloqueado tras primer desbloqueo" del escenario "nunca desbloqueado tras encendido".
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
| Jailbreak no soportado | Dispositivo/versión sin exploit público; usa hardware compatible con checkm8 |
| SSH rechaza conexión | OpenSSH no instalado o servicio caído; instálalo desde Sileo |
Contraseña alpine filtrada |
Nunca la cambiaste; cámbiala tras el primer acceso |
| class-dump vacío | Binario Swift o cifrado; descífralo primero (frida-ios-dump) |
| App no arranca en jailbroken | Detección de jailbreak; se evade en la clase siguiente |
❓ ¿Por qué iOS se considera más difícil de auditar que Android? Por el code signing obligatorio y el sandbox estricto: sin jailbreak no puedes ejecutar herramientas ni instrumentar apps, y los jailbreaks son cada vez más escasos.
❓ ¿El Secure Enclave puede extraerse o volcarse? No es una función que una app desactive. Es un subsistema con arranque y memoria protegidos; aun así, la seguridad completa depende de políticas de acceso, código de plataforma, dispositivo y forma en que la app usa las operaciones.
❓ ¿Puedo hacer algo sin jailbreak? Sí: análisis estático del IPA, revisión de Info.plist y entitlements, y pruebas de red con proxy, aunque el pinning y muchos controles requieren instrumentación.
Clase 262 — Pentest de aplicaciones Android