Descubren una puerta trasera no documentada en un chip Bluetooth usado en miles de millones de dispositivos

Descubrimiento de una puerta trasera en chips Bluetooth

• Puerta trasera en el chip ESP32: Se descubrió una "puerta trasera" no documentada en el microchip ESP32 del fabricante chino Espressif. Este chip se usa en más de mil millones de dispositivos desde 2023. La puerta trasera puede suplantar dispositivos de confianza, permitir acceso no autorizado a datos, moverse hacia otros dispositivos de la red o establecer persistencia a largo plazo.

• Contexto del hallazgo: Los investigadores españoles Miguel Tarascó Acuña y Antonio Vázquez Blanco descubrieron esta puerta trasera y la presentaron en RootedCON en Madrid. Esta puerta trasera podría infectar de forma permanente dispositivos sensibles como teléfonos móviles, computadoras, cerraduras inteligentes y equipos médicos.

Descubren una puerta trasera en el ESP32

• Investigación de seguridad en Bluetooth: Aunque ha disminuido el interés por la investigación de seguridad en Bluetooth, esto no se debe a que el protocolo o sus implementaciones sean más seguros. La mayoría de los ataques usan herramientas que no funcionan, no son compatibles con hardware común o dependen de herramientas antiguas que no son compatibles con sistemas modernos.

• Desarrollo de nuevas herramientas: Tarlogic desarrolló un nuevo controlador USB Bluetooth en C, independiente del hardware y multiplataforma, que permite acceder directamente al hardware sin depender de APIs específicas del sistema operativo. Gracias a esto, encontraron comandos ocultos específicos del fabricante (Opcode 0x3F) en el firmware Bluetooth del ESP32.

• Comandos descubiertos: En total se encontraron 29 comandos no documentados, que podrían usarse para manipulación de memoria (lectura/escritura de RAM y Flash), suplantación de direcciones MAC (spoofing de dispositivos) e inyección de paquetes LMP/LLCP.

• Riesgos: Estos comandos podrían facilitar implementaciones maliciosas a nivel OEM y ataques a la cadena de suministro. En particular, un atacante podría explotar remotamente la puerta trasera si ya cuenta con acceso root, instala firmware malicioso o distribuye actualizaciones maliciosas.

• Riesgo del acceso físico: En general, acceder físicamente a las interfaces USB o UART del dispositivo es un escenario de ataque más riesgoso y realista.

• Explicación de los investigadores: Los investigadores explicaron que es posible tomar control total del chip ESP32 y obtener persistencia en él mediante comandos de modificación de RAM y Flash, con la posibilidad de propagarse a otros dispositivos.

• Respuesta de Espressif: BleepingComputer pidió la postura de Espressif sobre los hallazgos, pero no recibió una respuesta inmediata.

[GN⁺]

Comentarios de Hacker News

• El título puede prestarse a confusión. El "backdoor" parece permitir husmear y manipular la memoria de su propio adaptador Bluetooth USB y otras funciones de bajo nivel. No es algo utilizable de forma inalámbrica

  • Los comandos de depuración no documentados son comunes. He encontrado funciones similares en adaptadores WiFi y receptores GPS. Esto se descubre haciendo ingeniería inversa del firmware del chip o de los drivers del proveedor. Por sí solo no es un gran problema. Permitir firmware sin firmar es igual de vulnerable
  • Si esta función pudiera usarse desde fuera del host, sería una historia muy distinta

• Los investigadores descubrieron funciones de hardware no documentadas que permiten acceso de bajo nivel al stack WiFi del ESP32

  • Llamarlo "backdoor" es simplemente clickbait

• Este titular es falso. Un backdoor en un chip Bluetooth permitiría que un atacante inalámbrico ejecute código en el chip. Este artículo informa que el driver del dispositivo conectado puede ejecutar código en el chip. Eso no viola ningún límite de seguridad

  • En un ecosistema periodístico que funcionara bien, haría falta una retractación y eso dañaría seriamente la reputación del medio que lo publicó. Pero eso no va a pasar

• Me confunde si esto solo significa que hay algunos comandos no documentados en el stack Bluetooth. Si esto solo es accesible para código que ya se está ejecutando en el dispositivo, yo no lo llamaría backdoor

• En teoría, uno debería tener acceso de bajo nivel a la radio BT conectada. Eso es lo esperable

  • Prefiero que los dispositivos tengan este tipo de interfaces de bajo nivel. El problema podría no ser su existencia sino la falta de documentación
  • He tomado posesión de dispositivos bloqueados usando comandos de lectura/escritura de memoria por USB en radios Qualcomm. Eso podría no ser bueno porque era lectura/escritura OOB completa, pero si esto solo fuera accesible desde código ya flasheado, sería mejor

• Buena investigación, pero mal titular. Como vector de ataque requiere acceso físico y en casi todos los casos ya puede lograrse por otros medios. "Comandos no documentados encontrados en chips Bluetooth comunes" habría sido un mejor titular

• TL;DR: Hicieron ingeniería inversa del firmware y encontraron comandos HCI para leer/escribir memoria, transmitir paquetes, configurar la dirección MAC y más

  • En realidad no es un backdoor. No sé si ellos lo llamaron así (la presentación está en español) o si los periodistas lo llamaron backdoor para generar clics
  • Enviar comandos HCI al dispositivo requiere acceso arbitrario. Eso significa que ya controlas el dispositivo. No es algo explotable de forma remota a través del enlace inalámbrico. Todos los exploits ya requieren control total del dispositivo, y llegado a ese punto no sorprende poder cambiar la dirección MAC o enviar paquetes
  • Es una investigación interesante, pero da mucha decepción verla empaquetada como un "backdoor". No sé de quién es la responsabilidad de esa expresión. Probablemente de los periodistas

• A todo el mundo le parece bien instalar drivers blob binarios opacos que corren en espacio de kernel en desktops y laptops, y ni siquiera poder tener acceso root en sus teléfonos controlados por la nube, pero unos comandos ESP32 de bajo nivel no documentados que solo pueden usarse cuando el dispositivo ya está comprometido sí son un vector de amenaza con valor noticioso

  • Me pregunto si algo salió mal en la traducción. Antes habría pensado que esto era genial y habría buscado cómo convertirlo en SDR