Entendiendo los jailbreak

Cuando se trata de iPhones, el término “jailbreak” (acuñado con la primera versión de iOS antes de que se llamara “iOS”) combina tecnología y el concepto de liberarse de restricciones:

1. Celda: Originalmente se refiere a una prisión o encierro metafórico. En el contexto de los iPhone, representa las restricciones y limitaciones impuestas por Apple a las aplicaciones de terceros que se ejecutan en su sistema operativo iOS. Apple mantiene un control estricto sobre lo que los usuarios pueden y no pueden hacer con sus dispositivos a través de las políticas de su App Store y las medidas de seguridad del sistema. Estas limitaciones incluyen restricciones para instalar aplicaciones de fuentes distintas a la App Store, personalizar la apariencia y funcionalidad del dispositivo y acceder al funcionamiento interno del sistema operativo.
2. Descanso: Implica escapar o liberarse del encierro. En el contexto del jailbreak del iPhone, significa eludir o eludir las restricciones establecidas por el iOS de Apple. Este proceso implica explotar vulnerabilidades en el sistema iOS para obtener acceso de root o privilegios administrativos, lo que permite a los usuarios modificar el dispositivo de formas que Apple normalmente no permite.

Hacer jailbreak a un iPhone le da al usuario final acceso completo de ejecución y escritura. Entonces, cuando lo pones todo junto, "jailbreak" en el contexto de los iPhone significa esencialmente liberarse de las restricciones y limitaciones impuestas por el iOS de Apple, permitiendo a los usuarios obtener más control sobre sus dispositivos y personalizarlos a su gusto. El término refleja la idea de liberar su iPhone de la “cárcel” metafórica de las restricciones de Apple, brindándole más libertad y flexibilidad con su dispositivo.

El deseo de liberar el teléfono ha dado origen a una “comunidad” de Jailbreak formada por hackers, usuarios curiosos y actores de amenaza. Como ocurre con cualquier comunidad que se precie, un grupo de Reddit (r/jailbreak) se ha formado, se han creado (y eliminado) canales de YouTube y la web oscura/gris permite compartir consejos, técnicas y procedimientos de jailbreak entre los miembros de la comunidad. Los jailbreak han sido buscados durante mucho tiempo, y aquellos que descubren, ejecutan y comparten jailbreak ganan fama o notoriedad dentro de la comunidad de jailbreak.

Tenga en cuenta que el jailbreak puede anular las garantías y puede tener implicaciones legales, por lo que no es algo que Apple apoye o aliente oficialmente. También tenga en cuenta que, si bien "liberarse" de la política de Apple anula la garantía de Apple, no es, en sí mismo, ilegal, y muchos en la comunidad de jailbreak consideran que es su derecho o incluso su obligación participar en jailbreak, y no necesariamente con fines maliciosos. propósitos. Si bien la comunidad de hackers, actores de amenazas y bromistas alegres ha formado una comunidad de jailbreak de base dedicada a frustrar los esfuerzos de Apple para bloquear su sistema operativo, una industria con fines de lucro que crackea iOS también ha echado raíces. Empresas como NSO, Cellebrite y Paragon ofrecen sofisticadas técnicas de jailbreak por una tarifa; y los organismos encargados de hacer cumplir la ley, así como los gobiernos de todo el mundo (aunque detestan admitirlo públicamente) casi seguro hacer uso de estos servicios.

En el mundo de los application security, los jailbreaks adquieren una enorme importancia porque cada vez que un actor de amenazas quiere alterar (modificar) una aplicación, una de las primeras cosas que debe hacer es jailbreak a un teléfono para poder asegurarse de que la aplicación modificada se pueda ejecutar. En otras palabras, si bien hacer jailbreak a un teléfono no es ilegal ni poco ético, en la mayoría de los casos es un paso necesario para utilizar una aplicación que ha sido manipulada. Por lo tanto, detectar teléfonos con jailbreak es parte integral de cualquier endurecimiento de la aplicación solution.

Al mismo tiempo, Apple ha invertido constantemente tiempo, dinero, esfuerzo e ingenio para evitar por completo las fugas. Con el tiempo, los jailbreak se han vuelto más complicados y, a menudo, requieren múltiples exploits para liberar completamente el dispositivo debido a las mejoras de seguridad de Apple. La evolución de los esfuerzos de Apple para prevenir jailbreaks es larga y histórica: esencialmente un juego del gato y el ratón que ha estimulado la innovación en la “comunidad” de jailbreak y dentro de la propia Apple.

Si bien la detección de jailbreak es fundamental para garantizar la seguridad de las aplicaciones disponibles públicamente, no todos los jailbreak son iguales; Algunas fugas ni siquiera representan una amenaza importante para la seguridad.

Esta publicación 1) describirá la evolución de los jailbreak de iPhone y 2) explicará qué tipos de jailbreak brindan acceso completo a los recursos del sistema en el sentido original de la palabra, y cuáles son primos menos poderosos del jailbreak tradicional.

La evolución conjunta de iOS y Jailbreaks

Los primeros días: exploits de BootROM

Al principio, el jailbreak se centraba principalmente en la ROM de arranque, un componente fundamental del proceso de arranque del dispositivo iOS. El bootROM es una pieza de software de bajo nivel grabada permanentemente en el hardware, lo que hace que los exploits a este nivel sean particularmente poderosos. Los ataques al bootROM afectan a toda la cadena de confianza: el gestor de arranque, el kernel y, eventualmente, el entorno del usuario. Un exploit de bootROM exitoso podría otorgar un acceso incomparable al dispositivo, permitiendo modificaciones permanentes que podrían sobrevivir a las actualizaciones y reinicios del software. Esta época estuvo marcada por hazañas famosas como Limera1n y PwnageHerramienta, que desbloqueó iPhones en masa, permitiendo instalaciones de firmware personalizadas y modificaciones profundas del sistema.

El cambio a iBoot: vulnerabilidades del gestor de arranque

Mientras Apple fortificaba el bootROM, los atacantes dirigieron sus miras a iBoot, la siguiente etapa en el proceso de arranque de iOS. Los exploits en el gestor de arranque, como redsn0w y Sn0wbreeze, aunque menos permanentes que las vulnerabilidades de bootROM, todavía ofrecían un amplio control sobre el dispositivo. Al comprometer iBoot, los atacantes podrían influir en el entorno del kernel y del usuario, permitiendo una personalización significativa y eludiendo las restricciones del ecosistema de Apple. Estas vulnerabilidades se podían corregir mediante actualizaciones de software, lo que las convertía en un medio de jailbreak menos duradero pero aún eficaz.

La era del kernel: parches y protección

La progresión hacia los exploits del kernel marcó una evolución significativa en las tácticas de jailbreak. Vulnerabilidades a nivel de kernel, explotadas por herramientas como Pangu, Taigy Yalu, permitió la ejecución de código sin firmar y modificaciones profundas del sistema sin alterar el proceso de arranque. Esta era consolidó un enfoque más refinado para el jailbreak, centrándose en la flexibilidad operativa dentro de la arquitectura de seguridad de Apple. Jailbreaks como Electra y Unc0ver ejemplificó aún más esta estrategia, navegando a través de las defensas de Apple para modificar el sistema manteniendo una apariencia de cumplimiento con los protocolos de seguridad de iOS.

Jailbreaks modernos: exploits de precisión y específicos de procesos

2015 fue un punto de inflexión en la historia de las fugas. Apple, habiendo reforzado efectivamente las defensas tanto de bootROM como de iBoot, ya no estaba dispuesta a simplemente reaccionar ante varios exploits en su kernel con parches periódicos y pasó a la ofensiva contra la comunidad de jailbreak con una serie de innovaciones que esencialmente han mantenido el jailbreak. comunidad, así como empresas como Cellebrite y NSO, pisándoles los talones.

En iOS 9 (septiembre de 2015), Apple presentó Kernel Patch Protection (KPP), su actualización de seguridad más crítica. KPP se refiere al código implementado en el kernel para proteger la memoria de ejecución de lectura y de solo lectura en el kernelcache. Lo hace mediante controles aleatorios de vez en cuando.

Desde septiembre de 2015, los jailbreak se han dividido en KPPless y KPP Bypass. KPPLess es una técnica en la que KPP todavía se está ejecutando, lo que significa evadir la verificación de KPP. KPP Bypass desactiva KPP por completo. Antes de KPP, un atacante necesitaba principalmente tener capacidad de escritura en el kernel para parchear el código de seguridad.

En los chips A10, enviados originalmente con iOS 10 en junio de 2016, Apple introdujo KTRR, Región de solo lectura de texto del kernel, que evita la modificación del kernel de iOS en tiempo de ejecución. Los chips más antiguos intentaron hacer esto a través de un programa de monitoreo cargado en EL3, pero el método era inherentemente defectuoso y la comunidad Jailbreak había descubierto durante mucho tiempo formas de evitar el programa de monitoreo. Comenzando con los chips A10, Apple efectivamente trasladó los controles de seguridad al propio hardware, haciendo así más difícil la vida de los Jailbreakers (tanto en la comunidad como en el sector con fines de lucro).

En junio de 2018, con la release de iOS 12, Apple introdujo PAC (Código de autenticación de puntero), su implementación de Autenticación de puntero. PAC utiliza los bits superiores de un puntero para almacenar una firma criptográfica, lo que esencialmente mejora la seguridad al verificar los valores del puntero y el contexto adicional. Se han introducido instrucciones especiales para agregar un código de autenticación a un puntero, verificar el PAC de un puntero autenticado y restaurar el valor del puntero original. Esto le da al sistema una forma de ofrecer garantías criptográficamente sólidas sobre la probabilidad de que ciertos punteros hayan sido manipulados por atacantes, lo que ofrece la posibilidad de mejorar enormemente application security.

Cuando salieron los chips A12 ese mismo año (septiembre de 2018), Apple introdujo la Capa de protección de página (PPL). El objetivo de PPL es evitar que los actores de amenazas modifiquen el código ejecutable de un proceso o sus tablas de páginas, incluso después de obtener privilegios de lectura/escritura/ejecución del kernel. Esta es otra mitigación de exploits que puede dificultar el encadenamiento de ataques. Para ello, aprovecha APRR para crear un "núcleo dentro del núcleo" que protege las tablas de páginas. La única forma que tiene el kernel de modificar las tablas de páginas es ingresar a PPL llamando a una “rutina PPL”, que es análoga a una llamada al sistema de XNU a PPL. Esto limita los puntos de entrada al código del kernel que pueden modificar tablas de páginas solo a esas rutinas PPL. ¿Podemos resumir por qué este cambio A12 fue importante para la comunidad de jailbreak?

La comunidad jailbreak tuvo un período de relativa calma hasta junio de 2021, cuando Apple presentó iOS15. iOS15 le dio a la comunidad de jailbreak urticaria al presentar SSV, el volumen del sistema sellado. Este mecanismo es una característica de seguridad a nivel de kernel que sella el volumen con una firma criptográfica conocida sólo por Apple, que rechaza cualquier código que intente modificar el contenido del sistema, lo que luego evitará cualquier cambio no autorizado realizado antes de que arranque iOS. Este método obligó a la comunidad de jailbreak a cambiar toda la estructura de las arquitecturas de jailbreak anteriores. Desde entonces, los jailbreak se han dividido en desarraigados y enraizados.

Los jailbreaks sin raíz mantienen todos los archivos y modificaciones fuera de la raíz, generalmente en / var y /privado/prearranque. Los jailbreaks rootful utilizan montajes vinculantes que crean efectivamente una raíz "falsa", que luego actúa como la real rootfs, pero requiere un exploit de bootROM.

Dado que el jailbreak se logró sin parchear el código del kernel, los efectos ahora no son para todo el sistema sino más por proceso. Esto significa que en lugar de hacer jailbreak al sistema operativo, ahora el jailbreak se realiza por proceso.

Podemos verlo de esta manera: en la era de los jailbreaks “premodernos”, bastaba con parchear el kernel, lo que provocaba que todo el sistema se viera afectado. Ahora, donde hay muchos jailbreak (Quimera, checkra1n) están manipulando las estructuras de datos del kernel en lugar de parchear directamente el código del kernel, la manipulación se produce por proceso. Este estado complica la detección del jailbreak. Si bien la mayor parte de la integridad del sistema parece intacta, se implementa la lógica para determinar si un proceso ha sido liberado o no. Es decir, a menos que se pretenda, el proceso permanece encarcelado. Esto, a su vez, significa que incluso si este tipo de jailbreak otorga acceso a recursos a los que Apple no desea que tenga acceso la aplicación, no brinda acceso a todos los procesos, lo cual es importante porque significa que el jailbreak en sí es no necesariamente peligroso para todas (o incluso para alguna) de las aplicaciones del teléfono.

Esta nueva forma de hacer jailbreak es técnicamente complicada, por decir lo menos. Requiere ganchos en lanzamiento donde se invocan todos los procesos, ganchos ejecutivos e inserción de todos los nuevos procesos jailbreak inmediatamente después de la creación del proceso. Y desafortunadamente (desde la perspectiva de la comunidad de jailbreak), toda esta creatividad técnica conduce a menos "libertades".

Implicaciones para Application Security Ingenieros y DevSecOps Managers

Entonces, ¿qué significa todo esto para usted, el application security ¿ingeniero? Bueno, uno de los mejores mecanismos de defensa que te ofrecemos es “Autoprotección de aplicaciones en tiempo de ejecución” o RASP. RASP permite a nuestros clientes programar sus aplicaciones para que reaccionen automáticamente cuando se activen guardias y protecciones. Algunos clientes han utilizado RASP durante mucho tiempo para tomar medidas cuando se activan los jailbreaks.

Pero si la extensa historia del juego del gato y el ratón entre Apple y la comunidad Jailbreak nos ha enseñado algo, es que no todos los jailbreak son iguales. Algunos requieren "conexión" a una computadora, lo que ofrece poco valor funcional a los usuarios curiosos o a cualquiera más allá de los actores de amenazas y académicos más decididos. Existen varios tipos, como los “semi-atados”, los desarraigados y los “arraigados”. Podría decirse que algunos no son dignos del apodo de "jailbreak" debido a su alcance limitado, y se parecen más a experimentos de piratas informáticos que a un "producto" funcional. Si bien los continuos esfuerzos de Apple para disuadir los jailbreak han obligado a la innovación en la comunidad de jailbreak, también han hecho que los jailbreak modernos sean menos poderosos con el tiempo. En otras palabras, la búsqueda incesante de Apple para arrinconar a la comunidad de jailbreak ha hecho que el término "jailbreak" parezca casi demasiado grandioso para referirse a las ventajas que estos hacks están logrando conferir, incluso cuando la perspicacia técnica necesaria para lograr estas pequeñas hazañas ha disminuido. crecido.

Por este motivo, aconsejamos que las empresas que crean aplicaciones para sus clientes utilicen un bisturí, en lugar de un martillo, para reaccionar ante los signos de jailbreak. Por ejemplo, simplemente registrar que se produjo un jailbreak podría ser suficiente y puede que ya no sea necesario programar una reacción exclusivamente ante un jailbreak. Si considera necesario programar una reacción, considere qué otras protecciones se activan en combinación con el jailbreak al diseñar su estrategia de autoprotección de aplicaciones en tiempo de ejecución (RASP). El jailbreak es un facilitador. Es importante detectar los ataques que se habilitan MEDIANTE el jailbreak y no depender únicamente de la detección del jailbreak para detener a los atacantes.

 

Para leer más sobre cómo Digital.ai Application Security puedes proteger (detectando jailbreaks entre muchos otros trucos) tus aplicaciones iOS, descarga nuestro Producto breve.