Un problema ahora solucionado obligó a los investigadores a eludir las restricciones de Apple y realizar acciones controladas por atacantes en el LLM del dispositivo. Así es como lo hicieron.
Desde entonces, Apple ha reforzado sus defensas contra estos ataques.
Dos publicaciones de blog (1, 2) publicado hoy en el blog de RSAC (a través de AppleInsider) detalla cómo los investigadores combinaron dos técnicas de ataque para obtener el modelo de dispositivo de Apple para ejecutar instrucciones controladas por el atacante mediante inyección rápida.
Curiosamente, realizaron con éxito el exploit sin estar 100% seguros de cómo el modelo local de Apple maneja las partes del canal de filtrado de entrada y salida, ya que Apple no revela los detalles exactos del funcionamiento interno de sus modelos, presumiblemente por razones de seguridad.
Aun así, los investigadores señalan que tienen una idea bastante clara de lo que sucede bajo el capó.
Según ellos, el escenario más probable es que después de que un usuario envíe un mensaje al modelo del dispositivo de Apple a través de una llamada API, un filtro de entrada garantice que la solicitud no contenga contenido inseguro.
Si es así, la API falla. De lo contrario, la solicitud se reenvía al modelo real en el dispositivo, que pasa su respuesta a un filtro de salida que verifica si la salida contiene contenido no seguro, ya sea fallando la API o dependiendo de lo que encuentre.
¿Cómo lo hicieron realmente?
Teniendo esto en cuenta, los investigadores descubrieron que podían utilizar dos técnicas para hacer que el modelo de Apple ignorara sus instrucciones básicas de seguridad y al mismo tiempo manipulara los filtros de entrada y salida para permitir la entrada de contenido malicioso.
Primero, escribieron la cadena maliciosa al revés, luego usaron caracteres Unicode de anulación de derecha a izquierda para representarla correctamente en la pantalla del usuario, mientras la dejaban al revés en la entrada y salida sin procesar donde los filtros la examinarían.
Luego, los investigadores integraron la cadena maliciosa en un segundo método de ataque llamado Neural Exec, que es básicamente una forma elaborada de anular las instrucciones del modelo si un atacante quiere ejecutarlas.
Como resultado, el ataque Unicode pudo eludir los filtros de entrada y salida, mientras que Neural Exec en realidad provocó que el modelo de Apple se comportara mal.
Para evaluar la efectividad del ataque, preparamos tres grupos distintos para generar mensajes de entrada apropiados:
- Aviso del sistema: Una colección de indicaciones/tareas del sistema (por ejemplo, “Editar el texto proporcionado para alinearlo con la ortografía y puntuación del inglés americano”).
- Cuerda dañina: Las cadenas generadas manualmente están diseñadas para ser consideradas agresivas o maliciosas (es decir, nuestro objetivo es forzar al modelo a generarlas).
- Aporte honesto: Se utilizan pasajes de artículos aleatorios de Wikipedia para simular entradas no conflictivas y de apariencia benigna (por ejemplo, en el contexto de una inyección rápida indirecta a través de RAG o sistemas similares).
Durante la evaluación, tomamos muestras aleatorias de un elemento de cada grupo, ensamblamos un mensaje completo, creamos una carga útil armada (ver más abajo), la inyectamos y comprobamos si el ataque tiene éxito invocando el modelo de dispositivo de Apple a través del sistema operativo.
En sus pruebas, los atacantes alcanzaron una tasa de éxito del 76% en 100 mensajes aleatorios.
Revelaron el ataque a Apple en octubre de 2025, y la compañía “desde entonces ha reforzado los sistemas afectados contra este ataque, y esas protecciones se implementaron en iOS 26.4 y macOS 26.4”.
Para leer el informe completo, también incluye un enlace a los aspectos técnicos del ataque, Sigue este enlace.
