Operation Triangulation: lo que se obtiene al atacar los iPhone de los investigadores

 (securelist.com)
1 puntos por GN⁺ 2023-12-28 | 1 comentarios | Compartir por WhatsApp
  • Investigadores de Kaspersky revelaron en 37C3 la cadena de ataque de iPhone 0-click por iMessage de Operation Triangulation, y la consideran la cadena más sofisticada que han visto hasta ahora
  • El ataque fue diseñado para funcionar hasta iOS 16.2 y encadena 4 zero-days para lograr ejecución remota de código, escalamiento de privilegios, bypass de PPL y ejecución en la etapa de Safari
  • El misterio central es CVE-2023-38606, la parte mitigada en la que los atacantes eluden la protección de memoria del kernel basada en hardware usando registros MMIO desconocidos del SoC Apple A12–A16 Bionic
  • El análisis indica que esos registros parecen estar relacionados con el coprocesador auxiliar de la GPU, y algunos no están referenciados en DeviceTree ni en el firmware, por lo que no está claro cómo los atacantes supieron usarlos
  • En la actualización del 9 de enero de 2024, los valores que parecían un “hash personalizado” se identificaron como ECC basado en código Hamming, lo que refuerza la posibilidad de que esta función de depuración acceda directamente a la caché y no a la memoria

Cadena de ataque revelada

  • El 27 de diciembre de 2023, en la presentación de 37C3, se dieron a conocer los resultados del análisis de largo plazo de Operation Triangulation
  • En esa presentación se revelaron por primera vez los detalles de los exploits y vulnerabilidades usados en el ataque
  • Los investigadores ya habían descubierto y reportado más de 30 zero-days explotados en el mundo real en productos de Adobe, Apple, Google y Microsoft, pero consideran que esta cadena de ataque está entre las más sofisticadas de todas

De iMessage 0-click a la carga del spyware

  • Los atacantes envían un archivo adjunto malicioso de iMessage, y la aplicación lo procesa sin mostrárselo al usuario
  • El adjunto explota CVE-2023-41990, una vulnerabilidad de ejecución remota de código en el comando de fuente TrueType ADJUST no documentado y exclusivo de Apple
    • Este comando existía desde principios de los años 90 y fue eliminado con el parche
  • Después sigue una secuencia de varias etapas escritas con return/jump oriented programming y el lenguaje de consultas NSExpression/NSPredicate
    • Se parchea el entorno de JavaScriptCore para ejecutar un exploit de escalamiento de privilegios escrito en JavaScript
  • El exploit en JavaScript fue reducido de tamaño y ofuscado para dificultar completamente su lectura, pero tiene unas 11,000 líneas
    • La mayor parte se usa para analizar y manipular JavaScriptCore y la memoria del kernel
  • Se abusa de DollarVM($vm), una función de depuración de JavaScriptCore, para manipular memoria de JavaScriptCore desde el script y ejecutar funciones nativas de la API
  • Fue diseñado para soportar tanto iPhone antiguos como recientes, e incluye también bypass de PAC para explotar los modelos más nuevos

Acceso a memoria del kernel y bypass de PPL

  • El exploit usa CVE-2023-32434, una vulnerabilidad de desbordamiento entero en mach_make_memory_entry y vm_map, syscalls de mapeo de memoria de XNU
    • Obtiene acceso de lectura/escritura a toda la memoria física del dispositivo desde nivel de usuario
  • Luego elude la Page Protection Layer (PPL) mediante registros MMIO de hardware
  • Tras explotar todas las vulnerabilidades, el exploit en JavaScript podía ejecutar acciones arbitrarias en el dispositivo
    • Los atacantes ejecutan el proceso IMAgent e inyectan un payload para borrar los rastros del exploit
    • Ejecutan el proceso Safari en modo invisible y lo pasan a una página web de la siguiente etapa
  • La página web verifica a la víctima y, si pasa las condiciones, entrega el exploit de Safari
  • El exploit de Safari usa CVE-2023-32435 para ejecutar shellcode
  • El shellcode ejecuta otro exploit de kernel en formato de archivo objeto Mach
    • Ese exploit también usa CVE-2023-32434 y CVE-2023-38606
    • Aunque es mayormente distinto del exploit de kernel en JavaScript, comparte parte del código relacionado con la explotación de las mismas vulnerabilidades
  • Finalmente obtiene privilegios de root y ejecuta otras etapas para cargar el spyware

El misterio de hardware de CVE-2023-38606

  • Los modelos recientes de iPhone cuentan con una protección basada en hardware para resguardar áreas sensibles de memoria del kernel
  • Esta protección está diseñada para impedir que un atacante tome control total del dispositivo, incluso si logra leer y escribir memoria del kernel
  • Los atacantes de Operation Triangulation usaron otra función de hardware del SoC diseñado por Apple para eludir esa protección
  • El comportamiento identificado es el siguiente
    • Se escriben datos, dirección de destino y hash de los datos en registros de hardware desconocidos del chip
    • Esos registros parecen no ser usados por el firmware
    • Como resultado, se puede escribir información en direcciones físicas específicas eludiendo la protección de memoria basada en hardware
  • Es posible que esta función fuera una característica de depuración para ingenieros de Apple o pruebas de fábrica, o que haya quedado incluida por error
  • Como se trata de una función no utilizada por el firmware, no se ha podido determinar cómo los atacantes aprendieron a usarla

Análisis de MMIO y DeviceTree

  • Los periféricos del SoC pueden ofrecer registros especiales de hardware para que la CPU controle el dispositivo
  • Esos registros se mapean en memoria accesible por la CPU y se conocen como memory-mapped I/O (MMIO)
  • En productos Apple, los rangos de direcciones MMIO de los periféricos se almacenan en formato DeviceTree
    • Los archivos DeviceTree pueden extraerse del firmware
    • Su contenido puede verse con la utilidad dt
  • La mayor parte del MMIO usado por los atacantes para el bypass de PPL no pertenecía a ningún rango MMIO definido en DeviceTree
  • El exploit apunta a los SoC Apple A12–A16 Bionic y usa los siguientes bloques MMIO desconocidos
    • 0x206040000
    • 0x206140000
    • 0x206150000
  • No se encontraron referencias a esas direcciones en DeviceTree de múltiples dispositivos y firmwares, ni en código fuente público, imágenes de kernel, extensiones de kernel, iBoot o firmware de coprocesadores auxiliares

Relación con el coprocesador auxiliar de la GPU

  • Al revisar el MMIO conocido alrededor, se vio que las direcciones desconocidas estaban cerca de gfx-asc, es decir, el coprocesador auxiliar de la GPU
  • gfx-asc tiene dos rangos MMIO
    • 0x206400000–0x20646C000
    • 0x206050000–0x206050008
  • Las direcciones desconocidas realmente usadas por el exploit son las siguientes
    • 0x206040000
    • 0x206140008
    • 0x206140108
    • 0x206150020
    • 0x206150040
    • 0x206150048
  • La mayoría se ubica entre las dos áreas gfx-asc, y la restante está cerca del inicio de la primera área gfx-asc
  • Se considera muy probable que estos registros pertenezcan al coprocesador auxiliar de la GPU
  • En el proceso de inicialización del exploit también se encontró código que manipula registros del administrador de energía GFX en direcciones distintas según el SoC
    • Con la utilidad pmgr se confirmó que esas direcciones corresponden a registros GFX dentro del rango MMIO del administrador de energía
  • Al acceder a los registros de la región desconocida, el coprocesador auxiliar de la GPU provocaba un panic con el mensaje “GFX SERROR Exception”
    • Ese resultado también respalda la conclusión de que los registros pertenecen al coprocesador auxiliar de la GPU

CoreSight y la región UTT propia de Apple

  • El registro 0x206040000 solo se usa en las etapas de inicialización y finalización del exploit
    • Se configura primero durante la inicialización y se procesa al final durante el cierre
  • Se analiza que este registro sirve para activar y desactivar la función de hardware o controlar interrupciones
  • El comportamiento del exploit coincide con la función ml_dbgwrap_halt_cpu del archivo dbgwrap.c del código fuente de XNU
  • dbgwrap.c contiene código que maneja los registros de depuración MMIO ARM CoreSight de la CPU principal
  • El código fuente de XNU menciona cuatro regiones MMIO relacionadas con CoreSight: ED, CTI, PMU y UTT
    • Cada región ocupa 0x10000 bytes
    • Las cuatro regiones son contiguas entre sí
  • Según el código fuente, la región UTT no viene de ARM, sino que es una función propia de Apple añadida por conveniencia
  • Al escribir ARM_DBG_LOCK_ACCESS_KEY en esa ubicación se confirmó que 0x206000000–0x206050000 es el bloque de registros de depuración MMIO CoreSight del coprocesador auxiliar de la GPU
  • Cada núcleo de la CPU principal también tiene su propio bloque de registros de depuración MMIO CoreSight, pero a diferencia del coprocesador auxiliar de la GPU, sus direcciones sí pueden encontrarse en DeviceTree
  • El autor del exploit también sabía cómo usar la región UTT propia de Apple para reanudar una CPU detenida
    • Ese código no está incluido en el código fuente de XNU

Función no identificada que actúa como DMA

  • Los registros 0x206140008 y 0x206140108 controlan la activación, desactivación y ejecución de la función de hardware usada por el exploit
  • 0x206150020 solo se usa en los SoC Apple A15/A16 Bionic
    • Se establece en 1 durante la inicialización y se restaura a su valor original al finalizar
  • 0x206150040 se usa para almacenar banderas y la mitad inferior de la dirección física de destino
  • 0x206150048 se usa para almacenar juntos los datos a escribir, la mitad superior de la dirección física de destino, el hash de los datos y otro valor adicional
    • La función de hardware escribe datos en bloques alineados de 0x40 bytes
    • El registro 0x206150048 requiere 9 escrituras consecutivas
  • Si todo el procedimiento se realiza correctamente, el hardware ejecuta una operación tipo DMA y escribe los datos en la ubicación solicitada
  • El exploit usa esta función para el bypass de PPL, principalmente parchando entradas de la tabla de páginas
  • También puede usarse para parchear datos del segmento protegido __PPLDATA
  • No se usó esta función para parchear código del kernel
    • Durante una prueba, al sobrescribir una instrucción del kernel en el segmento __TEXT_EXEC, se obtuvo un panic de “Undefined Kernel Instruction” con la dirección y el valor esperados
    • En otros intentos se produjo un panic de AMCC

Hash, ECC y posible acceso a caché

  • En el análisis inicial parecía que esta función requería un hash personalizado
    • El hash se calculaba usando una tabla predefinida sbox
    • Se buscó esa tabla en una gran colección de binarios, pero no apareció
  • El hash parecía ser de 20 bits, es decir, el cálculo de un valor de 10 bits dos veces
  • Si un atacante no conociera el método de cálculo y su uso, esta estructura se parece mucho a security by obscurity
  • En la actualización del 9 de enero de 2024, Hector Martin confirmó que ese valor no era un simple hash personalizado, sino un código de corrección de errores (ECC)
    • Más precisamente, un código Hamming con una tabla de búsqueda personalizada
  • Este hallazgo da una pista para entender el propósito original de la función de hardware no identificada
    • Al principio parecía una función de depuración con acceso directo a memoria y un hash “de relleno”
    • Pero por el uso de ECC y el comportamiento inestable observado al parchear código del kernel, gana fuerza la hipótesis de que esta función accede directamente a la caché

Experimentos en M1 y mitigación en iOS 16.6

  • Se confirmó que esta función de hardware desconocida también existe en el chip M1 de las Mac
  • Con la función trace_range de la herramienta m1n1 se rastrearon accesos MMIO en el rango 0x206110000–0x206400000
    • No se reportaron rastros de que macOS use estos registros
  • En iOS 16.6, Apple mitigó el exploit agregando los rangos MMIO usados a pmap-io-ranges de DeviceTree
    • Los rangos añadidos fueron 0x206000000–0x206050000 y 0x206110000–0x206400000
  • XNU usa la información de pmap-io-ranges para decidir si permite mapear ciertas direcciones físicas
  • Normalmente, las entradas de pmap-io-ranges tienen nombres de etiqueta significativos, como PCIe, DART o DAPF, pero los nombres de las regiones relacionadas con esta vulnerabilidad destacaban por su forma inusual frente a las demás entradas

Preguntas pendientes e implicaciones de seguridad

  • No se ha podido determinar cómo los atacantes aprendieron a usar esta función de hardware desconocida
  • Tampoco está claro cuál era su propósito original
    • Ni siquiera se sabe si es una función desarrollada por Apple o un componente de terceros, como ARM CoreSight
  • Incluso después de la actualización, el misterio sigue abierto
    • Los atacantes podrían obtener por fuerza bruta los valores de la tabla de búsqueda personalizada solo mediante experimentación
    • Pero además tendrían que conocer la existencia de una potente función de depuración de caché, el uso de código Hamming, la ubicación y propósito de los registros MMIO relacionados, y el orden de interacción entre ellos
  • Incluso si existe protección basada en hardware, la presencia de funciones de hardware capaces de eludirla puede volverla inútil frente a atacantes sofisticados
  • La seguridad de hardware es mucho más difícil de hacer ingeniería inversa que el software, pero los sistemas que dependen de “security through obscurity” dejan de ser seguros en cuanto se revela el secreto

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-12-28
Comentarios de Hacker News

  • Ya subieron también el video de la presentación: https://www.youtube.com/watch?v=7VWNUUldBEE

  • Es algo bastante sorprendente. El abuso de MMIO significa una de dos: o los atacantes tenían una capacidad de investigación realmente descomunal, o hackearon a Apple para obtener documentación interna del hardware; lo segundo parece más plausible.
    Hasta que apareció la S-box de la función hash personalizada, pensé que quizá un equipo de investigación grande de nivel NSA podría lograrlo, pero a partir de ahí parece que Apple sabía que esa función era riesgosa, la ocultó deliberadamente y, fuera lo que fuera, además la protegió con una especie de función débil de firma digital.
    Como señala la entrada del blog, aparte de desarmar y hacer ingeniería inversa de todo el silicio, no hay una forma clara de encontrar el “golpe mágico” correcto para activar esta función. En este nodo de proceso eso es, en la práctica, irrealista, así que queda la opción de que hackearon a un desarrollador y robaron documentación interna.
    El uso de una cadena larga de zero-days costosos para abrir un Safari invisible y luego volver a hackear el dispositivo cargando una página web mediante una cadena de exploits totalmente distinta también huele a una organización enorme con silos internos graves.
    Considerando que los investigadores son rusos de Kaspersky, es muy probable que esto sea obra de la NSA, o quizá de GCHQ.
    Otra parte interesante de la charla es que el malware puede activar el seguimiento publicitario y también detectar el hosting de iPhone en la nube que suelen usar los investigadores de seguridad. La plataforma de malware para iOS/macOS parece haber sido desarrollada durante más de 10 años, e incluso ejecuta aprendizaje automático en el dispositivo para hacer reconocimiento de objetos y OCR sin subir los bytes de las fotos, subiendo solo las etiquetas generadas. Le metieron muchísimo esfuerzo, pero al final no fue suficiente frente a estudiantes rusos brillantes.
    Aun así, no estoy totalmente de acuerdo con lo que dijo el presentador de que “la seguridad por oscuridad no funciona”. Esta plataforma estuvo en el mundo real durante 10 años, y nadie sabe cuánto tiempo explotaron esa “función” de hardware oculta. Si esa función de hardware hubiera estado documentada públicamente, la habrían encontrado mucho, mucho antes.

    • La parte de “la habrían encontrado mucho antes si la función de hardware hubiera estado documentada públicamente” significa que, según el principio de Kerckhoffs, desde el inicio debió haber estado documentada públicamente, y cualquiera que hubiera visto la documentación antes del lanzamiento debería haber dicho “esto no puede salir así, hay que quitar esta función”.
    • También hay un script de IoC que puede escanear respaldos de iTunes en busca de indicadores de compromiso de Operation Triangulation: https://github.com/KasperskyLab/triangle_check
    • Es un ataque realmente impresionante, y coincido con el análisis anterior. La parte de “volver a hackear” el dispositivo con una pestaña oculta de Safari, como se dijo, podría ser un mal resultado de silos internos en la organización, o también recuerda al enfoque tipo “crear virus” que usaban los script kiddies en los 90.
      Podría ser un diseño modular para adaptarse rápido, es decir, posiblemente una estructura menos dirigida.
    • O quizá Apple simplemente implementó esta “API” porque ellos se lo pidieron amablemente.
    • Hay demasiada desinformación en este hilo. Esto es ECC de Hamming, como se explica aquí[1].
      [1] https://social.treehouse.systems/@marcan/111655847458820583

  • Steve Weis lo resumió mejor en Twitter:
    “Este exploit de iMessage está demente. Tiene una vulnerabilidad de TrueType que existe desde los 90, 2 exploits de kernel, un exploit de navegador y hasta una función de hardware no documentada que no se usa en software publicado”.
    https://x.com/sweis/status/1740092722487361809?s=46&t=E3U2EI...

  • Si te da curiosidad la presentación de los investigadores de Kaspersky, el video editado todavía no estaba disponible, pero aquí se puede ver la repetición del streaming:
    https://streaming.media.ccc.de/37c3/relive/a91c6e01-49cf-422...
    La presentación empieza en 26:20.

  • Sobre la charla de 37c3, también hay una entrada en alemán de Fefe¹: https://blog.fefe.de/?ts=9b729398
    Según él, el valor de esta cadena de exploits probablemente estaba en un monto de ocho cifras en dólares.
    ¹ https://en.wikipedia.org/wiki/Felix_von_Leitner
    Parece que alguien va a ser despedido.

    • ¿Por qué? Que un exploit “se queme” es parte de este negocio.

  • Coresight no es una puerta trasera, es una función de depuración presente en todas las CPU ARM. Esto parece una extensión de Coresight necesaria para funcionar junto con las funciones de protección de memoria de Apple.
    Aunque no haya documentación pública, miles de ingenieros de Apple probablemente tendrían acceso a un gdb modificado u otras herramientas que puedan usar esto.

    • Para unos es una herramienta de depuración; para otros, una puerta trasera.
    • Aun así, el hashing raro sigue sin explicación.

  • Si es un dispositivo bajo supervisión, se puede desactivar iMessage mediante MDM local usando la app gratuita Apple Configurator de la Mac App Store: https://support.apple.com/guide/deployment/restrictions-for-...
    En dispositivos solo con Wi‑Fi, la app Messages queda oculta
    En dispositivos con Wi‑Fi y red celular, la app Messages sigue visible, pero solo se pueden usar los servicios SMS/MMS
    Por ejemplo, si el dispositivo se va a usar solo por Wi‑Fi durante mucho tiempo, se pueden desactivar los mensajes SMS/MMS y el tráfico inalámbrico celular no urgente con el PIN de la SIM

    • Compró un iPad celular y le puso la SIM de su país para seguir recibiendo SMS, porque los bancos de ese país todavía exigen autenticación por SMS al iniciar sesión
      Pero descubrió que los iPad celulares en la práctica no muestran los SMS que no envía la operadora de la SIM

  • Llama la atención que el hash de una escritura de datos compuesta solo de ceros también sea cero
    Y en el caso de un solo bit, el valor del hash pasa a ser un único valor de la tabla S-box. Es decir, este algoritmo hash probablemente pudo haberse hecho suficiente ingeniería inversa incluso sin documentación interna

    • Esto deja el típico “olor” a una forma de evitar que escrituras de memoria a direcciones aleatorias activen este hardware por accidente. No parece algo pensado como función de seguridad
      De hecho, si alguien hubiera dicho que no debía producirse una escritura arbitraria por un bug, yo lo habría implementado así. Esta implementación también bloquea de forma efectiva el uso de esta función cuando se conoce la dirección del búfer pero no su contenido
      Si el sistema se reinicia cada vez que el hash no coincide, incluso una seguridad de 10 bits probablemente bastaría para ese propósito. La función de depuración Coresight puede reiniciar completamente el sistema si así se desea

  • ¿Qué tan probable es que este registro MMIO se haya descubierto haciendo una búsqueda por fuerza bruta en todas las direcciones de registros?
    Puede que solo por diferencias de timing ya se pudiera saber que esa dirección era válida, y como el hash en la práctica era de 20 bits, quizá también era viable forzarlo por fuerza bruta

    • El registro parece haber podido identificarse con bastante facilidad por fuerza bruta. Está físicamente cerca de registros GPU documentados y al acceder a él provoca un pánico de GPU, así que los investigadores también lo atribuyeron a un componente de GPU. El atacante también pudo haber detectado la existencia del registro con la misma prueba
      Lo que es menos fácil de explicar es cómo reconstruyeron una tabla S-box personalizada para ejecutar el código de depuración. Ahí es donde la insinuación de amenaza interna se vuelve más fuerte, pero personalmente no creo que eso descarte otras explicaciones plausibles
      Por ejemplo, el atacante pudo haber extraído la S-box de firmware antiguo, parches de actualización OTA, dispositivos de desarrollo previos al lanzamiento (que en algún momento probablemente se podían comprar en eBay), versiones beta de iOS u otras muchas vías de filtración
      El investigador básicamente dice que “no encontró esta tabla S-box en ningún otro binario que revisó”. Pero considerando que parece ser algo exclusivo de Apple y por tanto el número de binarios en los que podría aparecer es limitado, no es necesariamente sorprendente. Como también dijo el investigador, eso incluye binarios no públicos hoy en día que podrían haberse distribuido por error. Es totalmente plausible que los atacantes hayan buscado estas filtraciones de forma sistemática y que en algún momento hayan tenido suerte, mientras que al investigador le resulte difícil repetir esa misma suerte pronto
    • Viendo esa implementación de la S-box, cuesta creer que esté implementada como una tabla de búsqueda en el hardware del chip. Debe de haber una expresión booleana más compacta que produzca el mismo resultado
      El hecho de que los atacantes no conocieran esa expresión booleana sugiere más que la dedujeron por ingeniería inversa que que tuvieran documentación

  • https://streaming.media.ccc.de/37c3/relive/11859

    • Empieza desde 27:21
      Junto con lo expuesto en la presentación, ordenado cronológicamente queda así
      Septiembre de 2018: se lanza el Apple A12 Bionic SOC, la primera CPU con MMIO no documentado
      Diciembre de 2021: la infraestructura inicial de la cadena de exploits, backuprabbit.com, se crea el 2021-12-15T18:33:19Z, y cloudsponcer.com el 2021-12-17T16:33:50Z
      Abril de 2022: luego se crea la infraestructura de la cadena de exploits snoweeanalytics.com el 2022-04-20T15:09:17Z, lo que sugiere que para esa fecha el exploit ya estaba convertido en arma
      Diciembre de 2023: parece ser el momento aproximado de detección. Se deduce a partir del período de análisis de “medio año” y de un informe de Apple de mediados de 2023
      Los ponentes dicen que, por rastros dentro del código, el grupo APT de origen usó la misma base de código de ataque durante “10 años”, es decir, aproximadamente desde 2013, y que también la usa para atacar laptops con macOS. Incluye evasión de antivirus
      Los ponentes también señalan la posibilidad de que una función de depuración firmada muy “tipo puerta trasera” se haya incluido en el chip sin que Apple lo supiera, por ejemplo por parte de un desarrollador de GPU
      En otras palabras, menos de 3.5 años después de que el primer chip vulnerable saliera al mercado, una serie MMIO de depuración no documentada del GPU Apple Coresight, cuyo abuso requiere conocer un valor secreto largo, fue convertida con éxito en arma y explotada por un grupo APT ya existente con más de 10 años de historial. Kaspersky dice que “no especula”, pero personalmente me parece poco probable que esto esté al alcance de algo que no sea un actor estatal importante
      Especulando, como Apple recibió pruebas suficientes de que unas 40 Apple ID vinculadas a APT se identificaron por sí mismas, tal vez se pueda inferir la identidad según si después hay o no anuncios de seguridad nacional en EE. UU. Si todo queda en silencio, probablemente sea la NSA
    • Ya subieron lo que parece ser la primera versión de la grabación real:
      https://media.ccc.de/v/37c3-11859-operation_triangulation_wh...