Interface de áudio vem com SSH ativado por padrão

 (hhh.hn)
1 pontos por GN⁺ 5 일 전 | 1 comentários | Compartilhar no WhatsApp
  • Ao descompactar o arquivo de firmware, foi possível verificar facilmente a estrutura interna do dispositivo, e o Rodecaster Duo veio com o SSH aberto por padrão
  • O pacote de atualização tinha formato de gzipped tarball, e o dispositivo continha duas partições para inicialização pela outra em caso de corrupção, além de scripts shell de atualização
  • O firmware recebido não tinha verificação de assinatura, o acesso SSH foi confirmado de fato por uma conexão Ethernet, e estava configurado para permitir apenas autenticação por chave pública
  • No Windows, ao capturar o fluxo de atualização via USB, foi confirmado que a entrada no modo de atualização e a execução do flashing ocorriam com comandos ASCII de um único caractere, M e U; após copiar archive.tar.gz e archive.md5, o novo firmware era instalado com uma reinicialização
  • No macOS, com um firmware personalizado, foi possível ativar autenticação SSH por senha e adicionar uma chave pública para efetivamente acessar o dispositivo; o motivo de o SSH vir ativado por padrão e com chaves incluídas nunca foi esclarecido

Atualização de firmware e SSH ativado por padrão

  • No Rodecaster Duo, foi possível inspecionar facilmente os arquivos enviados ao dispositivo durante o processo de atualização de firmware, e o SSH estava ativado por padrão
    • No macOS, o local de armazenamento do firmware foi encontrado rastreando a atividade de disco, e o firmware tinha o formato simples de um gzipped tarball
    • No dispositivo em que a atualização foi testada, a função de escrita no disco USB estava desativada, então essa atualização falhou
  • Dentro do dispositivo havia binários executáveis e scripts shell de atualização, e o disco tinha duas partições, permitindo inicializar pela outra caso uma fosse corrompida
    • O firmware recebido não tinha verificação de assinatura
    • Ao conectar um cabo Ethernet, foi confirmado que o SSH realmente estava aberto, com configuração para permitir apenas autenticação por chave pública
  • Foram identificadas duas chaves SSH adicionadas por padrão
    • 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

Fluxo de atualização e firmware personalizado

  • No Windows, com Wireshark e USBPcap, foi capturado o tráfego da atualização para verificar o fluxo de controle que o app RODECaster enviava ao dispositivo
    • Havia o comando 'M' para colocar o dispositivo em modo de atualização e o comando 'U' para executar a atualização
    • Ambos os comandos eram um único caractere ASCII enviado como HID report 1
  • A estrutura real da atualização era simples
    • Após enviar o comando M, copiavam-se archive.tar.gz e archive.md5 para o disco recém-exposto
    • archive.md5 era o valor de md5sum do arquivo
    • Depois disso, o disco era desmontado e o comando U era enviado; então o flashing começava, e em seguida o dispositivo reiniciava com o novo firmware
  • No macOS, foi criado um firmware personalizado usando container para ativar autenticação SSH por senha e adicionar a própria chave pública às authorized keys
    • Um exemplo mínimo das funções necessárias para o flashing pode ser visto aqui
    • Após executar o script e fazer o flashing, foi possível acessar o dispositivo via SSH
  • O firmware desse dispositivo podia ser gravado com muita facilidade, e o motivo de o SSH vir ativado por padrão e com chaves incluídas continua sem explicação
    • Esse problema foi reportado à RODE por ticket, mas não houve resposta
    • A intenção é continuar verificando se haverá mudanças em atualizações futuras de firmware

Leituras relacionadas

1 comentários

 
GN⁺ 5 일 전
Comentários do Hacker News
  • O que sempre me incomoda nessas discussões é o fato de que firmware assinado e firmware aberto não são opostos por natureza
    Deixar a verificação ativada por padrão é ok, mas quem comprou o hardware deveria poder assumir o controle do proprietário, seja registrando sua própria chave, mudando um jumper ou apertando um botão no boot
    Na prática, quem faz isso é basicamente uma parte dos Chromebooks e alguns equipamentos de rede, então toda vez que o assunto é segurança de firmware a discussão vira uma briga entre “trancar tudo” e “deixar tudo completamente aberto”, e desaparece a ideia de deixar decidir quem pagou pelo equipamento
    O fato de a Rode distribuir como tarball + hash é excelente, e espero que, mesmo se endurecerem mais isso no futuro, continue existindo uma forma de eu instalar no meu aparelho o que eu quiser
  • Gostei muito de a imagem de firmware ser simplesmente um tarball + hash
    Queria que existissem mais dispositivos abertos assim, e espero que a Rode não veja isso e resolva bloquear as atualizações de firmware
    • Se alguém da Rode estiver vendo isso, esse tipo de coisa me dá vontade de comprar o equipamento
      Por favor, não mudem isso
    • Uns anos atrás precisei atualizar o firmware de uma impressora HP, e gostei de como o processo era surpreendentemente simples
      Era uma impressora de mais ou menos 2009, e para aumentar a RAM para 256 MB era necessário atualizar o firmware, mas bastava enviar um tarball por FTP pela rede para a impressora
      Mandei com o FileZilla, ela ficou processando por alguns minutos e a atualização terminou na hora; desde então fiquei pensando por que atualização de firmware precisaria ser mais complicada do que isso
      Mesmo que façam alguma verificação por checksum por questão de segurança, seria ótimo simplesmente subir um blob por FTP, SCP ou SFTP e pronto
    • Ainda assim, acho correto ativar o comando de atualização só com alguma entrada física, tipo um botão
      Deveria ser algo que só funcionasse depois de entrar em uma espécie de modo DFU, porque senão qualquer coisa com acesso ao USB pode empurrar um firmware ruim e transformar o aparelho em um tijolo
    • Pessoalmente, eu não gostaria que minha interface de áudio estivesse rodando SSH, com uma estrutura em que alguém pudesse adicionar uma authorized key arbitrária
  • Teria sido mais interessante se o título fosse minha interface de áudio é um computador Linux de 64 bits
    Há 10 ou 20 anos, algo assim provavelmente teria sido implementado em um pequeno SoC de 16 ou 32 bits com um RTOS como VxWorks
    Como há bastante controle físico, o próximo passo até parece naturalmente transformá-la em um console de videogame
    • A minha interface de áudio na verdade também é um computador Linux, e por dentro tem uma FPGA realmente programada em campo
      Além disso, há duas portas 1GbE, e cada uma se comunica com uma parte diferente da máquina
      Só que esse tipo de configuração nem é tão incomum no mundo do áudio profissional; em cima de uma mesa em casa impressiona, mas na indústria é bem normal
      Talvez a história fique mais interessante depois que alguém conseguir um root shell ou brickar o aparelho
    • Até o seu video dongle pode ser um computador Unix: https://www.macrumors.com/2025/02/04/doom-apple-lightning-hdmi-adapter/
    • Hoje ainda existe alguma pressão de RAM/storage, mas os chips estão tão baratos
      Em termos de custo e compatibilidade, também não é fácil vencer o Linux
  • Quando um dispositivo começa a ter um DSP de verdade, esse tipo de arquitetura é bem comum
    Normalmente há um Linux mínimo rodando em um ARM SoC por baixo, e às vezes o BSP do fornecedor sai de fábrica com o sshd ligado sem querer
    Parece menos malícia e mais falta de alguém no lado de áudio realmente assumir responsabilidade pelo rootfs
    A questão principal é se isso só está aberto na rede USB ou se também está exposto na LAN de verdade
    A primeira opção é só incômoda; a segunda é realmente preocupante
    • Infelizmente, os padrões do Linux não são muito bons para produção em massa desse tipo de dispositivo
      Em comparação, o Android separa imagens padrão em eng / userdebug / user, então só de escolher bem um conjunto de padrões pré-configurados já fica mais fácil evitar esse tipo de erro
    • Isso de fato também está escutando na LAN
      Quando se usa certa funcionalidade ele só se conecta ao Wi‑Fi nesse momento, então não consegui verificar se essa interface também fica exposta
  • Ainda me surpreende que agora todo mundo pareça carregar um AI-hacker no bolso
    Basta jogar isso para um agente e, em poucos minutos, ele já inspeciona o firmware e sugere um caminho para modificar o dispositivo
    Até o ano passado, isso era o tipo de coisa que exigia no mínimo um hacker de nível Hotz, ou então alguém disposto a insistir por muito tempo
    • Isso não é verdade de forma alguma
      É verdade que os LLMs facilitaram muito análise, depuração e bypass, mas este dispositivo tinha um nível de proteção tão baixo que alguém com habilidade mediana e tempo/motivação já conseguiria
      Não havia firmware criptografado, nem verificação de assinatura, e ainda existia acesso SSH embutido
      Já o hypervisor do PS3 que o George Hotz quebrou foi projetado de forma muito mais robusta do ponto de vista do atacante, e o exploit real chegou a exigir voltage glitching com FPGA
      Esse tipo de ataque até pode ser ajudado por LLM, mas como não há um loop de feedback completo, ainda exige bastante trabalho manual
      https://rdist.root.org/2010/01/27/how-the-ps3-hypervisor-was-hacked/
    • Lendo o texto, parece que o Claude Code foi usado basicamente no lugar de Wireshark e Google para interpretar tráfego USB HID e encontrar documentação do protocolo
      Se você não tiver o Wireshark instalado, talvez economize um pouco de tempo, mas também há algum risco de alucinação
      Fora isso, foi só uma questão de editar ~root/.ssh/authorized_keys e /etc/shadow do tarball do firmware dentro de um Docker, mandar as mensagens HID relevantes e usar um script Python simples para copiar o tarball modificado para o volume que o dispositivo expõe como se fosse um drive USB
      Então isso não exige um hacker insano; basta o básico de administração Linux e saber juntar uma biblioteca USB HID com um programinha trivial
      Só fiquei momentaneamente confuso sobre por que instalaram o pacote whois no contêiner Ubuntu, mas em sistemas da família Debian o mkpasswd fica nele por razões históricas, então fez sentido
      E, se o sshd_config do dispositivo estivesse realmente com os padrões intactos, provavelmente login de root por senha nem funcionaria por causa de PermitRootLogin
      https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=116260
    • Eu também usei IA para ativar SSH em um digital back da Phase One que tenho, e em outro fiz engenharia reversa do firmware e o alterei para ser reconhecido como outro modelo
      Enganei um Credo 50 para se passar por IQ250, mas por dentro eles são praticamente iguais
    • Antigamente era preciso passar horas examinando captura de pacotes e um monte de dados; agora é bom não precisar gastar esse tempo
      Fuçar continua sendo divertido, mas conforme a gente envelhece fica mais difícil passar 16 horas grudado em um blob aleatório de firmware
    • Na maioria dos casos, LLM não consegue fazer esse tipo de trabalho nesse nível
      E lidar com um dispositivo com SSH aberto também não exige nenhuma habilidade especial
  • Eu também tinha exatamente esse problema, então fiquei muito curioso sobre como o autor resolveu isso
    Principalmente a parte de querer jogar e usar Discord no mesmo cômodo, enquanto eu e minha namorada conectamos cada um o microfone ao próprio computador, mas sem eco
    • O Rodecaster pode ser conectado a dois computadores
      Basta colocar os dois na mesma chamada do Discord, enviar os dois microfones combinados para a entrada de um dos computadores e deixar a outra pessoa com o microfone mutado, recebendo só o áudio no cliente
      Como a mixagem acontece localmente, não surge eco
      É tão simples que eu quase diria para me mandar um e-mail se quiser mais detalhes
    • Recentemente fiz um jack mixer meio na base do vibe coding em Rust, e ele consegue receber áudio pela LAN e reenviar
      A latência fica em torno de 40 ms, ou 50~60 ms via Wi‑Fi
      Dá para rodar o mixer em um PC, usar o microfone local como um canal de entrada, e o outro PC transmitir o próprio microfone para entrar como canal 2 no mixer, resolvendo de forma parecida
      Também dá para tocar música no PC local, e o mixer ou broadcaster pode criar um sink local
      No fim mistura tudo no mixer, manda a saída principal para o Discord e, na linha de monitoramento, envia o áudio do Discord de volta e o retransmite ao outro PC para escuta em tempo real
    • Fico pensando se isso não seria um problema resolvido com um headset com boom mic direcional
      Claro, talvez eu tenha entendido a situação errado
  • O texto é bom e o domínio também é ótimo
    Não conheço bem Zola, então não sei se é um template comum ou customizado, mas ficou muito bonito
  • Parece que muitos fornecedores tratam segurança praticamente como sinônimo de prevenção contra cópia
    Talvez por isso forcem coisas como imagens assinadas
  • Fiquei curioso sobre por que o objetivo era disclosure
    Para uma interface dessas, eu até imaginaria que seria melhor deixá-la aberta
    • Isso não era necessariamente o objetivo; eu também espero que a RODE continue deixando aberto
  • O pessoal da Rode na Austrália costuma ser relativamente acessível, então se houver algo para reportar, talvez dê até para simplesmente ligar para eles
    Lá eles quase falam algo parecido com inglês, então deve dar para se entender