Starlinkユーザー端末の分解
(darknavy.org)- DARKNAVYは、シンガポールで購入した Starlink Standard Actuated のアンテナを分解し、ハードウェア、ファームウェア、セキュリティチップ、エミュレーションの可能性を予備的に分析した
- アンテナPCBの大部分は STMicroelectronicsのRFフロントエンド が占めており、主要な制御部は基板の片側に集中していて、一般的なIoTデバイスに似た構造を示している
- Rev3ファームウェアはeMMCを取り外してダンプされ、大部分が 非暗号化 の状態だったため、ブートチェーンの一部、カーネル、ファイルシステムの一部、ランタイム構成を確認できた
- 抽出されたソフトウェアには、ユーザー端末だけでなく衛星・地上ゲートウェイ向けと思われる機能も含まれており、起動時に ハードウェア周辺機器 によってデバイス種別を識別する構造と見られる
- Ethernet Data Recorderは衛星テレメトリ関連パケットを記録し、ハードウェアキーで暗号化するが、UTAには41個の SSH公開鍵 が自動登録され、ローカルネットワークに対して22番ポートが常に開いている
Starlinkユーザー端末と分析範囲
- StarlinkはSpaceXの 低軌道衛星インターネット サービスで、ユーザーはユーザー端末を通じて低軌道衛星に接続し、地上ゲートウェイを経由してインターネットに接続する
- 新世代の衛星には レーザーリンク が段階的に搭載されており、一部の衛星は相互に直接通信できる
- 地上局への依存度を下げ、伝送効率を高め、世界的なカバレッジを改善する
- 現地の地上局がないウクライナの戦場でも、Starlinkユーザー端末は衛星間リンクを通じて近隣国のゲートウェイに間接的に接続できる
- DARKNAVYの調査はStarlinkユーザー端末全体ではなく、アンテナ構成要素である User Terminal Antenna, UTA に集中している
- 対象機器はシンガポールで購入したStarlink Standard Actuated
- Rev3またはGenV2とも呼ばれる
ハードウェア分解結果
- 完全なStarlinkユーザー端末は ルーター とアンテナの2つの部分で構成される
- 分解されたUTAのPCBは外部ケースとほぼ同じサイズだった
- 基板の大部分はSTMicroelectronics製の RFフロントエンドチップ が占めている
- 主要な制御部品は主にPCBの片側に集まっている
- RFアンテナを除いたUTAの中核領域の全体設計は、一般的なIoTデバイスとかなり似ている
- メインSoCは、SpaceX向けにSTがカスタム製造した quad-core Cortex-A53 である
- 現時点でこのチップのハードウェアとデータシートは機密扱いで、公開されていない
- Black Hat USA 2022で、KU LeuvenのDr. Lennert Woutersは第1世代StarlinkアンテナGenV1に フォールトインジェクション攻撃 を行い、デバイスのroot shellを取得するデモを行った
- SpaceXはその後、ファームウェアアップデートでPCBのUARTデバッグインターフェースを無効化し、フォールト攻撃への耐性を高めた
- Woutersは手法を改良し、再び侵入に成功した
ファームウェア抽出とソフトウェア構造
- DARKNAVYはUTAをより深く分析するため、eMMCチップから ファームウェアを直接ダンプ した
- Rev3基板には明確なeMMCデバッグピンがなかった
- eMMCチップをPCBから取り外した後、プログラマーで読み出す必要があった
- 抽出されたファームウェアの大部分は 暗号化されていない状態 だった
- BootROMを除くブートチェーン
- カーネル
- ファイルシステムの非暗号化領域
- カーネル起動後は、ランタイム環境の大部分をeMMCから読み込み、
/sx/local/runtimeディレクトリに展開する - ランタイム構造では、
binはStarlinkソフトウェアスタックに必要な実行ファイルを格納し、datは設定ファイルを保存し、revision_infoは現在のソフトウェアとハードウェアのバージョンを記録する - 外部ユーザー通信を処理する
user_terminal_frontendはGoで書かれており、その他のプログラムの大半はシンボルのない静的コンパイル済みC++実行ファイルである - 既存研究に基づく初期分析では、ネットワークスタックアーキテクチャは DPDK とある程度似ている
- 主にユーザー空間のC++プログラムがカーネルを迂回してネットワークパケットを処理する
- Linuxカーネルは基本的なハードウェアドライバーとプロセス管理を提供する役割が大きい
- UTAから抽出した中核ソフトウェアには、衛星や地上ゲートウェイに属すると見られる機能も含まれている
- 初期のリバースエンジニアリング上、システムは起動中にハードウェア周辺機器を基準に デバイス種別 を識別する
- その後、そのデバイス種別に合ったロジックをロードして実行する
QEMUベースのエミュレーション
- DARKNAVYはUTAを継続的に分析しやすくするため、Rev3ファームウェア向けの QEMUベースのエミュレーション環境 を構築した
- この環境で、外部エンティティと相互作用する一部のソフトウェアの実行とデバッグに成功した
httpdWebSocketgRPCサービス
STSAFE-A110セキュリティチップ
- UTAにはメインSoCのほかに、専用セキュリティチップである STSAFE-A110 が搭載されている
- このチップはCC EAL5+のセキュリティ等級をうたっている
- カスタムSoCとは異なり、NDAの下で合法的に購入できる
- UTAファームウェアでは、
stsafe_cliというユーザー空間プログラムがこのチップとのやり取りを処理する - リバースエンジニアリングの結果、STSAFEは主に次の機能を提供していると見られる
- 各デバイスの一意の識別子、UUID
- 衛星通信の認証に使われると推定される公開鍵証明書
stsafe_leaf.pemの管理 - ユーザーデータ転送用の対称暗号鍵の導出
- このチップはSoCのsecure bootメカニズムとは独立した 追加のroot of trust として機能し、現代の組み込みセキュリティ設計の手法と合致している
Ethernet Data RecorderとSSH鍵
- 分析中に Ethernet Data Recorder というプログラムが発見され、名前と機能だけを見るとユーザーデータをキャプチャするバックドアのように疑われる可能性がある
- 詳細を確認した結果、このプログラムは
pcap_filterに似たメカニズムで特定のネットワークパケットを記録する- キャプチャルールの例には、
udp and dst port 10017条件と特定のmulticast宛先ホストが含まれる - ファームウェア内の他の手がかりに基づくと、これらのパケットは 衛星テレメトリ に関連している
- キャプチャルールの例には、
- キャプチャされたすべてのトラフィックは、SoCにヒューズされたハードウェアキーを使って暗号化される
- 現時点で得られている情報だけでは、この機能が ユーザープライバシーデータ を収集しているとは見なしにくい
- デバイス初期化中にシステムが自身をユーザー端末として識別すると、初期化スクリプトが41個のSSH公開鍵を
/root/.ssh/authorized_keysに自動的に記録する- UTAの22番ポートはローカルネットワークに対して常に開いている
- ユーザー向け製品にこれほど多くの不明なログイン鍵が存在する点は目を引く
衛星インターネットシステムのセキュリティ文脈
- 衛星技術が進化を続け、さまざまな産業に適用されるにつれ、Starlinkや他の衛星インターネットシステムの各構成要素は、今後の攻撃・防御作戦における重要な領域になり得る
- 宇宙セキュリティでは、開発者とハッカーはデジタル領域だけでなく 宇宙物理学上の制約 にも向き合わなければならない
- たった一度の誤操作で、対象との連絡を永久に失う可能性がある
1件のコメント
Hacker News のコメント
初期化時にユーザー端末として識別されると、
/root/.ssh/authorized_keysに 41個の SSH 公開鍵を自動で入れるというのだから、「自分の」ユーザー端末に root アクセス権を持っていないのは誰なのかのほうが気になるもう少し真面目に見ると、ISP が提供するルーターにリモート管理システムを置くのと大きく違うのだろうか。SpaceX がユーザー端末に直接アクセスできなくても、衛星や地上局でトラフィックをキャプチャすることはできる
むしろ41個のインスタンスが1つの鍵を共有しているなら、そのほうが心配になりそうだ
authorized_keysでも25行ある。ノートPCごとに異なる YubiKey、iPad と iPhone の鍵、Mac の Secure Enclave 鍵があるStarlink にはシステム管理者も1〜2人よりは多いはずなので、公開鍵が100個ほどあっても妥当だと思う
プロダクションデバイスのエンジニアリング上の問題を診断するための別のリモートアクセスソフトウェアがあり、REPL を立ち上げることはできるが、アクセス制御と DevOps の承認で制限されている
類似投稿の過去の議論: Teardown of the SpaceX Starlink User Terminal https://news.ycombinator.com/item?id=25277171 (2020年12月2日 — 158ポイント、コメント138件)
公開鍵41個を上げれば、おそらくどの開発者が使っているのか確認できそうだ
https://web.archive.org/www.darknavy.org/blog/a_first_glimps...
すべてのパケットがユーザー空間で処理されるという点に驚いた
100バイトの UDP パケットで 1Gbps のトラフィックを処理するなら、毎秒100万パケットを処理しなければならない。1GHz CPU なら1パケットあたり1000サイクルしか使えない
可能ではあるが、エンジニアがアセンブリを手書きし、あらゆるルックアップテーブル技法を考えるのが好きでもない限り、簡単ではない
ソフトウェアはパッチ適用済みカーネルかもしれないし、XDP 風のカーネルバイパスかもしれない。Intel Puma のケーブルモデムルーター／ゲートウェイで DPDK か類似のものを周辺的に扱った経験に基づく推測だ
Starlink は25〜200Mbps程度で、平均パケットも7〜8倍大きいので、多くても毎秒約36,000パケットであり、1GHzでもかなり対処可能な水準だ
その時点では、ポーリングコードがカーネル内にあるかどうかがなぜ重要なのか分からない
memcpyを1回余分に避けられるので、ずっと速いタイトルの誤字を直してほしい。現在は “Ternimal” になっている
こういうことをどう始めるのか気になる。リバースエンジニアリングは難しく、機器をいじる遊びはたいてい本当に高価か、古くてもう開発されていないものだと思う。例外はあるだろうが
普通は UART があるものだが、Starlink 端末には UART がないようなので、この人は代わりに eMMC メモリチップを取り外した。実質的にははんだ付けされた microSD カードのようなものだ
“DARKNAVY built a basic QEMU-based emulation environment for the Rev3 firmware” とあるが、GPS のような外部デバイスにつながるファームウェアをエミュレーションする資料や、すでに用意された解法があるのか気になる
Android Emulator は QEMU エミュレーターのダウンストリームであり、Android デバイスの起動サポートを追加し、一般的な Android ハードウェア（OpenGL、GPS、GSM、センサー）と GUI インターフェースをエミュレートする。Android Emulator は複数の方法で QEMU を拡張している
製品でファームウェアをリバースエンジニアリング防止するにはどう保護すべきかに関心がある。SpaceX が使った手法を紹介する資料はあるだろうか？
rootfsを暗号化すべきだ。さらに一歩進めるなら、ARM の TrustZone のようなものを使って、ブートローダー、復号、イメージ署名のような機密作業を隠せるファイルシステムをそのままダンプできたという点を見ると、記事に出ているブートローダー以外には、SpaceX が特別な保護を適用していないように見える
むしろ、皆に利益があり、製品をより良くすることにリソースを使うほうがよいと思う。上級ユーザーにとっては、製品を改造できる理論上の可能性、さらにはメーカーが思いもしなかった方法で改造できる可能性が大きな利点になり得る
技術寄りのエンドユーザーの立場ではこう見える。照明、猫の給餌器、今ではローイングマシンまで、まともに使うためにデバイスをハックしなければならない状況に、本当に疲れて少し憂うつになっている
これがロケットと共有しているコードベース由来なら格好いいのだが？