Backdoor no documentada descubierta en un chip Bluetooth usado en miles de millones de dispositivos
(bleepingcomputer.com)- Se descubrieron comandos Bluetooth no incluidos en la documentación pública en el ESP32, ampliamente usado en dispositivos IoT, y el alcance potencial es grande porque, para 2023, era un chip presente en más de 1.000 millones de dispositivos
- Tarlogic Security presentó en RootedCON 29 comandos específicos de proveedor del firmware Bluetooth del ESP32, y señaló la posibilidad de leer/escribir RAM y Flash, suplantar direcciones MAC e inyectar paquetes LMP/LLCP
- Estos comandos podrían derivar en suplantación de dispositivos confiables, acceso no autorizado a datos, movimiento dentro de la red y persistencia a largo plazo; el problema se rastrea como CVE-2025-27840
- La posibilidad real de explotación remota depende de cómo la pila Bluetooth del dispositivo procese los comandos HCI, y es más relevante cuando hay firmware malicioso, actualizaciones maliciosas o acceso root ya obtenido
- Espressif dijo que se trata de comandos de depuración para pruebas internas y que por sí solos no pueden crear un riesgo de seguridad para el ESP32, pero planea eliminar los comandos no documentados en futuras actualizaciones de software
Comandos Bluetooth no documentados que quedaron en el ESP32
- El microchip ESP32 del fabricante chino Espressif incluye comandos Bluetooth que no aparecen en la documentación pública
- El ESP32 es un microcontrolador que proporciona conectividad Wi-Fi y Bluetooth a dispositivos IoT, y para 2023 se usaba en más de 1.000 millones de dispositivos
- Los comandos descubiertos podrían utilizarse para las siguientes acciones
- Suplantación para hacerse pasar por un dispositivo confiable
- Acceso no autorizado a datos
- Movimiento hacia otros dispositivos dentro de la red
- Posible obtención de persistencia a largo plazo
El hallazgo de Tarlogic y su herramienta de investigación
- Miguel Tarascó Acuña y Antonio Vázquez Blanco, de la española Tarlogic Security, presentaron los resultados de la investigación en RootedCON, en Madrid
- Los investigadores consideran que el interés por la investigación de seguridad Bluetooth ha disminuido, pero no porque el protocolo o sus implementaciones se hayan vuelto más seguros
- Muchos ataques publicados recientemente no contaban con herramientas funcionales, no funcionaban con hardware de propósito general o dependían de herramientas antiguas y sin mantenimiento, poco compatibles con sistemas modernos
- Tarlogic desarrolló un nuevo driver USB Bluetooth basado en C
- Es independiente del hardware y funciona de forma multiplataforma
- Permite acceder directamente al hardware sin depender de APIs específicas del sistema operativo
- Habilita acceso en bruto al tráfico Bluetooth
Control de bajo nivel permitido por los comandos
- Se identificaron comandos específicos de proveedor ocultos en el firmware Bluetooth del ESP32
- El opcode es
0x3F - Permiten controlar funciones Bluetooth a bajo nivel
- El opcode es
- En total se descubrieron 29 comandos no documentados
- Las funciones principales están relacionadas con lo siguiente
- Manipulación de memoria en RAM y Flash
- Suplantación de dispositivos mediante spoofing de direcciones MAC
- Inyección de paquetes LMP/LLCP
- Como Espressif no documentó públicamente estos comandos, es posible que no estuvieran pensados para ser accesibles o que hayan quedado por error
- Este problema se rastrea como CVE-2025-27840
Posibilidades de ataque y restricciones realistas
- Los investigadores consideran que estos comandos podrían generar riesgos de implementaciones maliciosas a nivel de OEM o de ataques a la cadena de suministro
- La posibilidad de explotación remota depende de cómo la pila Bluetooth del dispositivo procese los comandos HCI
- En las siguientes condiciones, la explotación remota podría volverse más probable
- Si el atacante ya obtuvo acceso root
- Si se implantó malware
- Si se distribuyó una actualización maliciosa que abre acceso de bajo nivel
- Si intervienen firmware malicioso o una conexión Bluetooth rogue
- En general, el acceso físico a la interfaz USB o UART del dispositivo es un escenario de ataque más realista
- Tarlogic considera que, si se compromete un dispositivo IoT que contiene un ESP32, sería posible ocultar una APT dentro de la memoria del ESP, controlar el dispositivo por Wi-Fi/Bluetooth y realizar ataques Bluetooth o Wi-Fi contra otros dispositivos
- Los comandos que permiten modificar RAM y Flash podrían llevar al control total del chip ESP32 y a la obtención de persistencia a nivel de chip
Aclaración de Espressif y plan de corrección
- BleepingComputer solicitó inicialmente comentarios a Espressif, pero no recibió respuesta inmediata
- Más tarde, Espressif emitió una postura oficial sobre el hallazgo de Tarlogic
- La compañía explicó que las funciones descubiertas son comandos de depuración con fines de pruebas internas
- Estos comandos forman parte de la implementación del protocolo HCI (Host Controller Interface) usado por la tecnología Bluetooth
- HCI se usa dentro del producto para la comunicación entre capas Bluetooth
- Espressif considera que la existencia de los comandos de depuración no puede, por sí sola, crear un riesgo de seguridad para el chip ESP32
- Sin embargo, planea proporcionar una corrección de software para eliminar los comandos no documentados
Corrección de términos y actualización del artículo
- En la actualización del 9 de marzo de 2025, se modificaron el título y el cuerpo para reflejar preocupaciones sobre llamar “backdoor” a los comandos no documentados
- El 8 de marzo de 2025 se agregó la postura de Tarlogic
- El 9 de marzo de 2025 se agregó el ID de CVE
- El 10 de marzo de 2025 se agregó la postura oficial de Espressif
1 comentarios
Opiniones en Hacker News
Creo que el título es un poco engañoso. Si entendí bien lo que leí, la puerta trasera de la que hablan aquí permite que la computadora lea y escriba en la memoria y en funciones de bajo nivel de su propio adaptador USB Bluetooth.
No parece que esto pueda explotarse de forma inalámbrica. Estos comandos de depuración no documentados son comunes, y he visto funciones similares en adaptadores WiFi y receptores GPS. Simplemente los encontraron haciendo ingeniería inversa del firmware del chip o de los drivers del proveedor; no estaban documentados, pero eso por sí solo no es un problema de gran impacto. Si permite firmware sin firma, entonces es igual de vulnerable.
Si puede usarse desde algún lugar que no sea el host, entonces sería una historia completamente distinta.
Espressif ha sido una excepción casi única en cuanto a apertura en este ámbito. También contribuyó a una toolchain Rust de código abierto para sus chips, e incluso alentó públicamente la ingeniería inversa de su stack de módem, que no puede publicar por temas de código licenciado. No me gusta que el precio por mostrar aunque sea un poco de apertura sea una publicidad mala y dañina.
“Según cómo procese el stack Bluetooth de un dispositivo los comandos HCI, la explotación remota de la puerta trasera podría ser posible mediante firmware malicioso o una conexión Bluetooth maliciosa”.
En pocas palabras, si tienes un stack de drivers seguro y confías en todo el código local, las extensiones HCI del proveedor no son un problema.
Dicho eso, las extensiones HCI pueden convertirse fácilmente en agujeros de seguridad. El problema es que HCI combina entradas controladas por atacantes con interfaces complejas y parsing delicado. Como demostró la vulnerabilidad BleedingTooth hace unos años, es fácil equivocarse.
Tener estas funciones también facilita pivotear desde otras vulnerabilidades, pero en la mayoría de los sistemas eso es casi fruta al alcance de la mano.
[0] https://google.github.io/security-research/pocs/linux/bleedi...
Incluso dejando de lado el peor caso de una API web, supongamos que, para evitar riesgos, ejecutas software en el que confías a medias dentro de tres capas de VM anidadas. Ese software da una razón plausible para necesitar acceso a Bluetooth, y le concedes una excepción. No te gusta el resultado, borras el software y también reinicias las tres capas de VM. Parece que terminó, pero lo que el malware instaló en el ESP mientras tenía acceso podría seguir ahí.
El acceso no documentado a tus dispositivos subordinados puede ser algo realmente malo, sobre todo cuando entra en juego la persistencia.
Se puede imaginar una situación en la que el ESP32 no se use como SoC independiente, sino como un “módem” WiFi/Bluetooth conectado al sistema host mediante un enlace serial.
En teoría, un atacante podría usar comandos no documentados para escanear, suplantar o atacar dispositivos Bluetooth cercanos. Tal vez incluso sin obtener permisos root en el dispositivo que hospeda al ESP32.
Se sorprenderían al saber que con permisos root dentro del OS se puede reescribir el firmware de una unidad de disco.
Lo que encontraron los investigadores es una función de hardware no documentada que permite que alguien que ya tiene permisos de ejecución de código acceda a un nivel más profundo de lo esperado en el stack WiFi del ESP32.
Llamar a esto “puerta trasera” es puro clickbait.
Estoy confundido. ¿Significa que hay algunos comandos no documentados en el stack Bluetooth? Si solo puede acceder código que ya se está ejecutando en el dispositivo, parece difícil llamarlo puerta trasera.
Esto no suena a ejecución remota de código.
Por eso existe la posibilidad de que un programa en espacio de usuario, o peor, un programa WebBLE, agregue una carga maliciosa persistente al adaptador. Un beacon de rastreo que sobreviva incluso después de cambiar el disco da miedo, pero no es ejecución remota de código.
En teoría, tendría que poder obtener acceso de bajo nivel al propio chip inalámbrico Bluetooth conectado, así que hasta cierto punto me parece esperable.
Es mejor que los dispositivos tengan este tipo de interfaces de bajo nivel. El problema quizá no sea su existencia, sino la falta de documentación.
Antes, en chips inalámbricos de Qualcomm, se podían usar comandos de lectura/escritura de memoria por USB para desbloquear dispositivos bloqueados y tomar posesión de ellos. Era una lectura/escritura totalmente fuera de banda, así que tal vez no fuera ideal, pero si esto solo es accesible desde el código flasheado, entonces es más bien una mejora.
Diapositivas en español: https://www.documentcloud.org/documents/25554812-2025-rooted...
En resumen, hicieron ingeniería inversa del firmware y encontraron comandos HCI que permiten hacer cosas como leer/escribir memoria, enviar paquetes y configurar la dirección MAC.
No es precisamente una puerta trasera. No sé si los investigadores lo llamaron así, porque la presentación está en español, o si son los periodistas quienes lo llaman puerta trasera para conseguir más clics.
Para usar esos comandos hace falta tener acceso arbitrario para enviar comandos HCI al dispositivo. Es decir, ya se tiene control del dispositivo y de cómo opera. No se explota de forma remota a través del enlace inalámbrico. Cualquier exploit tendría que contar ya con control total del dispositivo, y en ese punto la capacidad de cambiar la dirección MAC o enviar paquetes no es nada sorprendente.
Es una investigación interesante, pero que la empaqueten como “puerta trasera” realmente le quita el entusiasmo. No sé quién tiene la responsabilidad por esa formulación, pero sospecho que son los periodistas.
Como analogía más familiar, imaginen que se descubre que el controlador Ethernet de un chip IoT común puede cambiar la dirección MAC o enviar paquetes arbitrarios siguiendo instrucciones del firmware. Es lo mismo, solo que con Bluetooth.
https://www.tarlogic.com/news/backdoor-esp32-chip-infect-ot-...
Por eso existen herramientas para Windows como https://macaddresschanger.com/ y bdaddr en Linux. La mayoría parecen clones del diseño de CSR, y el comando para configurar la dirección también es bien conocido. https://sources.debian.org/src/bluez/5.55-3.1%2Bdeb11u1/tool...
Y encima se eliminó el requisito del cable Ethernet.
Puedes andar en una van blanca que diga “Free Candy / BLE Persistent Threats” y, de camino a China, vaciar dispositivos mientras pasas por un detector de metales.
Es inalámbrico, puede propagarse como un gusano, envía paquetes arbitrarios y puede suplantar dispositivos arbitrarios, ¿y aun así no ves el problema?
Detesto este tipo de artículos sensacionalistas. Ahora parece que Espressif va a sentirse presionada para volverse más cerrada.
Instalamos sin pensarlo drivers blob binarios opacos que corren en espacio de kernel en desktops y laptops, y ni siquiera tenemos acceso root en nuestros propios teléfonos controlados por la nube, pero unos cuantos comandos de bajo nivel no documentados del ESP32, que requieren que el dispositivo ya esté comprometido, se vuelven un vector de amenaza digno de noticia.
De verdad me pregunto si no se perdió algo en la traducción. Antes simplemente me habría parecido genial y habría intentado encontrar la forma de convertirlo en una radio definida por software.
La investigación en sí está bien, pero el título es malo. Como vector de ataque, requiere acceso físico y, en casi todos los casos, es algo que ya se podría hacer por otros medios.
Un título mejor sería algo como “Descubren comandos no documentados en un chip Bluetooth común”.
Ese título es mentira. Una puerta trasera en un chip Bluetooth debería permitir que un atacante inalámbrico obtenga ejecución de código en el chip.
Este artículo trata sobre que el driver de dispositivo del equipo conectado pueda obtener ejecución de código en el chip, lo cual no viola ningún límite de seguridad.
En un ecosistema mediático que funcionara correctamente, haría falta una corrección, y la reputación del medio que publicó el artículo debería sufrir un golpe importante. Lamentablemente, eso no va a pasar.