2. Trabajando en seguridad desde hace 6 años
Apasionado por la seguridad de toda la vida

6. ¿En serio vamos a diseccionar un sistema operativo?
¿Y además hablando también de hardware?
¿Estamos locos?

7. http://images.apple.com/ipad/business/docs/i
OS_Security_May12.pdf

8. Especialmente interesante a partir de 3GS
Cifrado total del almacenamiento
Procesador criptográfico
Claves que nunca salen del mismo y ‘fuseadas’ para cada
unidad (UID & GID)

12. Combinan CPU (ARM Cortex) + GPU + RAM
S5L8920 iPhone 3GS
S5L8930 (Apple A4) iPad / iPhone 4 / ATV 2G
S5L8940 (Apple A5) iPad 2 / iPhone 4S
S5L8945 (Apple A5X) iPad3
S5L8950 (Apple A6) iPhone 5
Familia ARMv7
Juegos de instrucciones ARM, THUMB y THUMB-2

13. Originalmente desarrollado para el primer iPhone (2007)

14. Sin duda uno de los sistemas operativos más seguros
Primera versión: iPhoneOS 1.0
Además cada vez más seguro
Basado en Mac OS X

15. iPhone OS 1.0
Sin sandboxing
Todo corría como root
Sin firma de código ni DEP ni ASLR
¡Sin apps!
iPhone OS 1.0 libTiff Exploit (Tavis Ormandy)

16. iOS 2 implementa la mayor parte de la actual arquitectura
App Store
Sin ASLR…
Casi todos los procesos corren sin privilegios
SMS exploit (Charlie Miller)
La sandbox era igual de permisiva para todas las apps.
Jailbreak Ikee Worm

18. iOS 3
Sin ASLR
Introducen code signing.
MobileSafari Pwn2Own 2010
Payload full ROP
No rompieron la sandbox

19. iOS 4
Se introduce el sistema de cifrado actual
En realidad con alguna pequeña modificación
jailbreakme.com (v2) (by comex)
Stack Overflow (Safari) + Integer Overflow (IOKit)
iOS 4.3
Aplicaciones compiladas con PIE
Introduce ASLR
main 256 posibles ubicaciones (si PIE)
dyld 256 posibles ubicaciones (si PIE)
dynamic library cache 4200 posibles ubicaciones

20. iOS 4.3.3
jailbreakme.com (v3 Saffron) (by comex again)
Leaking Integer Overflow (Safari) + Problema de tipado
(IOMobileFrameBuffer) + Incomplete Codesign

21. http://esec-lab.sogeti.com/post/Analysis-of-
the-jailbreakme-v3-font-exploit

22. iOS 5
Introduce Stack Canaries
Introduce Automatic Reference Counting
dyld siempre se mueve sea o no PIE el binario.
Exploit Corona (5.1.1)
Racoon Format String Overflow +
HFS Heap Overflow
Se cierra vulnerabilidad que permitía downgrades
Se acaba con el incomplete code signing
iOS 6
Sin novedades conocidas en la arquitectura de seguridad
Parcheo continuado de bugs (197)

23. Una clave para cada archivo
File System Key
Se genera durante la instalación
Está cifrada con UID
Si se borra se pierde todo
Effaceable Storage!
Diferentes Class Keys

24. Wipe muy rápido y efectivo
Posible cambiar fácilmente la “Clase” de un fichero
Es posible cambiar el Passcode sin recifrar todo.
Acceso a los ficheros en función de la clase del mismo
AES256-CBC

25. Los datos se almacenan según cuando deben estar accesibles
Dispositivo desbloqueado
Dispositivo alguna vez desbloqueado (arrancado)
Siempre
Cada clase tiene una clave maestra…
… cifrada con una combinación de passcode y UID
Estas claves se almacenan en la “keybag” del sistema

26. Región especial de las flash
Almacena tres claves
FileSystem Key
Clave de la clase NSProtectionNone
Clave del keybag del sistema

27. NSFileProtectionComplete
Passcode + UID
Se borra al bloquear
NSFileProtectionCompleteUntilFirstUserAuthentication
Passcode + UID
No se borra al bloquear
NSFileProtectionNone
UID
Clave de la clase guardada en Effaceable Storage

28. NSFileProtectionCompleteUnlessOpen
Ficheros que necesitan escribirse con el dispositivo bloqueado
Se genera un par efímero
Con ECDH se crea un secreto compartido con la privada
efímera y la pública de la clase.
Los metadatos del fichero almacenan:
La clave del fichero cifrada con el hash del secreto
La parte pública efímera
Se borra la parte privada
Cuando se cierra el fichero su clave se borra
Para abrirlo:
Recrear el secreto compartido con la parte privada de la
clase y la pública efímera
Descifrar la clave del fichero con el hash del secreto

31. Base de datos SQLite
Permiten guardar información de forma fácil a las Apps
NSFileProtectionNone
Acceso a través de API provista por Apple
Acceso permitido o no en función de
keychain-access-groups
application-identifier
Clases análogas a las de los ficheros
Sin NSFileProtectionCompleteUnlessOpen
AES128-GCM

33. Contienen las claves de las clases. Ficheros & Keychain
System keybag: donde están normalmente en el sistema
Se accede a través de AppleKeyStore.kext
Triple cifrado
Filesystem key
System keybag key
Cada clave de clase cifrada con UID / passcode
Backup keybag: usada en los backups cifrados de iTunes
PKBDF2(password iTunes) * 10000

34. iCloud keybag: similar a la de Backup
Usa criptografía asimétrica como en “Protected Unless
Open” para hacer el backup en el background.
Escrow keybag:
iOS la crea al conectar con iTunes por primera vez y se
envía cifrada al PC con una clave.
La clave queda guardada en el dispositivo
El PC almacena la keybag cifrada con la clave.
La clave se envía cuando se conecta a iTunes y permite
sincronizar aunque el dispositivo esté bloqueado.
Utilizada también para MDM.

36. La Passcode Key se calcula utilizando el UID
Proceso deliberadamente lento
No es posible crack offline!
En iPhone 4 con iOS 5:

37. Es un dispositivo embebido
Extraer la UID del procesador está normalmente fuera de
ámbito (¿microscopios electrónicos de barrido? ¿FIB?
La otra posibilidad: hacerlo ‘a la Live CD’

39. Bootrom Bootloader Firmware

40. Lo primero que se ejecuta
Sólo lectura
Origen de la cadena de confianza
Si es vulnerado la seguridad del sistema se viene abajo
Y no tiene arreglo…

41. Modelo / 0x24000 usb_control_ Limera1n SHA-1 Image
Exploit Segment msg(0xA1,1) Segment
Overflow Overflow
iPhone 3GS A X
iPhone 3GS B X
iPod 2G X
iPod 4G X X
iPad 1G X X
iPhone 4 X X
Apple TV 2G X X

42. Fallo a nivel de aplicación / kernel
Vulnerabilidad en BootROM

43. Permitir ejecución de aplicaciones no firmadas por Apple
Instala la tienda alternativa de aplicaciones: Cydia
Permite instalar aplicaciones “piratas”
Y otras muchas utilidades por supuesto
Reduce la seguridad del sistema a la de Android

44. Tethered
Untethered

46. BootROM exploit == tethered jailbreak
BootROM exploit + Incomplete Code Signing + Kernel Exploit =
untethered jailbreak
Safari + Kernel exploit = Remote jailbreak
Safari + Kernel + Incomplete Code Signing exploit = remote
untethered jailbreak

47. Aplica a todas las aplicaciones de terceros (y a la mayoría de las
propias)
Impide
Acceder a ficheros de otra aplicación
Acceder a ficheros del sistema
El acceso a la funcionalidad de la API está limitado por los
entitlements.

48. Cada aplicación declara a qué funcionalidad desea tener acceso
No se permite el acceso a la API sin el entitlement
correspondiente
Unido a la firma de código es un mecanismo muy potente

49. Todas las aplicaciones deben estar firmadas
Las de terceros son firmadas con la clave privada que
identifica al desarrollador (firmada por Apple)
La identidad del desarrollador es verificada por Apple
La calidad del código es revisada por Apple
Se permite cargar nuevas entidades de confianza
Para desarrollo
Para empresas
Ciertamente peligroso
Es responsabilidad del kernel verificarlo

50. También en tiempo de ejecución (para cada página)
Mucho más allá de W^X
Una de las razones para que no haya Flash o Java
La cadena de confianza se mantiene hasta el último momento

51. La excepción que confirma la regla (iOS 4.3)
dynamic code signing entitlement
Permite a Safari ejecutar JIT
Requiere una zona de memoria RWX (que también es
marcada como JIT)
Puede permitir exploits más sencillos en Safari

52. Hasta iOS 5.0.1 sólo se comprobaba el entitlement de
dynamic code signing si se pasaba la flag MAP_ANON
¡Cualquiera podía reservar memoria RWX!
Charlie Miller lo descubre y cuela aplicación en App Store
que ejecuta payloads remotas.
EPIC FAIL

53. ¿Realmente es necesario?

54. Apple ha logrado llegar a un nivel de seguridad realmente
impresionante.
A costa de sacrificar la “libertad” del usuario
Apple es el moderno sysadmin
Ha demostrado no abandonar los modelos antiguos
No obstante, seguirán saliendo nuevas vulnerabilidades