Bei einem Audio-Interface ist SSH standardmäßig aktiviert

 (hhh.hn)
1 Punkte von GN⁺ 4 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Beim Entpacken der Firmware-Datei ließ sich die interne Struktur des Geräts leicht nachvollziehen, und beim Rodecaster Duo war SSH im Auslieferungszustand offen
  • Das Update-Paket lag als gzipped tarball vor, und das Gerät enthielt zwei Partitionen, sodass bei einer Beschädigung von der anderen gebootet werden konnte, sowie Shell-Skripte für Updates
  • Für eingehende Firmware gab es keine Signaturprüfung, der tatsächliche SSH-Zugriff wurde über eine Ethernet-Verbindung bestätigt, und es war nur Pubkey-Authentifizierung erlaubt
  • Unter Windows wurde durch Mitschneiden des USB-Update-Ablaufs bestätigt, dass der Wechsel in den Update-Modus und das Flashing über die einzelnen ASCII-Befehle M und U erfolgen; danach werden archive.tar.gz und archive.md5 kopiert und nach einem Neustart ist die neue Firmware installiert
  • Unter macOS war mit Custom Firmware sogar ein echter Login möglich, indem SSH-Passwortauthentifizierung aktiviert und ein öffentlicher Schlüssel hinzugefügt wurde; warum SSH standardmäßig aktiv war und Standardschlüssel enthalten waren, blieb letztlich ungeklärt

Firmware-Update und standardmäßig aktiviertes SSH

  • Beim Rodecaster Duo ließen sich die während des Firmware-Updates an das Gerät übertragenen Dateien leicht einsehen, und SSH war standardmäßig aktiviert
    • Unter macOS wurde die Plattenaktivität verfolgt, um den Speicherort der Firmware zu finden; die Firmware lag als einfacher gzipped tarball vor
    • Auf dem getesteten Gerät war das Schreiben auf den USB-Datenträger deaktiviert, weshalb dieses Update scheiterte
  • Im Inneren des Geräts fanden sich ausführbare Binärdateien und Shell-Skripte für Updates; auf dem Datenträger gab es zwei Partitionen, damit bei einer Beschädigung von der anderen gebootet werden konnte
    • Für eingehende Firmware gibt es keine Signaturprüfung
    • Ein Test mit angeschlossenem Ethernet-Kabel zeigte, dass SSH tatsächlich offen war und nur Pubkey-Authentifizierung erlaubt wurde
  • Es wurden zwei standardmäßig hinterlegte SSH-Schlüssel gefunden
    • 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

Update-Ablauf und Custom Firmware

  • Unter Windows wurde mit Wireshark und USBPcap der Update-Traffic mitgeschnitten, um den Steuerungsablauf zu analysieren, den die RODECaster App an das Gerät sendet
    • Es gab den 'M'-Befehl, der das Gerät in den Update-Modus versetzt, und den 'U'-Befehl, der das Update ausführt
    • Beide Befehle wurden als einzelnes ASCII-Zeichen über HID report 1 übertragen
  • Die tatsächliche Update-Struktur war einfach
    • Nach dem Senden des M-Befehls werden archive.tar.gz und archive.md5 auf den neu eingeblendeten Datenträger kopiert
    • archive.md5 war der md5sum-Wert des Archivs
    • Anschließend wird der Datenträger ausgehängt und der U-Befehl gesendet; dann beginnt das Flashing und danach startet das Gerät mit der neuen Firmware neu
  • Unter macOS wurde mithilfe eines Containers eine Custom Firmware erstellt, die SSH-Passwortauthentifizierung aktiviert und den eigenen öffentlichen Schlüssel zu den authorized keys hinzufügt
    • Ein minimales Funktionsbeispiel für das Flashing findet sich hier
    • Nach dem Ausführen des Skripts und dem Flashing war eine SSH-Verbindung zum Gerät möglich
  • Die Firmware dieses Geräts ließ sich sehr leicht flashen, und der Grund für das standardmäßig aktivierte SSH sowie die enthaltenen Standardschlüssel blieb ungeklärt
    • Das Problem wurde per Ticket an RODE gemeldet, eine Antwort blieb jedoch aus
    • Künftige Firmware-Updates sollen weiter beobachtet werden, um mögliche Änderungen festzustellen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 일 전
Hacker-News-Kommentare
  • Was mich an solchen Geschichten immer frustriert, ist die Tatsache, dass signierte Firmware und offene Firmware eigentlich keine Gegensätze sind.
    Es ist völlig in Ordnung, die Verifikation standardmäßig zu aktivieren, aber die Person, die die Hardware gekauft hat, sollte die Kontrolle als Eigentümer haben, etwa indem sie eigene Schlüssel registriert, einen Jumper umsteckt oder beim Booten einen Knopf drückt.
    In der Praxis bieten das nur einige Chromebooks und Netzwerkgeräte, deshalb endet jede Diskussion über Firmware-Sicherheit immer als Streit zwischen „alles dichtmachen“ und „alles komplett offenlassen“, während die Struktur verschwindet, in der der zahlende Nutzer entscheidet.
    Dass Rode per tarball + hash verteilt, ist sehr gut, und selbst wenn sie es später stärker absichern, hoffe ich, dass es weiterhin einen Weg gibt, auf meine eigene Hardware das aufzuspielen, was ich möchte.
  • Dass das Firmware-Image einfach tarball + hash ist, gefällt mir wirklich sehr.
    Ich wünschte, es gäbe mehr so offene Geräte, und hoffe, dass Rode das nicht sieht und daraufhin Firmware-Upgrades sperrt.
    • Falls das jemand von Rode liest: Genau solche Dinge machen Lust, eure Geräte zu kaufen.
      Bitte ändert das nicht.
    • Ich musste vor ein paar Jahren die Firmware eines HP-Druckers aktualisieren, und überraschenderweise war das Verfahren herrlich simpel.
      Es war ein Drucker von etwa 2009, und um den RAM auf 256 MB aufzurüsten, war ein Firmware-Update nötig; man musste dem Drucker nur das Tarball per FTP über das Netzwerk schicken.
      Ich habe es mit FileZilla hochgeladen, ein paar Minuten gewartet, und das Update war direkt fertig; seitdem frage ich mich, warum Firmware-Updates überhaupt komplizierter sein müssen.
      Aus Sicherheitsgründen kann man gern eine Checksumme prüfen, aber es wäre schön, wenn man einfach per FTP, SCP oder SFTP einen Blob hochlädt und fertig.
    • Trotzdem finde ich, dass man den Update-Befehl nur über etwas wie einen physischen Knopf aktivieren sollte.
      Man sollte erst in eine Art DFU mode wechseln müssen, sonst kann jedes beliebige Ding mit USB-Zugriff versehentlich falsche Firmware einschieben und das Gerät bricken.
    • Ich persönlich möchte nicht, dass mein Audio-Interface SSH laufen hat und irgendjemand dort beliebige authorized keys hinzufügen kann.
  • Der Titel Mein Audio-Interface ist ein 64-Bit-Linux-Computer wäre interessanter gewesen.
    Vor 10 oder 20 Jahren wäre so etwas wahrscheinlich auf einem kleinen 16- oder 32-Bit-SoC mit einem RTOS wie VxWorks implementiert worden.
    Da es auch viele physische Bedienelemente gibt, wirkt der nächste logische Schritt fast wie der Umbau zur Spielkonsole.
    • Mein Audio-Interface ist tatsächlich auch ein Linux computer, und darin steckt sogar ein tatsächlich field-programmierbares FPGA.
      Außerdem hat es zwei 1GbE-Ports, die jeweils mit anderen Teilen der Maschine kommunizieren.
      So eine Konfiguration ist in der Pro-Audio-Welt allerdings nicht besonders ungewöhnlich; auf dem Schreibtisch zu Hause wirkt das beeindruckend, in der Branche ist es eher ziemlich normal.
      Vielleicht wird die Geschichte interessanter, wenn ich später eine Root-Shell bekomme oder das Ding bricke.
    • Auch dein video dongle kann ein Unix-Computer sein: https://www.macrumors.com/2025/02/04/doom-apple-lightning-hdmi-adapter/
    • Heute gibt es zwar noch RAM-/Storage-Druck, aber Chips sind so billig geworden.
      Auch bei Kosten und Kompatibilität ist Linux schwer zu schlagen.
  • Sobald Geräte mit einem richtigen DSP ausgestattet sind, ist so eine Architektur ziemlich üblich.
    Unten drunter läuft meistens ein minimales Linux auf einem ARM-SoC, und es kommt vor, dass ein Vendor-BSP versehentlich mit aktiviertem sshd ausgeliefert wird.
    Das ist weniger böse Absicht als vielmehr ein Fall, in dem sich im Audiobereich niemand wirklich verantwortlich um das rootfs kümmert.
    Entscheidend ist, ob das nur im USB-seitigen Netzwerk offen ist oder auch im echten LAN.
    Ersteres ist eher lästig, Letzteres wirklich besorgniserregend.
    • Leider sind die Linux-Standardeinstellungen für die Massenproduktion solcher Geräte nicht besonders gut geeignet.
      Im Vergleich dazu hat Android grundlegende Image-Typen wie eng / userdebug / user, sodass man solche Fehler schon vermeidet, wenn man nur die vorkonfigurierten Defaults richtig auswählt.
    • Es lauscht tatsächlich auch im LAN.
      Ich konnte nicht prüfen, ob es auch auf diesem Interface offen ist, weil es sich nur für bestimmte Funktionen mit dem Wi‑Fi verbindet.
  • Es überrascht mich immer noch, dass jetzt praktisch jeder einen AI-Hacker in der Tasche mit sich herumträgt.
    Man wirft so etwas einfach einem Agenten hin, und nach wenigen Minuten bekommt man einen Ansatz, wie man in die Firmware schaut und das Gerät modifiziert.
    Noch letztes Jahr wäre das etwas gewesen, das mindestens einen Hacker auf Hotz-Niveau oder jemanden mit enorm viel Ausdauer gebraucht hätte.
    • Das stimmt überhaupt nicht.
      Es ist zwar richtig, dass LLMs Analyse, Debugging und Umgehungen viel einfacher gemacht haben, aber dieses Gerät war so schwach geschützt, dass schon jemand mit mittleren Fähigkeiten, Motivation und etwas Zeit damit Erfolg haben konnte.
      Es gab keine verschlüsselte Firmware, keine Signaturprüfung und sogar eingebauten SSH access.
      Der PS3-Hypervisor, den George Hotz geknackt hat, war aus Sicht des Angreifers dagegen deutlich robuster ausgelegt, und der tatsächliche Exploit brauchte sogar Voltage Glitching mit FPGA.
      Bei solchen Angriffen können LLMs zwar helfen, aber ohne vollständige Feedback-Schleife bleibt weiterhin viel Handarbeit nötig.
      https://rdist.root.org/2010/01/27/how-the-ps3-hypervisor-was-hacked/
    • Dem Artikel nach wurde Claude Code im Grunde nur anstelle von Wireshark und Google verwendet, um USB-HID-Traffic zu interpretieren und Protokolldokumentation zu finden.
      Wenn Wireshark nicht installiert ist, spart das vielleicht etwas Zeit, bringt aber auch ein gewisses Halluzinationsrisiko mit sich.
      Ansonsten wurde nur in Docker ~root/.ssh/authorized_keys und /etc/shadow im Firmware-Tarball verändert, dazu ein einfaches Python-Skript verwendet, das die relevanten HID-Nachrichten sendet und das modifizierte Tarball auf ein Volume kopiert, das das Gerät wie ein USB-Laufwerk bereitstellt.
      Dafür braucht man also keinen verrückten Hacker, sondern nur solide Linux-Sysadmin-Grundlagen und das Niveau, ein kleines Programm mit einer USB-HID-Bibliothek zusammenzusetzen.
      Kurz war ich allerdings irritiert, warum im Ubuntu-Container das Paket whois installiert wurde, aber auf Debian-artigen Systemen liegt mkpasswd aus historischen Gründen eben dort.
      Und wenn die sshd_config des Geräts unverändert auf den Defaults beruhte, war Root-Passwort-Login wegen PermitRootLogin womöglich ohnehin von vornherein nicht möglich.
      https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=116260
    • Ich habe ebenfalls AI verwendet, um auf einem meiner Phase One digital back-Geräte SSH zu aktivieren, und bei einem anderen habe ich die Firmware rückentwickelt und so gepatcht, dass es sich als ein anderes Modell meldet.
      Ich habe ein Credo 50 als IQ250 ausgegeben; intern sind sie praktisch identisch.
    • Früher musste man stundenlang Paketmitschnitte und allerlei Daten durchforsten, und es ist schön, diese Zeit jetzt nicht mehr investieren zu müssen.
      Sich tief einzuarbeiten macht Spaß, aber je älter man wird, desto schwerer wird es, 16 Stunden am Stück an irgendeinem zufälligen Firmware-Blob zu sitzen.
    • In den meisten Fällen können LLMs Dinge auf diesem Niveau nicht leisten.
      Außerdem braucht es keine besonderen Fähigkeiten, um mit einem Gerät umzugehen, auf dem SSH offen ist.
  • Ich habe dasselbe Problem und war deshalb wirklich neugierig, wie der Autor es gelöst hat.
    Vor allem den Teil, in dem er mit seiner Freundin im selben Raum spielt und Discord nutzt, während beide ihre Mikrofone jeweils an den eigenen Computer anschließen wollen, aber ohne Echo.
    • Der Rodecaster kann mit zwei Computern verbunden werden.
      Ihr könnt beide demselben Discord-Call beitreten, dabei beide Mikrofone zu einem Eingang auf einem Rechner zusammenmischen und auf dem anderen Rechner das Mikro stummschalten, sodass dort im Client nur Audio empfangen wird.
      Weil das Mixing lokal passiert, entsteht kein Echo.
      Es ist so einfach, dass ich fast sagen würde: Schreib mir eine Mail, wenn du mehr Details willst.
    • Ich habe kürzlich in Rust grob einen jack mixer vibe-coded, der Audio über das LAN empfangen und wieder ausgeben kann.
      Die Latenz liegt bei ungefähr 40 ms, über Wi‑Fi eher bei 50–60 ms.
      Man könnte den Mixer auf einem PC laufen lassen und dort das lokale Mikro als einen Eingangskanal nutzen, während der andere PC sein Mikro streamt und damit Kanal 2 des Mixers speist; so ließe sich das Problem ähnlich lösen.
      Auf dem lokalen PC kann auch Musik laufen, und der Mixer oder Broadcaster kann einen lokalen Sink erzeugen.
      Am Ende mischt man alles im Mixer zusammen, schickt den Main-Out an Discord und gibt die Monitor-Linie nach der Discord-Audio-Ausgabe wieder an den anderen PC weiter, damit man in Echtzeit mithören kann.
    • Wäre das nicht einfach ein Problem, das sich mit einem Headset mit gerichtetem Boom-Mikrofon lösen lässt?
      Natürlich kann es sein, dass ich die Situation falsch verstanden habe.
  • Der Artikel ist gut und auch die Domain sieht klasse aus.
    Ich kenne mich mit Zola nicht aus, aber egal ob das ein gängiges Template oder etwas Eigenes ist, es sieht wirklich gut aus.
  • Viele Anbieter scheinen security im Grunde als Synonym für Kopierschutz zu verstehen.
    Deshalb erzwingen sie vermutlich signierte Images und Ähnliches.
  • Ich habe mich gefragt, warum das Ziel disclosure war.
    Bei so einem Interface hätte ich eher gedacht, dass man es absichtlich offenlassen möchte.
    • Das war nicht unbedingt das Ziel, und ich hoffe ebenfalls, dass RODE es offen lässt.
  • Die Rode-Leute in Australien gelten als recht ansprechbar; wenn es etwas zu melden gibt, könnte man wahrscheinlich einfach anrufen.
    Dort spricht man ja fast Englisch, also sollte die Verständigung klappen.