Honeynet UNAMex Lab Logo
Honeynet UNAMex Lab

USBLiter8: El Exploit de Hardware No Parcheable que Rompe la Cadena de Confianza desde el Arranque

USBLiter8: Cuando un cable USB es suficiente para romper el arranque seguro de un chip

Clasificación: Vulnerabilidad de alta severidad — Compromiso de cadena de confianza / Ejecución de código no firmado Fecha de divulgación pública: 18 de junio de 2026 Investigadores: Paradigm Shift

La firma de investigación en seguridad Paradigm Shift hizo público un exploit denominado USBLiter8, capaz de ejecutar código arbitrario dentro del SecureROM (BootROM) de los chips Apple A12 y A13, así como de los SoC S4 y S5 utilizados en Apple Watch. A diferencia de la inmensa mayoría de vulnerabilidades que cubrimos en este espacio, el fallo no reside en una línea de código que pueda corregirse con una actualización: está grabado de forma permanente en el silicio durante la fabricación del chip.

El problema en una línea

Cualquier persona con acceso físico a uno de estos dispositivos, un cable USB y una placa de microcontrolador de bajo costo podía, en menos de dos segundos, ejecutar código propio dentro del primer eslabón de la cadena de arranque seguro. Sin jailbreak previo. Sin exploits de software. Sin que ninguna actualización futura pueda revertirlo.

Eso es USBLiter8.

¿Qué es USBLiter8 y por qué importa?

En términos cotidianos, el arranque seguro (secure boot) es el mecanismo que garantiza que un dispositivo solo ejecute software verificado y firmado por el fabricante desde el instante en que se encienden. Esa garantía se construye como una cadena: el primer código que se ejecuta —el SecureROM o BootROM— verifica al siguiente eslabón, y así sucesivamente, hasta llegar al sistema operativo completo.

El fallo de USBLiter8 reside precisamente en ese primer eslabón: un defecto de diseño en el controlador USB Synopsys DWC2, integrado en el propio procesador. Cuando un dispositivo entra en modo DFU (Device Firmware Update) —el estado de recuperación de bajo nivel usado normalmente para reinstalar firmware— el controlador procesa de forma incorrecta ciertas secuencias de paquetes USB Setup, lo que permite a un atacante manipular estructuras internas de memoria antes de que se cargue cualquier software firmado.

Lo que convierte este caso en especialmente relevante —más allá de la gravedad técnica— es que el código defectuoso vive en memoria de solo lectura grabada en fábrica. Apple puede parchear fallos en iOS, iPadOS o watchOS mediante actualizaciones; no puede parchear el SecureROM de un chip que ya salió de la línea de producción. Esto ilustra un patrón distinto al de la seguridad de software tradicional: cuando el defecto está en el hardware, la única mitigación completa es el reemplazo del propio hardware.

¿Cómo funciona el fallo?

Para entender la vulnerabilidad, conviene entender qué papel juega el SecureROM en estos dispositivos.

El SecureROM es el primer código que se ejecuta al encender el chip: verifica criptográficamente al siguiente componente de arranque (iBoot) antes de cederle el control. Es, por diseño, el componente del que depende toda la seguridad posterior del sistema. Para mantenerlo inmutable y resistente a manipulación, se grava directamente en el silicio en el momento de fabricación.

USBLiter8 explota una inconsistencia en cómo ese código gestiona la memoria durante operaciones USB de bajo nivel:

Paso 1 — Entrada a modo DFU y conexión física. El dispositivo objetivo se coloca manualmente en modo DFU y se conecta mediante USB a una placa de microcontrolador basada en RP2350 (por ejemplo, Waveshare RP2350 USB-A/Zero, Pimoroni TINY2350 o Raspberry Pi Pico 2), capaz de generar tráfico USB de bajo nivel que las pilas de host convencionales no producen.

Paso 2 — Manipulación de la negociación USB. La placa envía una secuencia de paquetes USB Setup consecutivos diseñada para confundir al controlador DWC2 durante la fase inicial de negociación de la conexión.

Paso 3 — Corrupción de memoria del proceso de arranque. En chips A12, el búfer de DMA se ubica de forma contigua a la pila del proceso que gestiona USB en el heap; sobrescribir un registro de enlace guardado entrega control del contador de programa en el siguiente cambio de contexto. En chips A13, protegidos por Pointer Authentication (PAC), el bypass requiere etapas adicionales: corrupción de estructuras de heap relacionadas con DART, manipulación del contador de profundidad de pánico para evitar reinicios automáticos, y sobrescritura temporizada del puntero al manejador de interrupciones USB en la sección BSS.

Paso 4 — Ejecución privilegiada dentro del SecureROM. Con las estructuras de memoria ya corrompidas, el siguiente evento de interrupción USB ejecuta código del atacante en modo privilegiado (EL1), dentro del propio SecureROM, antes de que se cargue la cadena de arranque firmada.

La explotación no requiere jailbreak previo, software adicional en el dispositivo ni acceso remoto. Un dispositivo vulnerable, posesión física, un cable y la placa adecuada son suficientes. Cabe destacar que el exploit no compromete directamente al Secure Enclave: los datos cifrados del usuario y los códigos de acceso permanecen, en principio, protegidos, aunque los investigadores advierten que un compromiso de esta profundidad podría abrir rutas adicionales hacia ese subsistema.

¿Qué sistemas están afectados?

El impacto de USBLiter8 está acotado a los dispositivos que integran el controlador DWC2 junto con la configuración de protecciones de hardware presente en estas generaciones de silicio:

No están afectados:

La condición mínima de explotación —posesión física del dispositivo, modo DFU activado manualmente y una placa de hardware específica— limita su uso a escenarios dirigidos: custodia temporal por terceros, puestos de control fronterizo, dispositivos perdidos o robados, o cadenas de suministro comprometidas.

¿Por qué los fallos de hardware son la amenaza más difícil de erradicar?

USBLiter8 pertenece a una familia de vulnerabilidades poco frecuente pero especialmente temida en la industria: los fallos de BootROM, de los que apenas existen precedentes públicos —el más conocido, checkm8, expuso en 2019 hardware aún más antiguo de Apple.

La razón de su rareza es también la razón de su gravedad. El código de un BootROM se valida exhaustivamente antes de su grabado porque, a diferencia de cualquier otra capa del sistema, no admite una segunda oportunidad: una vez fabricado el chip, ese código es definitivo. Cuando aparece un defecto de todas formas, no hay parche posible; solo existe la opción de cambiar la configuración de protecciones en las siguientes generaciones de silicio, como ocurrió con A14 frente a A12/A13.

El hallazgo también tiene una implicación metodológica relevante: explotar el SecureROM requería, hasta ahora, recursos de investigación significativos. Que un equipo externo a Apple consiga romperlo usando hardware de microcontrolador disponible comercialmente —y no instrumentación de laboratorio especializada— reduce la barrera de entrada para este tipo de investigación, lo que probablemente impulsará nuevos hallazgos similares sobre otras familias de chips en el futuro.

Recomendaciones de seguridad

La medida más importante es, en este caso, la inversa de la habitual: no existe una actualización que corrija el fallo. Las recomendaciones se orientan al control del acceso físico y a la gestión del ciclo de vida del hardware.

Para usuarios y administradores de flotas de dispositivos

Escenario Medida recomendada
Dispositivos corporativos A12/A13 en uso activo Reforzar políticas de custodia física y restringir el acceso de terceros no autorizados
Equipos en puntos de carga públicos o compartidos Usar bloqueadores de datos USB (“condones USB”) que permitan solo el paso de energía
Dispositivos que requieran soporte técnico con modo DFU Realizar el procedimiento únicamente en talleres autorizados y bajo supervisión
Entornos de alta sensibilidad (gobierno, finanzas, salud) Priorizar la migración a hardware con chip A14 o posterior
Dispositivos perdidos, robados o recuperados de terceros Tratarlos como potencialmente comprometidos y evaluar su reemplazo antes de reincorporarlos a la operación

Recapitulando…

USBLiter8 es un exploit de tipo BootROM que permite ejecutar código no firmado dentro del SecureROM de los chips Apple A12, A13, S4 y S5, mediante un defecto físico en el controlador USB DWC2 explotado con acceso físico al dispositivo en modo DFU.

El fallo fue divulgado por la firma Paradigm Shift, que notificó a Apple Product Security antes de la publicación, y reside en la forma en que el controlador procesa paquetes USB Setup consecutivos durante el arranque. Su impacto alcanza a iPhone XS hasta iPhone 11, ciertos modelos de iPad, Apple Watch S4/S5 y dispositivos que comparten el mismo chipset.

Los puntos clave a retener:

USBLiter8 no cambia el riesgo cotidiano para la mayoría de los usuarios —el ataque exige posesión física y manipulación deliberada—, pero sí es un recordatorio de que, cuando la confianza falla en el hardware, ninguna capa de software por encima puede compensarlo del todo.

Referencias