SSH activé par défaut sur une interface audio

 (hhh.hn)
1 points par GN⁺ 5 일 전 | 1 commentaires | Partager sur WhatsApp
  • En décompressant le fichier de firmware, il était facile d’examiner la structure interne de l’appareil, et le Rodecaster Duo avait SSH ouvert par défaut
  • Le paquet de mise à jour était un gzipped tarball ; l’appareil contenait deux partitions pour démarrer sur l’autre en cas de corruption, ainsi que des scripts shell de mise à jour
  • Le firmware entrant ne faisait l’objet d’aucune vérification de signature ; une connexion SSH effective a été confirmée via Ethernet, avec authentification par clé publique uniquement
  • Sous Windows, la capture du flux de mise à jour USB a montré que l’entrée en mode mise à jour et le flashage s’effectuaient via des commandes ASCII d’un seul caractère, M et U ; après copie de archive.tar.gz et archive.md5, le nouvel appareil redémarrait sur le nouveau firmware
  • Sous macOS, un firmware personnalisé a permis d’activer l’authentification SSH par mot de passe et d’ajouter une clé publique, rendant l’accès effectif possible ; la raison de l’activation de SSH par défaut et de la présence de clés par défaut n’a finalement pas été élucidée

Mise à jour du firmware et activation de SSH par défaut

  • Le Rodecaster Duo permettait de voir facilement les fichiers transmis à l’appareil pendant le processus de mise à jour du firmware, et SSH y était activé par défaut
    • Sous macOS, le suivi de l’activité disque a permis de trouver l’emplacement de stockage du firmware, qui se présentait comme un simple gzipped tarball
    • Sur l’appareil ayant servi aux essais, l’écriture sur le disque USB était désactivée, ce qui a fait échouer cette mise à jour
  • À l’intérieur de l’appareil se trouvaient des binaires exécutables et des scripts shell de mise à jour, et le disque comportait deux partitions afin de démarrer sur l’autre si l’une était corrompue
    • Le firmware entrant ne faisait l’objet d’aucune vérification de signature
    • Après connexion d’un câble Ethernet, il a été confirmé que SSH était effectivement ouvert, avec authentification par clé publique uniquement
  • Deux clés SSH ajoutées par défaut ont été identifiées
    • 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

Flux de mise à jour et firmware personnalisé

  • Sous Windows, Wireshark et USBPcap ont permis de capturer le trafic de mise à jour et d’observer le flux de contrôle envoyé par l’application RODECaster à l’appareil
    • Il y avait la commande M pour faire passer l’appareil en mode mise à jour et la commande U pour lancer la mise à jour
    • Dans les deux cas, il s’agissait d’un caractère ASCII unique envoyé via le rapport HID 1
  • La structure réelle de la mise à jour était simple
    • Après envoi de la commande M, archive.tar.gz et archive.md5 étaient copiés sur le disque nouvellement exposé
    • archive.md5 correspondait à la valeur md5sum de l’archive
    • Ensuite, le disque était démonté et la commande U envoyée ; le flashage commençait, puis l’appareil redémarrait sur le nouveau firmware
  • Sous macOS, un conteneur a servi à créer un firmware personnalisé activant l’authentification SSH par mot de passe et ajoutant sa propre clé publique dans les authorized keys
    • Un exemple minimal des fonctions nécessaires au flashage est disponible ici
    • Après exécution du script et flashage, il a été possible de se connecter à l’appareil en SSH
  • Cet appareil permettait de flasher le firmware très facilement, et la raison de l’activation de SSH par défaut ainsi que de la présence de clés par défaut reste inconnue
    • Le problème a été signalé à RODE via un ticket, mais aucune réponse n’a été reçue
    • Il est prévu de continuer à vérifier si de futurs firmwares introduisent des changements

À lire aussi

1 commentaires

 
GN⁺ 5 일 전
Avis Hacker News
  • Ce qui me frustre toujours dans ce genre de discussion, c’est que firmware signé et firmware ouvert ne sont pas, à l’origine, des contraires.
    Activer la vérification par défaut, c’est très bien, mais la personne qui a acheté le matériel devrait pouvoir reprendre le contrôle propriétaire, soit en enregistrant sa propre clé, soit en changeant un jumper, soit en appuyant sur un bouton au démarrage.
    En pratique, seuls quelques Chromebook et certains équipements réseau permettent vraiment cela, donc dès qu’on parle de sécurité du firmware, on retombe toujours sur l’affrontement entre « tout verrouiller » et « tout laisser ouvert », pendant que disparaît l’idée d’un système où c’est l’utilisateur qui a payé qui décide.
    Le fait que Rode distribue ça sous forme de tarball + hash est excellent, et même s’ils durcissent davantage plus tard, j’espère que cela restera un système où je peux installer ce que je veux sur le matériel que je possède.
  • J’aime vraiment le fait que l’image du firmware soit simplement un tarball + hash.
    J’aimerais qu’il y ait plus d’appareils aussi ouverts, et j’espère que Rode ne va pas voir ça et décider de verrouiller les mises à jour du firmware.
    • Si quelqu’un de chez Rode voit ça, c’est exactement le genre de chose qui me donne envie d’acheter votre matériel.
      S’il vous plaît, ne changez pas ça.
    • Il y a quelques années, j’ai dû mettre à jour le firmware d’une imprimante HP, et j’avais trouvé la méthode étonnamment simple, ce que j’avais beaucoup apprécié.
      C’était une imprimante sortie vers 2009, et pour passer la RAM à 256 Mo il fallait une mise à jour du firmware, mais il suffisait d’envoyer le tarball à l’imprimante en FTP via le réseau.
      Je l’ai fait avec FileZilla, ça a mouliné quelques minutes et la mise à jour était terminée aussitôt ; depuis, je me dis qu’il n’y a pas vraiment de raison pour qu’une mise à jour de firmware soit plus compliquée que ça.
      Même s’il y a un checksum pour la sécurité, j’aimerais qu’on puisse juste envoyer un blob en FTP, SCP ou SFTP, et que ce soit tout.
    • Cela dit, je pense quand même qu’il vaudrait mieux n’activer la commande de mise à jour qu’avec une entrée physique, comme un bouton.
      Il faudrait imposer une sorte de mode DFU, sinon n’importe quoi ayant accès à l’USB pourrait pousser un mauvais firmware et briquer l’appareil.
    • Personnellement, je n’ai pas envie que mon interface audio fasse tourner SSH, avec un système où quelqu’un pourrait y ajouter une clé autorisée arbitraire.
  • Le titre Mon interface audio est un ordinateur Linux 64 bits aurait sans doute été encore plus intéressant.
    Il y a 10 ou 20 ans, ce genre de fonctionnalité aurait probablement été implémenté sur un petit SoC 16 ou 32 bits avec un RTOS comme VxWorks.
    Comme il y a aussi beaucoup de contrôles physiques, l’étape suivante paraît presque naturellement être d’en faire une console de jeu.
    • Mon interface audio est elle aussi, au fond, un ordinateur Linux, et elle contient même un FPGA réellement programmé sur le terrain.
      En plus, il y a deux ports 1GbE, chacun communiquant avec une partie différente de la machine.
      Mais ce type de configuration n’a rien d’exotique dans l’audio pro ; ça impressionne sur un bureau à la maison, mais dans le secteur c’est plutôt banal.
      Cela dit, ce sera peut-être plus amusant à raconter une fois que j’aurai obtenu un shell root ou que j’aurai briqué l’appareil.
    • Ton video dongle aussi peut être un ordinateur Unix : https://www.macrumors.com/2025/02/04/doom-apple-lightning-hdmi-adapter/
    • Aujourd’hui, il y a encore des contraintes RAM/stockage, mais les puces ne coûtent vraiment plus cher.
      En termes de coût et de compatibilité, il est difficile de battre Linux.
  • Dès qu’un véritable DSP commence à être intégré dans un appareil, ce genre d’architecture devient assez courant.
    En général, il y a dessous un Linux minimal tournant sur un SoC ARM, et il arrive qu’un BSP fournisseur parte accidentellement avec sshd activé.
    C’est moins de la malveillance qu’un cas où, côté audio, personne ne se sent vraiment responsable du rootfs.
    L’essentiel, c’est de savoir si c’est seulement exposé sur le réseau côté USB, ou si c’est aussi ouvert sur le vrai LAN.
    Le premier cas est pénible ; le second est vraiment préoccupant.
    • Malheureusement, les valeurs par défaut de Linux ne sont pas idéales pour produire ce genre d’appareils en volume.
      À l’inverse, Android sépare les images par types de base comme eng / userdebug / user, donc rien qu’en choisissant correctement des préréglages on évite plus facilement ce genre d’erreur.
    • En réalité, ça écoute aussi sur le LAN.
      Je ne l’ai pas vérifié sur l’interface Wi‑Fi, car elle ne se connecte que pour certaines fonctions.
  • J’ai toujours du mal à réaliser que tout le monde a maintenant une sorte d’AI-hacker dans sa poche.
    Il suffit de donner ça à un agent et, en quelques minutes, il peut inspecter le firmware et proposer une méthode pour modifier l’appareil.
    L’an dernier encore, c’était le genre de chose qu’il fallait au minimum être un hacker du niveau de Hotz pour faire, ou alors quelqu’un d’extrêmement obstiné prêt à y passer énormément de temps.
    • Ce n’est absolument pas vrai.
      Les LLM ont certes rendu l’analyse, le débogage et le contournement beaucoup plus faciles, mais cet appareil était tellement peu protégé qu’une personne de niveau intermédiaire, avec un peu de motivation et de temps, aurait tout à fait pu y arriver.
      Il n’y avait ni firmware chiffré, ni vérification de signature, ni même d’accès SSH embarqué.
      À l’inverse, l’hyperviseur de la PS3 que George Hotz avait compromis avait été conçu de manière bien plus robuste du point de vue du défenseur, et l’exploit réel nécessitait jusqu’à du voltage glitching au moyen d’un FPGA.
      Pour ce type d’attaque, les LLM peuvent aider, mais comme il n’y a pas de boucle de feedback complète, cela reste encore très dépendant du travail humain.
      https://rdist.root.org/2010/01/27/how-the-ps3-hypervisor-was-hacked/
    • À lire le billet, Claude Code semble en pratique avoir surtout servi à interpréter le trafic USB HID et à chercher de la documentation de protocole, à la place de Wireshark et de Google.
      Si Wireshark n’est pas installé, cela peut faire gagner un peu de temps, mais avec un petit risque d’hallucination.
      Pour le reste, il s’agissait surtout de modifier ~root/.ssh/authorized_keys et /etc/shadow dans le tarball du firmware à l’intérieur d’un conteneur Docker, puis d’utiliser un petit script Python pour envoyer les messages HID correspondants et copier le tarball modifié sur le volume exposé par l’appareil comme un lecteur USB.
      Donc ce n’est pas le genre de travail qui demande un hacker fou : des bases de Linux sysadmin et la capacité à bricoler un petit programme anodin avec une bibliothèque USB HID suffisent.
      En revanche, je me suis brièvement demandé pourquoi le paquet whois était installé dans le conteneur Ubuntu, avant de me rappeler que, sur les distributions de type Debian, mkpasswd s’y trouve pour des raisons historiques.
      Et si le sshd_config de l’appareil était resté sur la configuration par défaut, il est très probable qu’une connexion root par mot de passe n’aurait de toute façon pas été possible à cause de PermitRootLogin.
      https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=116260
    • Moi aussi, j’ai utilisé l’IA pour activer SSH sur un de mes Phase One digital back, et sur un autre j’ai fait de la rétro-ingénierie du firmware pour le patcher afin qu’il soit reconnu comme un autre modèle.
      J’ai fait passer un Credo 50 pour un IQ250, alors qu’en interne c’est essentiellement la même chose.
    • Avant, il fallait passer des heures à fouiller des captures de paquets et toutes sortes de données, donc c’est agréable de pouvoir éviter ce temps-là maintenant.
      C’est amusant de creuser, mais en vieillissant il devient difficile de passer 16 heures d’affilée sur un blob de firmware aléatoire.
    • Dans la plupart des cas, les LLM ne sont pas capables de faire ce genre de choses à ce niveau.
      Et de toute façon, il n’y a rien de particulièrement technique dans le fait de manipuler un appareil avec SSH ouvert.
  • J’ai exactement le même problème, donc j’étais vraiment curieux de savoir comment l’auteur l’avait résolu.
    En particulier la partie où lui et sa petite amie veulent jouer dans la même pièce et utiliser Discord, chacun avec son micro branché sur son propre ordinateur, sans écho.
    • Le Rodecaster peut être connecté à deux ordinateurs.
      Il suffit que les deux rejoignent le même appel Discord, puis d’envoyer les deux micros mixés en une seule entrée sur l’un des ordinateurs, tandis que l’autre reçoit seulement l’audio dans le client avec le micro coupé.
      Comme le mixage se fait en local, cela ne crée pas d’écho.
      C’est assez simple au point que j’aurais presque envie de lui dire de m’écrire par mail s’il veut plus de détails.
    • Récemment, j’ai vaguement fait du vibe coding en Rust pour un jack mixer, capable de recevoir de l’audio par le LAN puis de le renvoyer.
      La latence tourne autour de 40 ms, ou 50 à 60 ms en passant par le Wi‑Fi.
      On peut faire tourner le mixeur sur un PC, prendre le micro local comme canal d’entrée, puis faire diffuser l’autre PC avec son propre micro vers le canal 2 du mixeur pour résoudre le problème de façon similaire.
      On peut aussi lire de la musique sur le PC local, et le mixeur ou le broadcaster peut créer un sink local.
      À la fin, tout est mixé dans le mixeur, la sortie principale part vers Discord, et la ligne de monitoring peut renvoyer l’audio Discord puis le relayer à l’autre PC pour une écoute en temps réel.
    • Je me demande si ce n’est pas tout simplement un problème qui se résout avec un headset doté d’un micro perche directionnel.
      Cela dit, j’ai peut-être mal compris la situation.
  • Le billet est bien, et le domaine est classe aussi.
    Je ne connais pas bien Zola, mais que ce soit un template courant ou quelque chose de custom, c’est très agréable à regarder.
  • On dirait que beaucoup de vendeurs considèrent en pratique la security comme synonyme de prévention de la copie.
    C’est sans doute pour cela qu’ils imposent des images signées.
  • Je me suis demandé pourquoi l’objectif était la divulgation.
    Pour ce type d’interface, on pourrait penser qu’il vaudrait plutôt mieux la laisser ouverte.
    • Ce n’était pas forcément l’objectif, et moi aussi j’espère que RODE laissera ça ouvert.
  • Les gens de Rode en Australie ont plutôt la réputation d’être accessibles, donc s’il y a quelque chose à signaler, on pourrait probablement simplement les appeler.
    Là-bas, ils parlent quasiment anglais de toute façon, donc on devrait pouvoir se comprendre.