オーディオインターフェースでSSHがデフォルトで有効化されている

 (hhh.hn)
1 ポイント 投稿者 GN⁺ 5 일 전 | 1件のコメント | WhatsAppで共有
  • ファームウェアファイルを展開すると、デバイス内部の構造を簡単に確認でき、Rodecaster Duo ではデフォルト状態で SSH が開いていた
  • アップデートパッケージは gzipped tarball 形式で、デバイスには破損時にもう一方から起動する 2つのパーティション とアップデート用シェルスクリプトが入っていた
  • 取り込まれるファームウェアには 署名検証がなく、実際の SSH 接続は Ethernet 接続で確認され、公開鍵認証のみ許可 される状態だった
  • Windows では USB アップデートのフローをキャプチャし、M と U という 単一の ASCII コマンド でアップデートモード移行と書き込み実行が行われることを確認、archive.tar.gz と archive.md5 をコピーした後、再起動で新しいファームウェアが適用された
  • macOS では カスタムファームウェア で SSH のパスワード認証を有効にし、公開鍵を追加して実際に接続まで可能だったが、SSH がデフォルトで有効であり、デフォルト鍵が含まれていた理由は最後まで判明しなかった

ファームウェアアップデートと SSH のデフォルト有効化

  • Rodecaster Duo はファームウェアアップデートの過程でデバイスへ渡されるファイルを簡単に確認でき、デフォルト状態で SSH が有効化 されていた
    • macOS でディスクアクティビティを追跡してファームウェア保存場所を見つけ、ファームウェアは単純な gzipped tarball 形式だった
    • アップデートを試みたデバイスでは USB ディスク書き込み機能が無効化されており、そのアップデートは失敗した
  • デバイス内部には実行バイナリとアップデート用シェルスクリプトがあり、ディスクには 2つのパーティション があって、一方が破損するともう一方から起動するようになっていた
    • 取り込まれるファームウェアには 署名検証がない
    • Ethernet ケーブルを接続して確認したところ、SSH が実際に開いており、公開鍵認証のみ許可 される状態だった
  • デフォルトで追加されていた SSH 鍵 2つが確認された
    • 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

アップデートフローとカスタムファームウェア

  • Windows では Wireshark と USBPcap でアップデートトラフィックをキャプチャし、RODECaster App がデバイスに送る制御フローを確認した
    • デバイスをアップデートモードに入れる 'M' コマンド と、アップデートを実行する 'U' コマンド があった
    • どちらのコマンドも HID report 1 で送信される 単一の ASCII 文字 だった
  • 実際のアップデート構造は単純だった
    • M コマンドを送った後、新たに露出したディスクに archive.tar.gz と archive.md5 をコピーする
    • archive.md5 はアーカイブの md5sum 値だった
    • その後ディスクをアンマウントして U コマンドを送ると書き込みが始まり、その後デバイスが再起動して新しいファームウェアへ切り替わる
  • macOS では コンテナ を使って SSH のパスワード認証 を有効にし、自分の公開鍵を authorized keys に追加するカスタムファームウェアを作成した
    • 書き込みに必要な最小限の関数例は こちら で確認できる
    • スクリプトを実行して書き込んだ後、デバイスに SSH で接続できた
  • このデバイスはファームウェアを非常に簡単に書き込め、SSH のデフォルト有効化とデフォルト鍵が含まれていた理由は確認されないまま残っている
    • この問題は RODE にチケットで報告したが、回答は得られなかった
    • その後のファームウェアアップデートで変化があるか、引き続き確認する予定だ

関連記事

1件のコメント

 
GN⁺ 5 일 전
Hacker Newsのコメント
  • こういう話でいつももどかしいのは、signed firmware と open firmware は本来反対語ではないということだ
    デフォルトで検証を有効にしておくのは構わないが、ハードウェアを買った人が自分の鍵を登録したり、ジャンパを切り替えたり、起動時にボタンを押したりして、所有者による制御権を持てるべきだ
    実際にそこまでやってくれるのは一部の Chromebook やネットワーク機器くらいなので、ファームウェアのセキュリティの話になると、いつも「がっちりロックしよう」と「完全に開放しよう」の争いになり、実際に金を払ったユーザーが決める仕組みは消えてしまう
    Rode が tarball + hash で配布しているのはとても良いし、今後もっと厳格になったとしても、自分の持っている機器に自分の入れたいものを載せられる仕組みであってほしい
  • ファームウェアイメージが単なる tarball + hash なのは本当に気に入っている
    こういう形で開かれたデバイスがもっと増えてほしいし、Rode がこれを見てファームウェアアップグレードをロックしてしまわないことを願う
    • もし Rode の人がこれを見ているなら、こういう点こそ機材を買いたくなる理由だ
      どうか変えないでほしい
    • 数年前に HP プリンタ のファームウェアを上げる必要があったが、意外なくらい方式が単純で良かった
      2009年ごろのプリンタで、RAM を 256MB に増やすにはファームウェアアップデートが必要だったのだが、ネットワーク経由でプリンタに tarball を FTP で送るだけでよかった
      FileZilla で送ったら数分動いて、そのままアップデートが終わり、それ以来ファームウェア更新がこれより複雑である必要はあるのかと思うようになった
      セキュリティのために checksum くらいはあってもよいが、単に FTP や SCP や SFTP で blob を1つ送って終わりにしてほしい
    • それでも、アップデートコマンドの有効化は 物理ボタン のような入力でのみ行えるようにするのが正しいと思う
      いわば DFU mode に入らないとできないようにすべきで、そうでないと USB にアクセスできる何かが誤ったファームウェアを押し込んで機器を文鎮化できてしまう
    • 個人的には、自分のオーディオインターフェースが SSH を動かしていて、そこに誰かが勝手に authorized key を追加できる構造は望まない
  • タイトルが 私のオーディオインターフェースは64ビットLinuxコンピュータだ だったら、もっと興味を引いたと思う
    10年、20年前なら、こういう機能はおそらく小さな16ビットまたは32ビット SoC 上の VxWorks のような RTOS で実装されていた可能性が高い
    物理コントロールも多いし、次の段階としてゲーム機にするのも自然に見える
    • 私のオーディオインターフェースも実は Linux computer で、中には実際に field-programmed される FPGA が入っている
      しかも 1GbE ポートが2つあり、それぞれ機器の別々の部分と通信している
      ただ、こういう構成はプロオーディオの世界ではそれほど珍しくなくて、家の机の上で使うと印象的なだけで、業界ではかなり普通の部類だ
      そのうち root shell を取ったり文鎮化したりした後の話のほうが、もっと面白いかもしれない
    • あなたの video dongle も Unix コンピュータかもしれない: https://www.macrumors.com/2025/02/04/doom-apple-lightning-hdmi-adapter/
    • 今は RAM/storage の制約はあるにせよ、チップ価格がとにかく安い
      コストと互換性の面で Linux に勝つのも簡単ではない
  • まともな DSP がデバイスに入り始めると、こういう構造はかなり一般的になる
    通常は下に ARM SoC 上で動く最小限の Linux があり、ベンダーの BSP がうっかり sshd を有効にしたまま出荷されることもある
    悪意というより、オーディオ分野では rootfs をきちんと面倒見る人がいない場合に近い
    重要なのは、これが USB 側のネットワークにだけ開いているのか、それとも実際の LAN にも開いているのかという点だ
    前者は面倒なだけだが、後者は本当に気になる
    • 残念ながら Linux のデフォルト設定は、この種のデバイスの量産にはあまり向いていない
      それに比べて Android には eng / userdebug / user のように基本イメージ種別の区別があるので、事前構成されたデフォルトを選ぶだけでもこうしたミスを避けやすい
    • これは実際に LAN でも待ち受けている
      特定の機能を使うときだけ Wi‑Fi に接続しているので、そのインターフェースも開いているかは確認できていない
  • 今では誰もがポケットに AI-hacker を入れて持ち歩いているような感覚で、まだ驚かされる
    エージェントに投げるだけで、数分でファームウェアを見てデバイスを改造するためのアプローチを出してくる
    去年までなら、こういうのは少なくとも Hotz級 のハッカーか、あるいはとてつもなく長く粘って掘り下げる人がやることだった
    • それはまったく事実ではない
      LLM が解析、デバッグ、回避をずっと容易にしたのは確かだが、このデバイスは保護レベルが非常に低く、中程度のスキルしかなくても、動機と時間があれば十分可能だった
      暗号化されたファームウェアもなく、署名検証もなく、内蔵の SSH access まであった
      一方で George Hotz が突破した PS3 hypervisor は、攻撃者目線でははるかに堅牢に設計されており、実際のエクスプロイトには FPGA を使った voltage glitching まで必要だった
      そういう種類の攻撃は LLM が助けにはなっても、完全なフィードバックループがないため、依然として人手がかなり必要だ
      https://rdist.root.org/2010/01/27/how-the-ps3-hypervisor-was-hacked/
    • 記事を読む限り、Claude Code は実質的に Wireshark や Google の代わりとして USB HID トラフィックの解釈やプロトコル文書探しに使った程度に見える
      Wireshark が入っていないなら多少時間は節約できるだろうが、幻覚のリスクも少しある
      それ以外には、Docker の中でファームウェア tarball の ~root/.ssh/authorized_keys と /etc/shadow を修正し、関連する HID メッセージを送って、修正済み tarball をデバイスが USB ドライブのように公開しているボリュームにコピーする簡単な Python スクリプトを書いた程度だった
      だからこれは狂ったハッカーが必要な仕事ではなく、Linux sysadmin の基礎と USB HID ライブラリを組み合わせてちょっとしたプログラムを1つ書ける程度で足りる
      ただ、なぜ Ubuntu コンテナに whois パッケージを入れたのか一瞬不思議だったが、Debian 系では歴史的な理由で mkpasswd がそこに入っているので納得した
      また、デバイスの sshd_config がデフォルトのままだったなら、PermitRootLogin のせいで root のパスワードログインはそもそもできなかった可能性が高い
      https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=116260
    • 私も AI を使って、自分が持っている Phase One digital back の1つで SSH を有効にし、別の1つではファームウェアをリバースエンジニアリングして別モデルとして認識されるようにパッチした
      Credo 50 を IQ250 として偽装したが、中身は実質的に同じだ
    • 昔はパケットキャプチャやあれこれのデータを何時間も掘り返す必要があったが、今はその時間を使わずに済むのがいい
      深掘りする楽しさはあるが、年を取るとランダムなファームウェア blob を相手に 16時間 も費やすのはきつくなる
    • ほとんどの場合、LLM はそのレベルのことはできない
      しかも SSH が開いているデバイスを扱うのに特別な技術が必要なわけでもない
  • 私も同じ問題があって、筆者がこれをどう解決したのか本当に気になった
    同じ部屋でゲームをしながら Discord を使い、自分と彼女がそれぞれ自分のコンピュータにマイクをつなぎつつ、echo なしで使いたいという部分が特にそうだ
    • Rodecaster は2台のコンピュータに接続できる
      両方とも同じ Discord 通話に入り、2本のマイクを片方のコンピュータの入力にまとめて送り、もう片方はマイクをミュートしたままクライアントで音声だけ受ければいい
      ミキシングはローカルで行われるので、エコーは発生しない
      もっと知りたければメールしてほしいと言いたくなるくらい簡単だ
    • 最近 Rust で jack mixer を雑に vibe coding したのだが、LAN 経由で音声を受けてまた送り出せる
      遅延はだいたい 40ms、Wi‑Fi 経由だと 50〜60ms くらい出る
      1台の PC でミキサーを動かしてローカルマイクを入力チャンネル1にし、もう1台の PC は自分のマイクをブロードキャストしてミキサーのチャンネル2に入れれば、同じように解決できる
      ローカル PC で音楽も流せるし、ミキサーや broadcaster がローカル sink を作ることもできる
      最後に全部をミキサーで混ぜて、メインアウトを Discord に送り、モニターラインは Discord 音声を出した後で別の PC にリレーしてリアルタイム試聴に使える
    • 指向性のブームマイク付き headset なら解決する問題ではないかとも思う
      もちろん、こちらが状況を誤解しているのかもしれない
  • 記事もいいし ドメイン も格好いい
    Zola は詳しくないが、これが一般的なテンプレートなのかカスタムなのかは分からなくても、とても見栄えが良い
  • 多くのベンダーは security を実質的に 複製防止 と同義だと見ているように思う
    だから signed image のようなものを強制するのだろう
  • なぜ目標が disclosure だったのか気になった
    こういうインターフェースなら、むしろ開いたままにしておきたいのではないかと思った
    • それが必ずしも目標というわけではなく、私も RODE には開いたままにしておいてほしいと思っている
  • オーストラリアの Rode の人たちは比較的話が通じるほうなので、何か報告したいことがあるなら普通に電話してもよさそうだ
    向こうではほぼ英語みたいなものも話しているので、話は通じるはずだ