Análisis
Tendencia

Se filtra el código del iBoot de iOS 9. ¿Qué es y qué supone para la seguridad de iOS?

Explicamos qué es exactamente el iBoot de iOS (cuyo código se ha filtrado) y qué puede suponer como filtración sin precedentes de código fuente creado por la propia Apple para seguridad de sus dispositivos.

Resumen del artículo

  • En una filtración sin precedentes en la historia de Apple, un usuario ha compartido en la web GitHub el código fuente del componente iBoot de iOS 9.3, que permite iniciar el propio sistema iOS. Una parte clave del arranque seguro del sistema. Explicamos qué es iBoot y sus implicaciones de cara a la seguridad de nuestros dispositivos.

Este jueves 8 de febrero de 2018, se hacía pública una noticia importante: se había filtrado el código fuente del componente iBoot de iOS 9 en la web GitHub. Tras conocerse, Apple ha presentado una demanda por infracción de propiedad y el repositorio ha sido borrado. Pero obviamente ha dado el tiempo suficiente para que este repositorio se clone en el ordenador de más de un analista de seguridad y algún que otro desarrollador curioso.

Apple ha confirmado de forma oficial que esta filtración es real en cuanto a que es un código suyo, aunque declaraciones oficiales desde Cupertino restan importancia al problema.

“Un antiguo código fuente de hace 3 años parece haberse filtrado, pero tal como está diseñada la seguridad de nuestros productos, esta no depende del secreto de nuestro código fuente. Hay muchas capas de protección de hardware y software en nuestros productos, y siempre animamos a nuestro clientes a actualizar a las últimas versiones de nuestro software para que se beneficien de las últimas protecciones”.

Hay que notar que esté código no se ha filtrado ahora. Ya sé filtró en el subreddit de Jailbreak en reddit hace 4 meses, pero pasó inadvertido para la mayoría. Es ahora cuando Apple ha sido consciente de ello y ha ejercitado su derecho de solicitud de borrado como propietaria del código.

Pero la gran pregunta entonces es, ¿qué es iBoot? ¿es grave la filtración? ¿no lo es? ¿puede suponer algo bueno, malo o ambas cosas? Vamos a intentar arrojar luz al respecto.

iBoot, el arranque del kernel

iOS tiene varias fases a la hora de arrancar el sistema cuando encendemos un dispositivo. El primer paso lo establece el procesador de aplicación, que ejecuta un código guardado en la ROM de arranque. Una zona de memoria de solo lectura impresa de fábrica y que es inalterable. En esa zona está grabada la clave pública de Apple de firma digital. Esta clave pública es la parte esencial que permite validar que las partes del arranque han sido creadas por Apple, validando cada paso de la secuencia de inicio.

iOS Hardware Security

La firma digital es un proceso que está compuesto por dos claves: una pública y otra privada. Ambas están generadas por una autoridad certificadora, que en este caso es la propia Apple. Apple no ha confiado en ninguna autoridad de terceros como las muchas que hay para firmar dominios en internet o contenido: han creado su propia autoridad. Eso supone que ellos son los únicos que tienen la clave privada que permite firmar contenido. Cuando firmamos algo con la clave privada, la pública nos permite validar que dicha firma es correcta sin comprometer la seguridad. La clave pública permite validar criptográficamente que el contenido ha sido firmado por la autoridad que emitió ambas claves: pública y privada.

En los dispositivos A9 o anteriores (o Apple Watch con procesador S1) tras este paso se valida la firma de otro componente: el LLB o Low-Level Bootloader que se encarga de cargar y validar el siguiente paso: el iBoot. En procesadores A10 Fusion o posteriores (también S2 o posteriores), este componente LLB no existe y es la propia ROM la que carga y valida la firma de iBoot para sea ejecutado. Si esta firma no se valida y la carga no es válida, el dispositivo entra en modo DFU de forma automática, el conocido modo Device Firmware Upgrade que solicita una actualización de la capa de arranque (LLB o iBoot en adelante) ya que se rechaza el que tiene el sistema en ese momento.


Un iBoot modificado por alguien debería estar firmado por Apple para que la ROM del equipo lo validara y permitiera que se ejecute


Este dato es clave: cualquiera podría coger el código fuente de iBoot filtrado y pretender hacer una versión propia y ponerlo en un dispositivo iOS para conseguir que arranque en condiciones que le permitan saltarse capas de seguridad del sistema. Pero esto no va a funcionar porque dicho iBoot debería estar firmado por Apple para que la ROM del equipo lo validara y permitiera que se ejecute. No se valida la firma y entra una y otra vez en modo DFU dejando inutilizado el equipo hasta conectarse por cable a iTunes e instalar una versión válida desde Apple que sí esté firmada por la compañía.

Trozo de código filtrado de iBoot

Una muestra del código filtrado del componente iBoot

Si nuestro equipo tiene un procesador Secure Enclave, este para arrancar tiene otro proceso similar donde una parte de los componentes de arranque está en una ROM y el software del chip no puede arrancar y no puede validarse, hasta que el software sea reconocido como válido según la impresión de fábrica de la ROM. Y si Secure Enclave no arranca, tampoco arrancará el dispositivo.

Cuando iBoot es validado y ejecutado, este es el encargado de validar los componentes del dispositivo como la memoria, el almacenamiento y que todas las partes del dispositivo funcionen correctamente devolviendo un informe positivo de su funcionamiento. Hecho esto, carga el núcleo Darwin que da soporte a iOS: el kernel. El mismo kernel que usa macOS, watchOS o tvOS. Kernel que ha de tener la firma correcta validada por la clave pública de la ROM. Tras el arranque correcto del kernel, carga el sistema iOS y a partir de ese momento, cada página de memoria que ejecuta código es previamente validada contra la clave pública para verificar que es correcta y permitir su ejecución.

Software Security

Aquí la protección ha llegado a un nivel mayor que la propia de componentes: si cualquier zona de memoria con código quiere ejecutarse, ha de validar previamente la firma correcta de ese código y que está firmado por Apple. Todo el sistema y cualquiera de las apps que provienen del App Store. Código que no esté correctamente firmado por la clave de la autoridad certificadora de Apple, no podrá ejecutarse en iOS y se le negará este privilegio a nivel de núcleo del sistema.

No obstante siempre puede haber agujeros de seguridad que comprometan al sistema, pero cuando estos se parchean hay un método que añade otra capa más de seguridad: la autorización de software del sistema. Cuando nosotros queremos actualizar el software, no podemos si Apple no valida la huella digital de la actualización de forma online. Para que sea válida, el sistema envía a Apple para su validación (en una conexión segura) la firma del nuevo componente iBoot de la actualización, del kernel, de la propia imagen de iOS, el identificador único del dispositivo y una huella aleatoria anti-repetición de petición que valida la conexión (tipo nonce). Si todo esto no es validado por Apple, se niega la actualización.


Si Apple no valida la huella digital de la actualización de forma online, las actualizaciones de sistema no se realizarán


Este proceso es que el impide que un dispositivo con una versión de iOS pueda volver a versiones anteriores que no estén firmadas por Apple, por lo que ellos controlan qué versiones están o no validadas para ser instaladas e impiden instalar a nadie versiones que tuvieran fallos de seguridad que ya han sido arreglados en versiones más nuevas.

Por último, el Secure Enclave es otro elemento importante. Usa memoria cifrada y proporciona todas las operaciones criptográficas al sistema para el cifrado de datos y su propia protección. De hecho, el cifrado sigue funcionando aun cuando algunos componentes como el propio kernel puedan estar comprometidos. Por lo tanto aún cuando pudiera estar afectado por jailbreak el cifrado de datos sigue funcionando, uno de los motivos por los que el jailbreak es cada vez más complicado en iOS.

Analizando las consecuencias

Tras la exposición anterior, queda claro que la filtración de este código fuente en realidad es casi anecdótica, en tanto a que la seguridad de los dispositivos no puede verse comprometida porque hay más pasos que nos aseguran el arranque de los mismos es seguro. Como dice Apple, hay una combinación de factores hardware y software que unidos dan la seguridad del sistema y esta no depende que su código fuente sea o no secreto. Lo es más por razones de derechos de propiedad que porque sea un problema de seguridad. El problema es de Apple y que se haya filtrado algo así.

Además si alguien hiciera una versión nueva o modificada de este iBoot hay que tener en cuenta algo muy importante: pertenece a la versión 9.3. Y actualmente solo el 7% del total de dispositivos iOS activos está en esta versión (en la versión 9). Y otro detalle importante: casi la totalidad de dispositivos con iOS 9 tiene la última versión oficial que apareció, la 9.3.5. Una versión que corregía el error Tridente que permitía hacer jailbreak a un dispositivo atacando el motor webkit del navegador e ignorar la protección de comprobación de firma en las páginas de memoria con código.

Por este motivo es muy difícil que alguien tenga exactamente esa versión 9.3 filtrada que sería la que “podría” intentar suplantar o instalar una vez modificada. Cosa que tampoco podrá hacer porque no validará la firma como ya hemos comentado.

¿Para qué puede servir esta filtración entonces? Para aprender más de iOS, básicamente. Para conocer qué hace, aunque sea una versión antigua. Aunque el código no hubiera cambiado mucho hasta la actual iOS 11.2.5, encontrar una vulnerabilidad a intentar explotar podría ser una de las opciones y/o peligros. Algún investigador podría encontrar un fallo en el código que de la casualidad que Apple no ha detectado y parcheado desde esa versión y permita ser explotado en la última versión de iOS y anteriores. Esa sería una posibilidad plausible.

Criptografía

Otra cosa que puede hacerse, aparte de conocer mejor cómo funciona iOS en su código fuente para validar el propio arranque del sistema, es intentar conseguir que un dispositivo cualquiera con procesador ARM pudiera arrancar iOS aunque no fuera de Apple. Un iBoot que tenga eliminada la comprobación de firma podría servir para permitir emular un dispositivo iOS en otro hardware y conseguir arrancar una versión de iOS 9 en, por ejemplo, un smartphone que originalmente tuviera Android y al que se le hubiera conseguido el conocido acceso root.


Esta filtración podría servir para intentar conseguir que un dispositivo cualquiera con procesador ARM pudiera arrancar iOS aunque no fuera de Apple


Hacer esto supondría un trabajo de investigación nada fácil, pues habría que ir parcheando uno a uno los componentes para, por ejemplo, conectar los drivers de componentes de iOS con los que tuviera ese otro dispositivo. Por lo que habría que crear una capa de emulación que le dijera a iOS que tiene componentes originales pero conectara a través de drivers con los que tiene el hardware que pretende emular el sistema. Algo así como hace una máquina virtual hoy día que usa drivers virtuales para conectar con el hardware real del equipo que corre la emulación. Por lo tanto, no es un trabajo trivial y supone más un trabajo de investigación para aquel que esté interesado que en una amenaza a la seguridad.

Otra cosa que están haciendo algunos investigadores es sacando información sobre versiones reconocidas de chips o sistemas. En este histórico que permanece en este iBoot, parece confirmarse que, por ejemplo, el HomePod es un dispositivo que ha sufrido múltiples re-definiciones y transformaciones desde hace 6 años o que ha existido un Apple TV con un chip A9X que nunca llegó al mercado.

No podemos olvidar que históricamente, fallos en este componente iBoot, han permitido pasar a través de la seguridad de los dispositivos y han permitido bloquear la comprobación de la firma en las páginas de memoria que solicitan ejecución. Lo que conocemos como jailbreak, en este caso en modo untethered que permitía seguir usando este modo que rompe la seguridad del dispositivo aunque este se apagara y volviera a encenderse. El modo más complejo. El otro modo requiere que con cada reinicio se vuelva a explotar la vulnerabilidad que hace jailbreak para volver a dicho estado.

No podemos olvidar que hacer esto a un dispositivo iOS lo deja totalmente expuesto como en el caso comentado de Tridente, donde al conseguir jailbreak de un dispositivo se instalaba un software espía llamado Pegasus, de la firma israelí NSO Group, que convertía el teléfono del atacado en un aparato espía que grababa conversaciones, activaba micrófonos, cámaras, extraída toda la información del mismo y podía seguirlo por la señal GPS con absoluta precisión. Y este software espía se instalaba porque el objetivo era poner en modo jailbreak el dispositivo. Si nosotros hacemos jailbreak voluntariamente, cualquiera con visitar una simple página web podría instalar un software así en nuestros dispositivos.

Por lo tanto es normal que nos preocupe pero como ha dicho Apple, la seguridad de los dispositivos iOS es mucho más que mantener en secreto un código.

Conclusiones

Como podemos ver, dentro de la gravedad que supone la filtración de algo así para Apple, la importancia real para los usuarios es casi mínima o anecdótica. Es cierto que hay una realidad innegable y es que ningún sistema es 100% seguro y que algún investigador con dicho código, podría encontrar algún fallo que Apple aún no hubiera descubierto y parcheado en versiones actuales (suponiendo que dicho código no hubiera cambiado lo suficiente para dejar de tener esa vulnerabilidad por sí mismo).

No obstante, las posibilidades son remotas pero seguro que en Apple ahora están haciendo una buena auditoría del componente iBoot de la actual versión y las anteriores para curarse en salud, aunque haya transmitido tranquilidad a la opinión pública.

¿Qué opináis vosotros de la filtración? Como siempre, podéis usar los comentarios del post para transmitirnos vuestras impresiones o dudas. Un saludo y Good Apple Coding.

Fuente
iOS Security (January 2018)
Etiquetas

Julio César Fernández

Analista, consultor y periodista tecnológico, desarrollador, empresario, productor audiovisual, actor de doblaje e ingeniero de vídeo y audio.

Artículos relacionados

Cerrar
Cerrar