By Vit Sembera (Senior Threat Researcher, Automotive)
Pwn2Own Automotive 2024では、Synacktiv（シナクティヴ）のリサーチャーであるDavid Berard氏とVincent Dehors氏が、Pwn2Own Vancouver 2022（英語ブログ）で初披露したTesla（テスラ）の車両内インフォテインメント（IVI）システムに対するハッキング成功の記録を更新する、またも素晴らしいデモンストレーションを披露しました。今回は、車両のLTE接続カードに侵入し、Linuxベースのプラットフォーム上で動作する重要なコンポーネントであるTeslaのIVIシステムを侵害する2バグ連鎖攻撃を実行しました。この脆弱性により、リモートコード実行（RCE）攻撃を実行し、Teslaの通信システムの乗っ取りに成功しました。
通信接続カードのエクスプロイト
OffensiveCon 2024でのプレゼンテーション“0-Click RCE on the Tesla Infotainment Through Cellular Network,”『セルラーネットワークを介したTesla インフォテインメントの0クリックRCE（リモートコード実行）』で、Synacktivのリサーチャーは、TeslaのLTE接続カードを標的にした方法と、ルートレベルのアクセスを許可する複数の重大な脆弱性を明らかにしました。
- UARTポートがルートアクセス可能になっていた
- ルートファイルシステムが読み取り/書き込み可能モードでマウントされていた
- ATコマンドハンドラーに脆弱性があり、任意のコマンドを注入することが可能であった
- iptablesファイアウォールに時折発生する競合状態により、ファイアウォールが無効になることがあり、攻撃の格好の機会が生まれていた
これらの脆弱性を活用することで、リサーチャーは巧妙な攻撃チェーンを編み出しました。携帯電話ネットワークの基地局を模倣し、接続チェックを操作することで、ファイアウォールが停止している間にカードを再起動したりコマンドを注入したりすることを可能にしました。そうやって、最終的にファイアウォールを恒久的に無効化し、SSH経由でリモートアクセスを獲得したのです。
車両内インフォテインメント（IVI）システムへの潜入
次の攻略段階では、モバイルネットワーク通信を処理するように設計されたオープンソースのテレフォニー ソフトウェアであるOfonoを実行するTeslaのIVIシステムが標的となりました。TeslaはOfonoをカスタマイズし、LTE接続カードとの通信用プラグインを追加しましたが、このプラグインにはヒープ バッファ オーバーフローの脆弱性が存在していました。Synacktivは、システムのlibc内でヒープ シェーピングやリターン オリエンテッド プログラミング（ROP）などの高度な技法を用いて脆弱性を悪用しました。また、リサーチャーはXPINセキュリティモジュールを回避し、メモリ マッピングのバグを悪用することで検出を回避しました。
サンドボックスの回避
Ofonoのdaemon（モバイルネットワーク通信の管理を担当するバックグラウンドプロセス）は、MiniJail、SecComp、AppArmor、iptablesなどのセキュリティ対策により、厳重にサンドボックス化されていました。しかし、このデーモンにはネットワーク管理者の権限が与えられていたため、リサーチャーはネットワーク構成を変更し、IVIシステムからTesla（テスラ）のセキュリティゲートウェイにパケットを転送することで、サンドボックスの保護を回避することができました。
セキュリティ上の学び
Synacktivの2つのバグを利用して連鎖的に攻撃を仕掛ける方法は、非常に複雑であり、最も安全なシステムでも侵害できてしまうという同チームの専門性を改めて示しました。しかし、彼らが攻略した脆弱性は、一般的なセキュリティ上の見落としによるものでした。
- 入力コマンドの検証が不十分であるために、接続モジュール上でリモートコードの実行が可能であった
- 不適切なバッファサイズの割り当てにより、Teslaのカスタム Ofono プラグインでヒープ バッファ オーバーフローが発生するようになっていた
- Teslaのシステムにはサンドボックスやファイアウォールなどの強力なセキュリティ強化策が施されていたが、設定ミスと不適切な実装により、最終的には突破が可能となっていた
これらのセキュリティ上の教訓は、高度に保護されたシステムでも、巧妙に仕組まれた攻撃の手口には屈してしまいかねないことを強調しています。特に、小さな脆弱性が看過され、対処されないままになっている場合、そのリスクは高いでしょう。
協調した脆弱性開示の時間軸に関する背景
Pwn2OwnイベントでZDIが、或るチームがデバイスやソフトウェアを「ハックに成功」または「pwned」と発表してから、そのハックに使用されたテクニックが公表されるまで、しばしば遅延があることに疑問を持たれた方も多いでしょう。この遅延は、ゼロデイ脆弱性をより責任を持って管理するために設計された調整型脆弱性開示（CVD）プロセスの一部です。
1990年代には、脆弱性を積極的に探し出すハッカーはごくわずかであり、多くのベンダーは脆弱性への対処に備えていませんでした。ホワイトハッカーもベンダーも、「ハッカーは利益と引き換えに脆弱性を報告しているのではないか？」や「脆弱性は修正されるのか、それとも報告は時間の無駄になるのか？」といった懸念を抱えていました。そして、次のような譲歩案が採用されることになりました。まずハッカーが脆弱性をベンダーに報告し、その後、ベンダーがパッチをリリースし、ハッカーの発見を公に認めるというものです。
ZDIの脆弱性開示ポリシーに基づき、提出された脆弱性は、パッチが利用可能になった時点で、またはベンダーが対応しない場合は一定期間経過後に開示されます。このアプローチにより、問題が解決されるか、または修正方法が知られていない脅威が公に認知されることで、脆弱性が悪用されるリスクが回避または抑止されます。これが、脆弱性が最初に提出されてから詳細が公表されるまでの時間差を説明するものです。
