usbliter8: el fallo de hardware que compromete el SecureROM de Apple en A12/A13 y no tiene parche

El 18 de junio de 2026 se publicó una investigación técnica y una prueba de concepto que cambia el panorama para varios dispositivos Apple: el exploit llamado usbliter8 permite ejecutar código arbitrario dentro del SecureROM de chips A12 y A13, el código que se quema en la silicona durante la fabricación y que ninguna actualización de software puede modificar.

La raíz del problema es un fallo de hardware en el controlador USB Synopsys DWC2: la unidad DMA que guarda paquetes USB Setup puede retroceder su puntero de escritura por un desfase entre cómo se reinicia el índice y cómo se aceptan paquetes más cortos de lo habitual, provocando un underflow repetible del buffer. Eso por sí solo no bastaría, pero en A12 y A13 Apple configuró el DART (el IOMMU del USB dentro de SecureROM) en un modo de bypass que permite que esos punteros DMA escritos hacia atrás alcancen y corrompan SRAM arbitraria. Con cadenas de técnicas adicionales (incluida una evasión por etapas de Pointer Authentication en A13), los investigadores logran ejecución a nivel privilegiado (EL1) dentro de SecureROM en menos de dos segundos desde que el dispositivo está en modo DFU y conectado por USB a un microcontrolador dedicado.

Es importante entender el alcance práctico. Esto no es un ataque remoto: requiere posesión física del dispositivo, forzar el modo DFU y disponer del hardware adecuado y del conocimiento para explotarlo. Las familias afectadas incluyen iPhone XS/XS Max/XR, iPhone 11/11 Pro, iPhone SE (2ª gen), varios iPad con A12/A13, Apple Watch Series 4/5 y HomePod mini, entre otros; A11 no está afectado y A14 y generaciones posteriores parecen inmunes a esta vía, según los investigadores. La analogía técnica y operativa más cercana en la historia reciente es el exploit checkm8 de 2019, que dejó fuera del alcance de parches a los chips A5–A11; para contexto técnico y precedentes ver la página pública sobre checkm8 https://en.wikipedia.org/wiki/Checkm8.

Las implicaciones para seguridad corporativa y de alto riesgo son claras y duras: no existe un parche de software que cierre esta puerta. Cualquier dispositivo con un SoC afectado mantiene la vulnerabilidad mientras exista físicamente el silicio. Para usuarios individuales la probabilidad de encontrarse con un atacante con las capacidades necesarias es baja, pero para gobiernos, empresas con datos sensibles o roles con requisitos de custodia estricta esto es una situación de custodia y retiro de hardware.

Recomendaciones prácticas inmediatas: primero, inventariar equipos que usen A12/A13/S4/S5 y clasificarlos por criticidad; segundo, priorizar la sustitución por equipos con A14 o posteriores para roles donde la integridad física y de arranque sea crítica; tercero, aplicar controles físicos estrictos: no dejar dispositivos desatendidos, usar almacenamiento y cadena de custodia con registro y sellos, y evitar que los dispositivos sean conectados vía USB a hosts o cables no controlados. Cabe destacar que muchas contramedidas de software no aplican: el exploit opera antes de la cadena de arranque firmada y no depende de la configuración del sistema operativo, por lo que herramientas como la gestión móvil empresarial o las políticas de sistema no podrán detener la explotación si el adversario tiene el dispositivo en mano.

Algunas medidas complementarias y realistas para reducir riesgo: evitar dejar dispositivos en modo DFU o físicamente accesibles, aplicar sellos físicos y controles de entrada/salida en áreas de alta seguridad, y considerar el uso de dispositivos de reserva o hardware dedicado a funciones sensibles que ya estén en generaciones más nuevas. Para usuarios que quieran comprobar si su dispositivo corresponde a un modelo potencialmente afectado, Apple mantiene documentación para identificar modelos y especificaciones que puede consultarse en su página de soporte sobre modelos de iPhone y iPad https://support.apple.com/en-us/HT201296.

Un punto crítico: los investigadores no demostraron acceso directo al Secure Enclave, y Apple ha diseñado ese componente como una frontera separada, pero la toma de control del BootROM y del SecureROM abre vectores nuevos que podrían facilitar ataques físicos adicionales, por lo que no conviene mirar la ausencia de una prueba de compromisos del enclave como garantía definitiva de seguridad.

Finalmente, el hecho de que la prueba de concepto y el código estén públicos cambia la ecuación: lo que hoy es investigación y demostración puede convertirse mañana en una herramienta más accesible para actores con recursos. Los responsables de seguridad deben asumir que la disponibilidad pública reduce la barrera técnica y ajustar políticas de custodia, requisitos de hardware y ciclos de renovación en consecuencia. Para mantenerse informado sobre avisos oficiales y patrones de explotación se recomienda vigilar tanto los comunicados del fabricante como las bases de datos y centros de respuesta a incidentes; para referencia general sobre divulgación de vulnerabilidades y actuaciones del CERT/NVD, ver el NIST NVD https://nvd.nist.gov/.

En resumen, usbliter8 es un recordatorio duro de que las vulnerabilidades de hardware pueden ser permanentes y que la seguridad física y la selección de plataforma son decisiones estratégicas: controlar quién tiene acceso físico al dispositivo y cuándo puede ser conectado por USB forma ahora parte de la superficie de seguridad que las organizaciones deben gestionar activamente.