Exploit para iBoot en iPhone 4S con iOS 7.0.4

Desde hace una semanas, INCIDE cuenta con un nuevo pentester senior, José Selvi, valenciano y mejor persona. A raíz de la noticia que ha sacudido esta semana las redes sociales sobre el posible Jailbreak definitivo para cualquier dispositivo con procesador A5 de Appel, no ha podido esperar más para ver qué hay detrás de este demoledor anuncio. Os dejamos con su post. ¡Bienvenido Selvi!

   Hace unos pocos días pudimos ver en Twitter como un conocido Jailbreaker, iH8sn0w, comentaba haber encontrado una vulnerabilidad en los dispositivos con procesador A5 de Apple (iPhone 4S, por ejemplo).

   

   Según sus propias palabras, la vulnerabilidad se encontraría en el iBoot, una de las partes del arranque de los dispositivos de Apple que se ejecuta previamente a la ejecución del kernel del sistema operativo iOS.

   El arranque de un dispositivo iOS se realiza mediante la llamada "Secure Boot Chain", en la que cada etapa realiza sus acciones pertinentes y comprueba la firma de la siguiente etapa antes de otorgarle el control.

   La primera etapa de todas, el bootrom, se escribe en el dispositivo en el momento del ensamblaje, y no puede ser cambiada ni actualizada en toda la vida del mismo. Las vulnerabilidades en alguno de estos elementos del arranque, o en el propio kernel, permitirían evadir esta protección de la firma, y por lo tanto arrancar versiones modificadas del kernel, que es en lo que consiste un Jailbreak.

   No obstante, a pesar de que el propio iH8sn0w comenta que, a partir de ahora, los dispositivos A5 son "Jailbreakeables" de por vida, a priori únicamente las vulnerabilidades en el bootrom serían de este tipo, ya que al estar embebido en el propio hardware es el único elemento que no puede ser actualizado por Apple. El iBoot, elemento en el que parece existir la vulnerabilidad, se encuentra dentro de la imagen del sistema operativo iOS que descargamos en el momento de realizar una actualización, dentro del fichero IPSW, por lo que Apple podría corregir la vulnerabilidad en próximas releases.

   Dado que los detalles de la vulnerabilidad aún no han sido publicados y todavía no podemos ponernos a jugar con ella, vamos a descargar el IPSW de una versión vulnerable y a intentar extraer la imagen del iBoot. Para ello lo primero que vamos a hacer es descargar la imagen con la que vamos a trabajar, por ejemplo la versión 7.0.4 para iPhone 4S, de la conocida web ipswdownloader.com

   El fichero IPSW no es más que un ZIP al que se le ha cambiado la extensión, pero sus ficheros se encuentran cifrados mediante el algoritmo AES, empleando claves a priori desconocidas. Veamoslo:

$ file iPhone4,1_7.0.4_11B554a_Restore.ipsw

iPhone4,1_7.0.4_11B554a_Restore.ipsw: Zip archive data, at least v2.0 to extract

$ unzip iPhone4,1_7.0.4_11B554a_Restore.ipsw

Archive:  iPhone4,1_7.0.4_11B554a_Restore.ipsw

inflating: 058-1077-002.dmg       

inflating: 058-1108-002.dmg       

inflating: 058-1124-002.dmg       

inflating: BuildManifest.plist    

creating: Firmware/

creating: Firmware/all_flash/

creating: Firmware/all_flash/all_flash.n94ap.production/ 

inflating:

Firmware/all_flash/all_flash.n94ap.production/applelogo@2x~iphone.s5l8940x.img3 

inflating:

Firmware/all_flash/all_flash.n94ap.production/batterycharging0@2x~iphone.s5l8940x.img3 

inflating:

Firmware/all_flash/all_flash.n94ap.production/batterycharging1@2x~iphone.s5l8940x.img3 

inflating:

Firmware/all_flash/all_flash.n94ap.production/batteryfull@2x~iphone.s5l8940x.img3 

inflating:

Firmware/all_flash/all_flash.n94ap.production/batterylow0@2x~iphone.s5l8940x.img3 

inflating:

Firmware/all_flash/all_flash.n94ap.production/batterylow1@2x~iphone.s5l8940x.img3 

inflating:

Firmware/all_flash/all_flash.n94ap.production/DeviceTree.n94ap.img3 

inflating:

Firmware/all_flash/all_flash.n94ap.production/glyphplugin@2x~iphone-30pin.s5l8940x.img3 

inflating:

Firmware/all_flash/all_flash.n94ap.production/iBoot.n94ap.RELEASE.img3 

inflating:

Firmware/all_flash/all_flash.n94ap.production/LLB.n94ap.RELEASE.img3 

inflating: Firmware/all_flash/all_flash.n94ap.production/manifest 

inflating:

Firmware/all_flash/all_flash.n94ap.production/recoverymode@2x~iphone-30pin.s5l8940x.img3 

creating: Firmware/dfu/

inflating: Firmware/dfu/iBEC.n94ap.RELEASE.dfu 

inflating: Firmware/dfu/iBSS.n94ap.RELEASE.dfu 

inflating: Firmware/Trek-5.0.02.Release.bbfw 

inflating: Firmware/Trek-5.0.02.Release.plist 

creating: Firmware/usr/

creating: Firmware/usr/local/

creating: Firmware/usr/local/standalone/

inflating: kernelcache.release.n94 

inflating: Restore.plist

$ srch_strings Firmware/dfu/iBSS.n94ap.RELEASE.dfu | head -10

3gmI

ssbiEPYT

ssbi

ATAD

jnZf

UZ^_

[...]

   Como podemos ver, el formato de los ficheros no es reconocido, debido a que su contenido está cifrado. A pesar de que la clave de cifrado no se publica por Apple, los Jailbreakers las obtienen como parte de su trabajo de investigación, y van publicando aquellas que identifican, por ejemplo, en el iPhoneWiki.

   En este caso, el propio iH8sn0w ha colgado en su Twitter una de las claves que ha encontrado durante su trabajo: 

   Con esta información ya podemos extraer las imágenes del IPSW que acabamos de descargar. Imagino que podríamos hacerlo a mano con openssl, pero yo he preferido usar una versión modificada del script "kernel_patcher.py" de la suite iphone-dataprotection (que podéis descargar de AQUI). 

   Básicamente, en script es el mismo que el original pero eliminando las acciones de parcheo del kernel, dejando las imágenes tal cual se encuentran dentro del IPSW. Veamos si funciona:

$ ./ipsw_decrypt.py --iv 3a0fc879691a5a359973792bcd367277 --key

371e3aea9121d90b8106228bf2b5ee4c638a0b4837fefbd87a3c0aca646e5996

--binary iBSS iPhone4,1_7.0.4_11B554a_Restore.ipsw

Decrypting iBSS.n94ap.RELEASE.dfu

Decrypted kernel written to iBSS.n94ap.RELEASE.dfu.decrypt

   Parece que todo ha funcionado bien, así que solo nos queda ver si efectivamente lo que hay dentro tiene pinta de iBSS:

$ srch_strings iBSS.n94ap.RELEASE.dfu.decrypt

iBSS for n94ap, Copyright 2013, Apple Inc.

RELEASE

iBoot-1940.3.5

[...]

   Pues... todo apunta a que sí. Lamentablemente cada imagen está cifrada con una clave diferente y no podemos utilizar esta misma clave para descifrar el iBoot y ponernos a mirar, así que por el momento habrá que esperar a ver si son publicados más detalles sobre la vulnerabilidad. 

Jose Selvi es Pentester Senior en INCIDE.

¿Quieres leer más artículos de José Selvi? Visita su blog: www.pentester.es

Sobre el cifrado en iOS

En este artículo repasamos la irrupción del iPhone y iPad en el entorno empresarial, así como la seguridad que ofrece el cifrado de estos dispositivos.

Revolución Apple

Es de sobra conocido el éxito que Apple ha tenido en los últimos años en el sector de los smartphones (iPhone), y posteriormente de las tabletas (iPad).


Apple sabe lo que es entrar en un sector dominado por varios competidores, y reventarlo con productos que arrasan aún cuando se les pueda criticar la falta de algunas características importantes, ya sean de hardware o de software. Desde que irrumpió en el mercado de la música en 2001, la empresa ha vendido más de 300 millones de iPods, por no hablar de miles de millones de canciones en la iTunes Store.


Pasaron los años y la compañía de la manzana siguió haciendo las delicias de propios y extraños con sus ordenadores y sus reproductores. Después de años de rumores, en 2007 finalmente Steve Jobs presentó lo que llamó "producto revolucionario": el consabido iPhone, un dispositivo personal de comunicaciones, un auténtico ordenador en el bolsillo, siempre conectado, en que la función de hacer llamadas parecía lo de menos.

La primera versión del dispositivo fue criticada, posiblemente con razón, por sus carencias de hardware (había dispositivos en el mercado con mayor capacidad de almacenamiento, mejor cámara...) y sobre todo de software: en iOS 1.0 (entonces llamado iPhone OS) no existía la App Store ni la posibilidad de instalar aplicaciones de ninguna clase, el dispositivo se limitaba a las aplicaciones instaladas de base: correo, calendario, notas, poco más. Eso sí, Safari ofrecía una experiencia de navegación web nunca vista hasta entonces en un teléfono, PDA, o similar. La única puerta a expandir de algún modo la funcionalidad del dispositivo era a través de "aplicaciones web", que evidentemente sólo funcionaban mientras el dispositivo tuviese una conexión de datos.


Un año después, el ecosistema de software alrededor de iOS comenzaba a existir: iPhone OS 2.0 trajo consigo la App Store y la posibilidad de que cualquier desarrollador pudiese distribuir sus aplicaciones (de pago o no). Al mismo tiempo Apple lanzaba el iPhone 3G y daba un salto hacia Europa y otros países. El juego empezaba a ponerse interesante.




El sector corporativo


En 2009 Apple lanzaba el iPhone 3GS, que manteniendo el diseño exterior encerraba un hardware totalmente renovado que llevaba el terminal a un nivel bastante serio. Era, digamos, una puesta al día necesaria en cuanto a especificaciones para ponerse al nivel de la competencia, manteniendo el mismo diseño. Llegaba iOS 3.0.


Ése fue probablemente el salto definitivo del iPhone al sector empresarial. Las BlackBerry que tanto habían dominado ese sector tiempo atrás, ya empezaban a perder cuota de mercado a pasos agigantados, en pos de nuevos y flamantes smartphones. Y de éstos, un pedazo cada vez más grande correspondía a Apple. Hay que comentar que al mismo tiempo, Android experimentó también un enorme ascenso debido a su adopción por multitud de fabricantes.


En sus 24 meses de vida (junio 2007 - junio 2009), el iPhone había demostrado que estaba a la altura, que podía ser un dispositivo de primera clase. El modelo 3GS añadió una característica (sostenida desde la versión 3 de iOS, liberado al mismo tiempo) que, si bien quizá no fue la más esperada, supuso un factor importante para el salto al sector corporativo: cifrado por hardware. Eso y algún detalle más, como la integración con Exchange, hizo que de repente el dispositivo tuviese cabida en infinidad de organizaciones, más o menos grandes, en cuyas políticas de seguridad no había encajado hasta entonces. Y evidentemente, cuando en 2010 llegó el iPad cuajó igual de bien en esos entornos corporativos.

Cifrado: algo que tienes, algo que sabes...

Lamentablemente (o no), es habitual que cualquier sistema de protección más o menos popular sea reventado por la comunidad hacker a los días de su lanzamiento. De esto saben mucho grandes compañías como Microsoft, Sony, y en general las distribuidoras de contenido audiovisual.


Sucede además que, si lo planteamos con un poco de lógica, un sistema de cifrado gestionado por el propio dispositivo implica que, necesariamente, las claves residen dentro del mismo. Y que, igual que el sistema operativo puede acceder a ellas para cifrar y descifrar los datos a su antojo, lo mismo puede hacer cualquier hijo de vecino con un poco de pericia que pase por allí (con bastante pericia, la verdad sea dicha). Incluso si suponemos que el cifrado puede estar apoyado en la contraseña que el usuario define sobre el dispositivo, la inmensa mayoría de dichas contraseñas son numéricas de 4 dígitos, lo cual es efectivo cuando el dispositivo está encendido y un humano debe teclear cada combinación (y además el dispositivo fuerza una espera cada vez mayor entre intentos fallidos, y/o permite un número máximo de intentos). Pero si se puede aplicar fuerza bruta, el espectro de claves es sencillamente ridículo.

En este sentido, una lectura muy interesante es iPhone data protection in depth. Sus autores, Jean-Baptiste Bédrune y Jean Sigwald, han desarrollado una serie de herramientas que permiten precisamente eso: hacer un volcado de un dispositivo iOS (incluso iOS versión 5), extraer las claves de cifrado, y descifrar la imagen (siempre que el código sea el simple: numérico de 4 dígitos). Como curiosidad, llama la atención que el proceso de romper la clave por fuerza bruta se debe realizar en el propio dispositivo, con lo que probar las 10.000 combinaciones posibles lleva algunos minutos (pero es cuestión de eso, minutos, menos de una hora).


Entre las limitaciones de la herramienta, posiblemente la más importante sea que necesita tener acceso al dispositivo en sí para extraer las claves de cifrado (no basta con tener una imagen forense del mismo). También cabe comentar que dichas claves cambian en cada reinstalación del dispositivo, por lo que si tenemos una imagen anterior, y acceso al dispositivo original pero éste ha sido reinstalado, no podremos extraer del mismo las claves necesarias para descifrar aquella imagen.




¿Qué podemos hacer?


Si queremos que los datos de nuestros dispositivos iOS estén debidamente protegidos, hay algunos pasos que nos ayudarán.


Probablemente es obvio decirlo a estas alturas, pero ahí va: es conveniente utilizar códigos de desbloqueo complejos (esto es, alfanuméricos de más de 4 dígitos). Teniendo en cuenta que las herramientas comentadas realizan el ataque de fuerza bruta dentro del propio dispositivo (esto es, dependen de su potencia computacional), podemos tener una cierta seguridad sin necesidad de utilizar claves extremadamente complejas.


De manera reactiva, si perdemos un dispositivo iOS, podremos hacer un borrado remoto siempre que el dispositivo: (a) tenga activada la función Buscar mi iPhone; o (b) tenga configurada una cuenta de Exchange. Nótese que esto incluye los servicios de Google Apps, muy extendidos en grandes organizaciones, ya que en dispositivos iOS se configuran como una cuenta de Exchange, y la interfaz de administración de Google Apps ofrece esa funcionalidad (en Organization & Users, tras pinchar en el usuario correspondiente, hay una lista de los Mobile Devices asociados y para cada uno de ellos la opción de Wipe this device.


Más adelante veremos qué se puede hacer cuando no podemos romper el cifrado (esto es, cuando el código de desbloqueo es alfanumérico).