Google encuentra un nivel de estado-nación de ataques en iPhone

Cuando se trata de seguridad móvil, a los usuarios se les advierte de manera rutinaria que tengan mucho cuidado y eviten enlaces, correos electrónicos y archivos adjuntos sospechosos. Pero el crecimiento de los ataques sin clic elude estas defensas blandas.

Google perforó recientemente uno de esos ataques, que resultó haber golpeado un iPhone. “Evaluamos que este es uno de los exploits técnicamente más sofisticados que jamás hayamos visto, lo que demuestra aún más que las capacidades (un proveedor) brindan competencia a las que anteriormente se pensaba que solo eran accesibles para un puñado de estados nacionales”. dijo el aviso de Google.

La parte más aterradora del informe de Google, y hay una lote de partes aterradoras, es que viola una de las reglas no escritas de las alertas de seguridad, a saber, que no es óptimo informar los detalles de un ataque para el cual no existe una defensa efectiva. Estoy de acuerdo con Google aquí en que los detalles deben discutirse para que la comunidad pueda inventar una defensa más rápidamente.

“Se ha documentado que NSO está ofreciendo a sus clientes tecnología de explotación sin clic, donde incluso los objetivos con conocimientos técnicos que podrían no hacer clic en un enlace de phishing ignoran por completo que están siendo atacados. En el escenario de cero clics, no se requiere interacción del usuario. Es decir, el atacante no necesita enviar mensajes de phishing. El exploit simplemente funciona en silencio en segundo plano. Aparte de no usar un dispositivo, no hay forma de evitar la explotación mediante un exploit sin clic. Es un arma contra la que no hay defensa”.

Con ese pensamiento reconfortante, pasemos a los detalles.

El gráfico que no es realmente un gráfico

La compañía detrás del software utilizado en estos ataques, NSO, supuestamente usa un truco de GIF falso para atacar una vulnerabilidad en el analizador de PDF CoreGraphics. Los archivos tienen una extensión .gif, pero no son archivos de imagen GIF. El nombre está diseñado únicamente para evitar que un usuario se preocupe.

“La biblioteca ImageIO se utiliza para adivinar el formato correcto del archivo de origen y analizarlo, ignorando por completo la extensión del archivo. Usando este truco de gif falso, más de 20 códecs de imágenes son repentinamente parte de la superficie de ataque sin clic de iMessage, incluidos algunos formatos muy oscuros y complejos, que exponen de forma remota probablemente cientos de miles de líneas de código.

Como señaló Google, estos ataques son difíciles de frustrar. Es poco probable que el bloqueo de todas las imágenes GIF resulte efectivo. Primero, estos archivos no son en realidad GIF. El enfoque más simple es bloquear cualquier cosa usando una extensión GIF, pero los malos simplemente cambiarán a una extensión diferente que suene inocua.

(Nota: el informe de Google dice que Apple ha estado tratando de negar el ataque GIF a través de parches lanzados en 2021. “Apple nos informa que han restringido los formatos ImageIO disponibles a los que se puede acceder desde IMTranscoderAgent a partir de iOS 14.8.1 (26 de octubre de 2021) y eliminó por completo la ruta del código GIF de IMTranscoderAgent a partir de iOS 15.0 (20 de septiembre de 2021), y la decodificación de GIF se realizó completamente dentro de BlastDoor”.

La técnica de compresión

Se trata de una táctica legítima común para reducir el tamaño de los archivos reemplazando algunos caracteres repetidos. Esto se mete un poco en la maleza: “Esto le da a la página de destino actual JBIG2Bitmap un valor desconocido, pero muy grande, para h. Dado que ese valor h se usa para verificar los límites y se supone que refleja el tamaño asignado del búfer de respaldo de la página, esto tiene el efecto de ‘desenlazar’ el lienzo de dibujo. Esto significa que los comandos de segmento JBIG2 subsiguientes pueden leer y escribir en la memoria fuera de los límites originales del búfer de respaldo de la página”.

¿El resultado?

“Al representar mapas de bits de 4 bytes en las coordenadas de lienzo correctas, pueden escribir en todos los campos de la página JBIG2Bitmap y al elegir cuidadosamente nuevos valores para w, h y línea, pueden escribir en compensaciones arbitrarias desde el búfer de respaldo de la página. En este punto, también sería posible escribir en direcciones de memoria absolutas arbitrarias si conociera sus compensaciones del búfer de respaldo de la página. Pero, ¿cómo calcular esas compensaciones? Hasta ahora, este exploit ha procedido de una manera muy similar a un exploit de lenguaje de secuencias de comandos canónicas que en Javascript podría terminar con un objeto ArrayBuffer ilimitado con acceso a la memoria. Pero en esos casos, el atacante tiene la capacidad de ejecutar Javascript arbitrario, que obviamente puede usarse para calcular compensaciones y realizar cálculos arbitrarios. ¿Cómo se hace eso en un analizador de imágenes de un solo paso? En la práctica, esto significa que es posible aplicar los operadores lógicos AND, OR, XOR y XNOR entre regiones de memoria en desplazamientos arbitrarios del búfer de respaldo JBIG2Bitmap de la página actual. Y dado que eso ha sido ilimitado…, es posible realizar esas operaciones lógicas en la memoria en compensaciones arbitrarias fuera de los límites».

Este es un problema de codificación que permite a los atacantes colarse y ejecutar código no autorizado. Esta información es crítica, ya que permite a los codificadores evitar este agujero de vez en cuando y le da al software algo concreto para encontrar y bloquear.

Ataques fuera de alcance

Otro punto de Google: “JBIG2 no tiene capacidades de secuencias de comandos, pero cuando se combina con una vulnerabilidad, tiene la capacidad de emular circuitos de puertas lógicas arbitrarias que operan en memoria arbitraria. Entonces, ¿por qué no usar eso para construir su propio ¿Arquitectura de computadora y script eso? Eso es exactamente lo que hace este exploit. Mediante el uso de más de 70 000 comandos de segmento que definen operaciones de bits lógicos, definen una arquitectura de computadora pequeña con características tales como registros y un sumador y comparador completo de 64 bits, que utilizan para buscar en la memoria y realizar operaciones aritméticas. No es tan rápido como Javascript, pero es fundamentalmente computacionalmente equivalente. Las operaciones de arranque para el exploit de escape de sandbox están escritas para ejecutarse en este circuito lógico y todo se ejecuta en este extraño entorno emulado creado a partir de un solo paso de descompresión a través de una secuencia JBIG2”.

Google tiene toda la razón cuando argumenta que estas cosas se están acercando al nivel de maldad del estado-nación. Pero al menos estos detalles ayudarán a los CIO y CISO a comenzar a maniobrar para evitarlo.