Cuando se trata de seguridad móvil, a los usuarios se les advierte regularmente que tengan mucho cuidado y eviten enlaces, correos electrónicos y archivos adjuntos sospechosos. Pero el crecimiento de los ataques sin clic pasa por alto estas defensas flexibles.
Google perforó recientemente un ataque de este tipo, que resultó haber golpeado un iPhone. “Creemos que este es uno de los exploits técnicamente más sofisticados que jamás hayamos visto, demostrando una vez más que las capacidades (de un proveedor) rivalizan con las que antes se pensaba que no estaban disponibles que un puñado de estados nacionales”, decía el aviso de Google.
La parte más aterradora del informe de Google, y tiene muchas partes aterradoras, es que rompe una de las reglas no escritas de las alertas de seguridad, que es que no es óptimo informar detalles de un ataque para el cual no hay defensa eficaz. Estoy de acuerdo con Google en que los detalles deben discutirse para que la comunidad pueda preparar una defensa más rápidamente.
“Se ha documentado que NSO ofrece tecnología operativa sin clics a sus clientes, 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 sin clic, no se requiere interacción del usuario. Esto significa que el atacante no necesita enviar mensajes de phishing. El exploit solo funciona en silencio en segundo plano. A menos que no esté utilizando 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 conmovedor, vayamos 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 usó 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 solo pretende 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. Con este truco de gif falso, más de 20 códecs de imágenes se convierten repentinamente en parte de la superficie de ataque sin clics 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 ha señalado Google, estos ataques son difíciles de frustrar. Es poco probable que el bloqueo de todas las imágenes GIF sea 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 otra extensión que parezca inofensiva.
(Nota: el informe de Google indica que Apple intentó revertir el ataque GIF a través de correcciones lanzadas en 2021. "Apple nos informa que han restringido los formatos ImageIO disponibles accesibles desde IMTranscoderAgent desde iOS 14.8.1 (26 de octubre de 2021) y eliminó por completo la ruta del código GIF de IMTranscoderAgent de iOS 15.0 (20 de septiembre de 2021), y la decodificación de GIF se llevó a cabo completamente en BlastDoor.
La técnica de compresión
Esta es una táctica común y legítima para reducir el tamaño del archivo reemplazando ciertos caracteres repetidos. Se mete un poco en la maleza: “Esto le da a la página de destino actual de JBIG2Bitmap un valor desconocido, pero muy grande, para h. Dado que este valor h se usa para la verificación de límites y se supone que refleja el tamaño asignado del búfer de guardado de la página, esto tiene el efecto de "delinear" 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 la página de guardado.
Результат?
"Al representar mapas de bits de 4 bytes en las coordenadas de lienzo correctas, pueden escribir en todos los campos en la página JBIG2Bitmap, y al elegir cuidadosamente nuevos valores para w, h y línea, pueden escribir en compensaciones arbitrarias del búfer. "guardando 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 guardado de la página. Pero, ¿cómo calcular estas compensaciones? Hasta ahora, este exploit se ha desarrollado de manera muy similar a un exploit de lenguaje de secuencias de comandos canónico que, en Javascript, podría dar como resultado un objeto ArrayBuffer ilimitado con acceso a la memoria. Pero en estos casos, el atacante tiene la opción de ejecutar JavaScript arbitrario, que obviamente puede usarse para calcular compensaciones y realizar cálculos arbitrarios. ¿Cómo se hace esto 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 copia de seguridad JBIG2Bitmap de la página actual. Y dado que ha sido ilimitado..., es posible realizar estas 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 ingresar y ejecutar código no autorizado. Esta es información crítica porque permite a los codificadores evitar este agujero de vez en cuando y también le da al software algo concreto para encontrar y bloquear.
Ataques fuera de rango
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 se ejecutan en una memoria arbitraria. Entonces, ¿por qué no usarlo para crear su propia arquitectura de TI y escribirla? ? Esto es exactamente lo que hace esta hazaña. Mediante el uso de más de 70 000 comandos de segmento que definen operaciones binarias lógicas, 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 encontrar memoria y realizar operaciones aritméticas. No es tan rápido como Javascript, pero es básicamente 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 dice que estas cosas se acercan al estándar de mala calidad del estado-nación. Pero al menos esos detalles ayudarán a los CIO y CISO a comenzar a eludirlo.
© 2022 IDG Communications, Inc.