Pwnd Blaster: hackear una PC a través de un parlante sin tocar el parlante en absoluto

• Creative Sound Blaster Katana V2X puede ser convertido por un atacante dentro de un rango Bluetooth de unos 15 m en un dispositivo de vigilancia o un Rubber Ducky remoto, ejecutando comandos CTP y actualizaciones de firmware sin emparejamiento ni contacto físico
• CTP sobre USB requiere autenticación challenge-response basada en una clave estática, pero la ruta por Bluetooth acepta los mismos comandos CTP sin autenticación a través de una característica GATT, permitiendo leer información y cambiar configuraciones
• El contenedor de firmware está compuesto por FBOOT, FMAIN y CHK2, y sin verificación de firma acepta firmware modificado siempre que coincida el checksum SHA-256 de CHK2
• La PoC subió un firmware personalizado por BLE durante unos 10 minutos y luego, tras reiniciarse, hizo que el parlante actuara como un teclado HID USB para escribir y ejecutar echo pwned
• Creative, tras ser contactada por medio de SingCERT, dijo que “no presenta un riesgo de ciberseguridad” y no lo consideró una vulnerabilidad; el firmware más reciente sigue siendo vulnerable y solo existe un parche no oficial que bloquea CTP-over-Bluetooth

---

Punto clave de la vulnerabilidad

• El Katana V2X es una barra de sonido que se conecta a una PC por USB, y la app de Creative cambia configuraciones como DSP, LED y fuente de salida mediante CTP
• Para escribir comandos CTP por USB, primero hay que pasar por una autenticación challenge-response, y la clave es un valor estático que puede derivarse del binario incluido en Creative App
• Las actualizaciones de firmware también se ejecutan sobre CTP, y la imagen inicial del firmware se extrajo capturando tráfico USB con Wireshark
• En Bluetooth Low Energy, a veces es posible conectarse al dispositivo y leer o escribir características GATT sin emparejamiento; el emparejamiento crea cifrado, pero no siempre es necesario para la conexión en sí
• Dentro del firmware del Katana V2X, el manejador interno de CTP estaba conectado no solo a USB sino también a Bluetooth, y al escribir 5a 09 01 02 en la característica 9e9daaec-3a10-4fe8-b69f-7397aff77886 desde una laptop, se pudo leer la cadena completa de versión del firmware desde la característica 9e9daaeb-3a10-4fe8-b69f-7397aff77886

Verificación del firmware y cadena de ataque OTA

• El contenedor de firmware incluye FBOOT, relacionado con el modo de recuperación, el firmware principal FMAIN, que se ejecuta en el arranque normal, y CHK2, un checksum SHA-256 del contenedor completo
• FBOOT y FMAIN son código basado en FreeRTOS, como indica la cadena /home/jieyi/mcuos2.5/kernel/freertos-8.2.3/, y FMAIN es unas 6.5 veces más grande que FBOOT
• El dispositivo aceptó firmware modificado siempre que CHK2 fuera correcto, y al flashear un firmware que cambiaba la cadena WELCOME por PATCHED, al arrancar se mostró PATCHED en la pantalla de segmentos
• Un script en Python que reimplementó el mismo procedimiento de actualización de firmware por BLE subió firmware personalizado sin emparejamiento ni autenticación, y por la velocidad de BLE tardó unos 10 minutos en completarse
• El parlante tiene micrófono, por lo que existe la posibilidad teórica de que un firmware personalizado funcione como un dispositivo de monitoreo encubierto que escuche conversaciones y las envíe por Bluetooth a un receptor

Método de inyección como teclado USB

• El Katana V2X funciona en su configuración normal como un dispositivo confiable conectado por USB a la PC
• Aunque el dispositivo no es ya un teclado completo, sí se configura como un dispositivo HID Consumer Control para controles multimedia como volumen y reproducir/pausar
• Se pudo modificar el descriptor de reportes USB del firmware para añadir un segundo elemento de report descriptor y hacer que el dispositivo también se anunciara como teclado
• Dentro del firmware ya existía una rutina para enviar datos HID, y era posible mandar pulsaciones de teclas llamándola con los datos de tecla presionada y tecla liberada
• En lugar de desviar de forma compleja el flujo de ejecución, se sobrescribió una tarea diagnostic de FreeRTOS que parecía no hacer nada especial durante el uso normal, para ejecutar código personalizado al arrancar
• Esa tarea espera unos 20 segundos a que el subsistema USB esté listo, luego escribe echo pwned a intervalos de unos 20 ms, presiona Enter y termina
• El parche final estaba compuesto por un reporte USB de 83 bytes, 102 bytes de ensamblador ARM/Thumb para el inyector de teclas y 2 bytes por cada pulsación a transmitir
• En un ataque real, podría abrirse un programa como powershell.exe y pegar un comando malicioso de una sola línea, y si el atacante desactiva las rutinas de actualización de firmware tanto del modo normal como del modo de recuperación, podría volver imposible eliminar el firmware malicioso y aplicar futuros parches
• El Bluetooth del parlante permanece siempre encendido incluso en modo de ahorro de energía, y no parece haber forma de apagarlo

Mitigación y cronología de divulgación

• Creative no tenía un contacto público de seguridad, y también era difícil encontrar un medio de contacto general aparte del formulario de soporte del sitio web
• Tras dos intentos de contacto por el formulario de soporte, SingCERT participó como mediador
• Creative respondió a SingCERT casi dos meses después y dijo que “no presenta un riesgo de ciberseguridad, por lo que no lo consideramos una vulnerabilidad”
• No hay un parche provisto por Creative y el firmware más reciente sigue siendo vulnerable
• La mitigación no oficial bloquea CTP-over-Bluetooth y es muy probable que la app móvil de Creative deje de funcionar con este cambio
• v2x-patcher descarga el firmware oficial desde los servidores de Creative, lo parchea en memoria y luego lo sube por USB a un Katana V2X conectado
• Todas las pruebas y el trabajo de ingeniería inversa se realizaron con la versión de firmware 1.3.230619.1820

Detalles de ingeniería inversa

• FMAIN.bin no era una sola imagen sino una estructura scatter-loaded, donde distintos offsets de archivo se cargan en diferentes direcciones
• El análisis automático de Ghidra requería la dirección base correcta y el mapa de memoria; después de inferirlos y aplicar un diseño validado mediante lecturas de memoria del dispositivo, se obtuvieron resultados de análisis válidos
• Los punteros a cadenas no se cargaban directamente sino mediante pares movw y movt; un script que buscaba pares cargados en el mismo registro y creaba referencias DATA cuando apuntaban a memoria válida generó unas 13 mil referencias
• Para probar sin reflashear el firmware cada vez, se sobrescribió el manejador de eco del opcode CTP 0x54 para que procesara comandos de lectura, escritura y ejecución
• El manejador personalizado final ocupó 96 bytes y cabía dentro del tamaño del manejador original, de unos 106 bytes
• Al ejecutar múltiples pulsaciones con mem-exec en el contexto de la tarea de procesamiento USB, las demoras vTaskDelay se acumulaban y el dispositivo se reiniciaba por el watchdog por tarea
• Al inyectar el código de teclado en la tarea de servicio diagnostic en vez de llamarlo directamente desde la tarea USB, el problema del watchdog desapareció

[GN⁺]

Comentarios de Hacker News

• Da risa ver comentarios de gente que claramente no leyó bien el artículo, o directamente no lo leyó. Esto es básicamente como un bucket S3 público en la placa de un dispositivo Bluetooth
  Aun así, el trabajo en sí está buenísimo. Pensé que sería mucho más difícil convertir un dispositivo conectado por USB en una vía de ataque, pero resulta bastante gracioso que alcance con hacerlo pasar por un teclado, abrir una terminal local y ejecutar comandos maliciosos. Como no es una terminal con privilegios de administrador, el daño queda algo limitado, pero en Windows muchos usuarios simplemente aceptan el prompt de UAC, así que probablemente se podría obtener acceso total en bastantes PCs

• Según un correo de SingCERT, el fabricante dijo que “esto no crea un riesgo de ciberseguridad, por lo tanto no lo consideramos una vulnerabilidad”. O sea, escribir firmware arbitrario por vía inalámbrica en un dispositivo conectado por USB a la computadora de otra persona, sin siquiera emparejarlo, no sería una vulnerabilidad de seguridad

  • Es la lógica de “solo se puede hacer que escriba texto, ¿qué riesgo podría haber?”
    Hace preguntarse cuántas empresas de periféricos más operan aparentemente sin equipo de seguridad. Probablemente haya muchas más vulnerabilidades de este tipo que aún no se han descubierto. A mi hermano una vez lo despertaron a las 2 de la mañana unos chicos del vecindario que se conectaron por Bluetooth a su parlante y pusieron sonidos de pedos en bucle al volumen máximo; eso apenas es la punta del iceberg del uso malicioso de Bluetooth
  • Si alguien va a un showroom de Creative, a un evento de ventas o al CES y “parchea” todos los dispositivos, esa respuesta va a cambiar muy rápido
  • Esa cita sobre el riesgo parece malinterpretar por completo el concepto de riesgo. Primero existe la vulnerabilidad, y solo después, al agregar impacto y probabilidad, aparece el riesgo
    Por definición, siempre existen vulnerabilidades de bajo riesgo porque tienen poco impacto o baja probabilidad. Los CVE tienen puntajes, pero el riesgo real y si se acepta antes o después de mitigar depende del caso de uso. “No hay riesgo => no hay vulnerabilidad” es un razonamiento erróneo por diseño; como mucho se puede aceptar “no hay vulnerabilidad => no hay riesgo”
  • Lo mismo podría decirse de cualquier computadora que ejecute macOS o Windows. El simple hecho de poder ejecutar tu propio software no necesariamente es una vulnerabilidad
    Pero sí es raro que la interfaz para volver a flashear esté expuesta por Bluetooth. Según entiendo, para emparejarse con el parlante debería hacer falta acceso físico
    Corrección: estaba equivocado. Este es un endpoint BTLE que funciona sin emparejamiento. En ese caso, es una vulnerabilidad completamente absurda. Ojalá la parcheen sin quitar la capacidad de ejecutar tu propio software
  • Ya ni recuerdo qué había aprendido hace años sobre Creative Labs, pero al meterme en este tema tenía la certeza de que, de una forma u otra, Creative Labs la iba a arruinar

• El artículo está bien escrito y es fácil de entender, vale la pena leerlo aunque sea por encima
  En resumen, encontraron una forma de hacer reescritura arbitraria de firmware por Bluetooth en la soundbar Creative Sound Blaster Katana V2X, sin necesidad de autenticación real ni interacción del usuario
  Como esta soundbar se conecta directamente por USB a la computadora host, pudieron agregar descriptores al firmware para que fuera reconocida como teclado. Después de eso, fue sencillo enviar pulsaciones al PC. La soundbar también tiene micrófono, así que un atacante podría convertirla en un dispositivo de escucha
  Lo reportaron a Creative y a SingCERT, pero la empresa recién respondió dos meses después diciendo que “no crea un riesgo de ciberseguridad, por lo tanto no lo consideramos una vulnerabilidad”
  El autor publicó un parcheador de firmware que desactiva el protocolo de transporte defectuoso. Es un método algo tosco, que incluso podría romper funciones de la app oficial de Bluetooth, pero parece ser lo mejor que se puede hacer sin cooperación del fabricante

• Incluso fabricantes antiguos a menudo construyen primero el dispositivo y luego le pegan el software como si fuera algo secundario. Casi no prestan atención al ciclo de vida del software: ni a la seguridad, ni a los parches, ni a las actualizaciones, ni a los cambios del ecosistema
  Incluso he visto casos en los que la marca del dispositivo encargó el software a una pequeña firma tercerizada, y luego esa empresa cerró, desapareció o abandonó el negocio, y el fabricante ni siquiera se quedó con el código fuente. Entonces ya no tienen capacidad de mejorar o corregir el software que hace funcionar el dispositivo, y después se van acumulando capas y capas de middleware, UI y conexiones improvisadas

  • Da miedo lo seguido que pasa esto. En una situación como la actual, donde se venden en masa periféricos baratos para computadoras y teléfonos a cada minuto, tampoco hay una forma realista de que alguna entidad supervise y regule todo esto
    De hecho, me imagino que no pocos dispositivos tienen firmware escrito no por un “pequeño desarrollador tercerizado”, sino por alguien más parecido a un hacker de la cadena de suministro

• ¿Por qué pensar tan en chico? También podrías usar al propio parlante como atacante
  Cualquier script kiddie con acceso a un LLM podría crear un gusano que se propague por la cadena de suministro. Hasta podría hackear parlantes directamente en la planta de fabricación y hacer que reproduzcan algo como un Rickroll
  Me pregunto si incluso en ese caso Creative seguiría diciendo que “no crea un riesgo de ciberseguridad”
  Como extra, si cierran el agujero de seguridad desactivando también la función legítima de flasheo de firmware, entonces para reparar el parlante el fabricante tendría que hacerle jailbreak, así que puntos extra

  • Basta con flashear un gusano en el dispositivo y mandarlo por RMA
  • Antes probablemente se podía. Los modelos más recientes están imponiendo restricciones cada vez más fuertes y descartando los modelos viejos, al punto de pedir hasta identificación oficial del gobierno

• No se ve nada bien que el autor haya tenido que publicar un parche de terceros porque el fabricante no lo considera una vulnerabilidad

  • ¿De verdad sorprende? El hack del autor es excelente y, si fueras un objetivo, el impacto podría ser grande, pero en términos generales el impacto es muy pequeño. El fabricante no tiene muchos motivos para preocuparse
    Para ser víctima, tendrías que tener este dispositivo, el atacante tendría que saberlo y además tendría que estar cerca. Basta recordar el diálogo de Fight Club
    A = número de parlantes desplegados en el campo
    B = porcentaje con probabilidad de ser hackeados
    C = monto promedio de acuerdo extrajudicial
    Decisión: si el costo de no hacer retiro ni reparación es mayor que el costo del retiro, entonces se inicia el retiro. El costo más grande sería que la gente dejara de comprar sus parlantes en el futuro, pero no parece que eso vaya a pasar

• Si yo estuviera a cargo de una organización como el Mossad, gastaría una gran parte del presupuesto en comprar todos los dispositivos Bluetooth del mercado, contrataría a graduados israelíes de informática que estén con poco trabajo para encontrar vulnerabilidades como esta, y luego lo convertiría en un conjunto de herramientas fácil de desplegar
  Por ejemplo, querrías que un activo con acceso a oficinas del gobierno iraní caminara por el edificio con un celular y lograra comprometer tantas computadoras como fuera posible. Ahora que lo pienso, probablemente hay que asumir que de hecho ya lo están haciendo

  • Va un poco en la dirección contraria. Para empezar, en Israel no hay tantos graduados en informática. Los mejores talentos ya pasan por la Unidad 8200
    En la práctica, es casi como una maestría totalmente subsidiada en ingeniería informática, y al ser una organización de inteligencia de señales, ahí aprenden este tipo de cosas. Cuando terminan sus 2 o 3 años de servicio, no tienen deuda estudiantil, el gobierno aporta bastante capital semilla para startups, y el ecosistema de TLV funciona como una pequeña Bay Area
    También es más aceptado socialmente vivir con los padres, así que una parte importante de la gente en sus 20 no tiene deudas, tiene gastos mensuales bajos, cuenta con sólidas capacidades técnicas adquiridas en el servicio militar, está en un centro de emprendimiento y tiene buen acceso a capital. Como resultado, salen muchos unicornios, especialmente en ciberseguridad(https://www.techaviv.com/unicorns)
    En comparación, en EE. UU. tienes que dedicarte a una licenciatura de 4 años, endeudarte mucho, pagar renta y batallar para conseguir capital semilla. La mentalidad de “bueno, supongo que podemos aprovechar un poco los restos de un sistema roto” pierde de vista la perspectiva de tener un sistema exitoso desde el principio
  • Este tipo de entrenamiento probablemente sería un error de redondeo en el presupuesto de seguridad nacional o inteligencia de cualquier país. Ahora incluso se podría automatizar con IA el barrido inicial de dispositivos y la selección de candidatos para análisis manual
    Me sorprendería bastante si esto no fuera una práctica estándar. Aunque también podría ser que la productividad real sea menor de lo que parece y no valga la pena el esfuerzo. Aun así, este caso sugiere que sí podría rendir resultados, y habría que compararlo con otros métodos de los servicios de inteligencia que no conocemos
  • En paralelo con esa propuesta, quizá sería más fácil fabricar y vender directamente dispositivos con fallas, es decir, con puertas traseras integradas
    ¿Qué es más fácil, hacer marketing o encontrar bugs? :-)
  • No hay forma de que todos los servicios de inteligencia del mundo no estén haciendo esto
  • NSO Group(https://en.wikipedia.org/wiki/NSO_Group) probablemente sea algo así. Los servicios de inteligencia israelíes podrían estar sembrando vulnerabilidades en dispositivos basura baratos, o en esta basura cara, para que NSO u organizaciones israelíes parecidas a NSO las aprovechen. Ya sabemos que venden bípers

• Escribo firmware, especialmente firmware para dispositivos con soporte Bluetooth, y en mi empresa bloquearon este sitio web

• La gente que ama la tecnología compra una bocina ultrainteligente que se conecta a todas las computadoras de la casa y hasta controla una cafetera ultrainteligente para servir café recién hecho cuando suena Miles Davis
  La gente que entiende la tecnología pone un hacha junto al tostador

  • Ese es el significado original de hacker

• Ya hasta me emociona que algún canal hecho al aventón saque un video sobre esto y me lo ponga en la portada de YouTube como dentro de 4 días hábiles

  • ¿Sabías que si desactivas el guardado del historial de reproducciones de YouTube, puede que la portada desaparezca por completo?
  • Aun así, primero lo subirán a LinkedIn y se llevarán todo el prestigio