La interfaz de audio tiene SSH habilitado por defecto

 (hhh.hn)
1 puntos por GN⁺ 5 일 전 | 1 comentarios | Compartir por WhatsApp
  • Al descomprimir el archivo de firmware se pudo revisar fácilmente la estructura interna del dispositivo, y el Rodecaster Duo tenía SSH abierto por defecto
  • El paquete de actualización tenía formato de gzipped tarball, y el dispositivo incluía dos particiones para arrancar desde la otra en caso de daño, además de scripts de shell para la actualización
  • El firmware entrante no tenía verificación de firma, y se confirmó acceso SSH real por conexión Ethernet, con solo autenticación por clave pública permitida
  • En Windows, al capturar el flujo de actualización por USB, se confirmó que la entrada al modo de actualización y la ejecución del flasheo se hacían con comandos ASCII de un solo carácter, M y U; después de copiar archive.tar.gz y archive.md5, el nuevo firmware se instalaba tras reiniciar
  • En macOS fue posible llegar a una conexión real creando firmware personalizado para activar la autenticación por contraseña en SSH y añadir una clave pública; nunca se aclaró por qué SSH venía habilitado por defecto ni por qué incluía claves preinstaladas

Actualización de firmware y SSH habilitado por defecto

  • En el Rodecaster Duo era fácil ver los archivos transferidos al dispositivo durante el proceso de actualización de firmware, y SSH estaba habilitado en el estado predeterminado
    • En macOS se rastreó la actividad del disco para encontrar dónde se guardaba el firmware, y el firmware tenía un formato simple de gzipped tarball
    • En el dispositivo donde se intentó actualizar, la escritura al disco USB estaba deshabilitada, por lo que esa actualización falló
  • Dentro del dispositivo había binarios ejecutables y scripts de shell para la actualización, y el disco tenía dos particiones para arrancar desde la otra si una se dañaba
    • El firmware entrante no tenía verificación de firma
    • Al conectar un cable Ethernet se comprobó que SSH realmente estaba abierto, con solo autenticación por clave pública permitida
  • Se identificaron dos claves SSH agregadas por defecto
    • ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCX/bCFTDgViuPvdFL/VMMVRrw9b5S8HcDQk17qoCEYwmI+IIG8rEAsLiaeCOwyhf9IN+8/LRaN0Z5ZfU3WMbmsKEg8zd1Yvqq74nFbhO47vbtzmCi9S4ucIKkBEVOyvyN5lt9hWf5t5nZSmlfldZK3Pem5y8wHM5A+K/gSnzp4gwQ1QYfFb068uQ+ciIdOhb8SkUs8CwzotglIbp19I6ZmXmsNj/TmpbUf5rMfUAf1gysZ5j1UdRWrvWVh5daqvZRsBBPbXEeJfDU3Nr3HR14XYt9mgexrz/5oyKSj/lQYLmh9cDfsxvkGNIQ8fF9l+n2L1KZM4lLgiGk4KFBjQHaIBZx9OebCiiZCO4NTJUBDk9a+SZpiDiipADV07s7vTInYyFA6GrmKtnq3M6upT4WJBvVuL/BMnK5yY1RZtoqox2/pcCg2rH5S1GIy0v0HFJisl7kWInlaG2mdsaCx19wAjCFe/qT9LyxjQ6+0rArI55/JJFDkNeMjrewRQwNdASjCox8vqXCBfjvsR9qv70/ywcymgsnLAnq2LuYg5FYwMMDYOvVnhACC+BYTdNDTn5oeMIjQCUenY/DPCHpJkf4YOf3YCMUTEU9tExhtwW/X+m21hS3+STLtTfqbUeg9CeuPQZgfl9vc65n3tMxAdlEGEDoTaNMAgr2TzJv92Ka9iQ==
    • ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDaNyzPfIcEeQsfzyQs/wyX6mX52kiS+4eNHfCaxFlgj

Flujo de actualización y firmware personalizado

  • En Windows se capturó el tráfico de actualización con Wireshark y USBPcap para revisar el flujo de control que la app RODECaster enviaba al dispositivo
    • Existían el comando 'M' para poner el dispositivo en modo de actualización y el comando 'U' para ejecutar la actualización
    • Ambos comandos se enviaban como un solo carácter ASCII en el HID report 1
  • La estructura real de la actualización era simple
    • Después de enviar el comando M, se copiaban archive.tar.gz y archive.md5 al disco recién expuesto
    • archive.md5 era el valor md5sum del archivo
    • Después se desmontaba el disco y se enviaba el comando U; entonces comenzaba el flasheo y luego el dispositivo reiniciaba con el nuevo firmware
  • En macOS se creó firmware personalizado usando un contenedor para activar la autenticación por contraseña en SSH y añadir una clave pública propia a authorized keys
    • Un ejemplo mínimo de las funciones necesarias para el flasheo puede verse aquí
    • Tras ejecutar el script y flashear, fue posible conectarse al dispositivo por SSH
  • Este dispositivo permitía flashear firmware con mucha facilidad, y no se pudo determinar por qué SSH venía habilitado por defecto ni por qué incluía claves preinstaladas
    • El problema se reportó a RODE mediante un ticket, pero no hubo respuesta
    • Se seguirá revisando si hay cambios en futuras actualizaciones de firmware

Lecturas relacionadas

1 comentarios

 
GN⁺ 5 일 전
Comentarios de Hacker News
  • Lo que siempre me frustra en este tipo de historias es que firmware firmado y firmware abierto no son opuestos por naturaleza
    Está bien que la verificación venga activada por defecto, pero quien compró el hardware debería poder registrar sus propias claves, cambiar un jumper o mantener presionado un botón al arrancar para tomar el control del propietario
    En la práctica, los únicos que realmente ofrecen algo así son algunas Chromebook y equipos de red, así que cada vez que sale el tema de la seguridad del firmware todo termina en una pelea entre "cerrémoslo por completo" y "dejémoslo totalmente abierto", y desaparece la idea de que decida quien pagó por el dispositivo
    Que Rode distribuya esto como tarball + hash me parece excelente, y aunque luego lo hagan más estricto, ojalá siga siendo de una forma que me permita instalar en mi equipo lo que yo quiera
  • Me encanta que la imagen de firmware sea simplemente tarball + hash
    Ojalá hubiera más dispositivos abiertos así, y espero que Rode no vea esto y termine bloqueando las actualizaciones de firmware
    • Si alguien de Rode llega a ver esto, justo por cosas como esta dan ganas de comprar el equipo
      Por favor no lo cambien
    • Hace unos años tuve que actualizar el firmware de una impresora HP, y me gustó lo sorprendentemente simple que era el proceso
      Era una impresora de alrededor de 2009, y para subirle la RAM a 256 MB necesitaba una actualización de firmware; bastaba con enviarle el tarball por FTP a través de la red
      Lo hice con FileZilla, estuvo trabajando unos minutos y la actualización terminó de inmediato, y desde entonces me quedó la sensación de que no hay razón para que actualizar firmware sea más complicado que eso
      Aunque haya una verificación tipo checksum por seguridad, estaría bien que simplemente te dejaran subir un blob por FTP, SCP o SFTP y listo
    • Aun así, creo que tiene sentido que el comando de actualización solo se habilite mediante algo como un botón físico
      Debería requerir entrar en una especie de DFU mode; de lo contrario, cualquier cosa con acceso al USB podría empujar firmware incorrecto y dejar el dispositivo brickeado
    • Personalmente no quiero que mi interfaz de audio esté corriendo SSH, ni que exista una forma de que alguien agregue una authorized key arbitraria
  • Habría sido más interesante si el título fuera Mi interfaz de audio es una computadora Linux de 64 bits
    Hace 10 o 20 años, algo así probablemente se habría implementado en un SoC pequeño de 16 o 32 bits con un RTOS como VxWorks
    Como además tiene muchos controles físicos, hasta parece natural que el siguiente paso sea convertirla en una consola de videojuegos
    • Mi interfaz de audio en realidad también es una computadora Linux y por dentro tiene un FPGA que de verdad se programa en campo
      Encima tiene dos puertos 1GbE y cada uno se comunica con una parte distinta del equipo
      Pero este tipo de arquitectura no es tan rara en el mundo del audio profesional; en un escritorio de casa impresiona, pero dentro de la industria es bastante normal
      Quizá la historia se ponga más interesante después de sacarle un root shell o dejarla brickeada
    • Tu video dongle también puede ser una computadora Unix: https://www.macrumors.com/2025/02/04/doom-apple-lightning-hdmi-adapter/
    • Hoy en día sigue habiendo presión de RAM/storage, pero los chips son tan baratos
      que tampoco es fácil ganarle a Linux en costo y compatibilidad
  • Cuando un dispositivo empieza a llevar un DSP decente, esta clase de arquitectura es bastante común
    Normalmente abajo hay un Linux mínimo corriendo en un ARM SoC, y a veces el BSP del proveedor sale accidentalmente con sshd activado
    No tanto por mala intención, sino más bien porque en audio a menudo no hay nadie realmente a cargo del rootfs
    Lo importante es si esto solo está expuesto en la red del lado USB o si también está abierto en la LAN real
    Lo primero es una molestia; lo segundo sí preocupa de verdad
    • Lamentablemente, los valores por defecto de Linux no son muy buenos para fabricar este tipo de dispositivos en masa
      En comparación, Android separa las imágenes base en eng / userdebug / user, así que con solo elegir bien la configuración predeterminada es más fácil evitar este tipo de errores
    • Esto de hecho también está escuchando en la LAN
      Solo se conecta por Wi‑Fi cuando se usa cierta función, así que no pude verificar si esa interfaz también queda expuesta
  • Todavía me sorprende sentir que ahora cualquiera lleva un AI-hacker en el bolsillo
    Solo se lo pasas a un agente y en unos minutos inspecciona el firmware y te da una forma de modificar el dispositivo
    Hasta el año pasado, esto era algo que como mínimo requería un hacker nivel Hotz, o a alguien dispuesto a insistir y escarbar durante muchísimo tiempo
    • Eso no es cierto en absoluto
      Es verdad que los LLM han facilitado mucho el análisis, el debugging y los bypasses, pero este dispositivo tenía un nivel de protección tan bajo que alguien con habilidad intermedia, motivación y tiempo habría podido hacerlo igual
      No había firmware cifrado, ni verificación de firma, e incluso ya traía acceso por SSH integrado
      En cambio, el hipervisor de la PS3 que rompió George Hotz estaba diseñado para ser muchísimo más resistente desde la perspectiva del atacante, y el exploit real llegó a requerir incluso voltage glitching con FPGA
      En ese tipo de ataques, los LLM pueden ayudar, pero como no tienen un ciclo de retroalimentación completo, sigue haciendo falta mucho trabajo humano
      https://rdist.root.org/2010/01/27/how-the-ps3-hypervisor-was-hacked/
    • Por lo que se ve en el artículo, Claude Code básicamente se usó como reemplazo de Wireshark y Google para interpretar tráfico USB HID y encontrar documentación del protocolo
      Si no tienes Wireshark instalado, quizá te ahorre algo de tiempo, aunque con cierto riesgo de alucinaciones
      Fuera de eso, lo único que hizo fue modificar ~root/.ssh/authorized_keys y /etc/shadow dentro del tarball del firmware en Docker, enviar los mensajes HID correspondientes y usar un script sencillo en Python para copiar el tarball modificado al volumen que el dispositivo expone como si fuera una unidad USB
      Así que esto no requería un hacker fuera de serie, sino más bien conocimientos básicos de sysadmin de Linux y la capacidad de unir una librería USB HID con un programita trivial
      Sí me desconcertó por un momento por qué había instalado el paquete whois en un contenedor Ubuntu, pero luego tuvo sentido al recordar que en Debian y derivados mkpasswd está ahí por razones históricas
      Además, si el sshd_config del dispositivo estaba intacto, es muy probable que el inicio de sesión como root por contraseña ni siquiera hubiera funcionado desde el principio debido a PermitRootLogin
      https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=116260
    • Yo también usé IA para habilitar SSH en uno de mis Phase One digital back, y en otro hice ingeniería inversa del firmware y lo parcheé para que se identificara como otro modelo
      Hice pasar un Credo 50 por un IQ250, aunque por dentro son prácticamente lo mismo
    • Antes había que pasarse horas revisando capturas de paquetes y todo tipo de datos, así que se agradece ya no tener que gastar ese tiempo
      Meterse a fondo sigue siendo divertido, pero conforme uno envejece se vuelve difícil dedicarle 16 horas seguidas a un blob de firmware cualquiera
    • En la mayoría de los casos, un LLM no puede hacer ese nivel de trabajo
      Además, manejar un dispositivo con SSH abierto tampoco requiere ninguna habilidad especial
  • Yo tenía exactamente el mismo problema, así que me interesaba muchísimo saber cómo lo resolvió el autor
    Sobre todo la parte de querer jugar y usar Discord en el mismo cuarto, mientras mi novia y yo conectamos cada quien su micrófono a su propia computadora pero sin eco
    • El Rodecaster puede conectarse a dos computadoras
      Ambos entran a la misma llamada de Discord, pero envías los dos micrófonos mezclados como entrada a una sola computadora, y en la otra persona dejas el micrófono silenciado para que el cliente solo reciba audio
      Como la mezcla ocurre localmente, no se genera eco
      Es tan simple que dan ganas de decirte que me escribas por correo si quieres más detalles
    • Hace poco hice medio a la rápida un jack mixer en Rust, como con vibe coding, y puede recibir audio por la LAN y volver a enviarlo
      La latencia ronda los 40 ms, o unos 50–60 ms si pasa por Wi‑Fi
      Puedes correr el mixer en una PC, tomar el micrófono local como un canal de entrada, y hacer que la otra PC transmita su micrófono para meterlo como canal 2 del mixer; así se puede resolver algo parecido
      También puedes reproducir música desde la PC local, y el mixer o el broadcaster pueden crear un sink local
      Al final mezclas todo en el mixer y mandas la salida principal a Discord, mientras la línea de monitoreo saca el audio de Discord y luego lo retransmite de vuelta a la otra PC para usarlo en escucha en tiempo real
    • También me da la impresión de que esto se resolvería con un headset con micrófono boom direccional
      Aunque puede que yo haya entendido mal la situación
  • El artículo está muy bueno y el dominio también está genial
    No conozco bien Zola, así que no sé si es una plantilla común o algo personalizado, pero se ve muy bien
  • Parece que muchos proveedores entienden security prácticamente como sinónimo de prevención de copias
    Por eso probablemente fuerzan cosas como las imágenes firmadas
  • Me preguntaba por qué el objetivo era la divulgación
    Para una interfaz como esta, hasta parecería mejor dejarlo abierto
    • No era necesariamente el objetivo, y yo también espero que RODE lo siga dejando abierto
  • La gente de Rode en Australia suele ser relativamente accesible, así que si hubiera algo que reportar, hasta parecería viable simplemente llamarlos
    Al fin y al cabo por allá casi hablan inglés, así que seguramente se entenderían