ファームウェア・ラチェットのバイパス：Tesla Wall Connector の脆弱性を突く

組み込みデバイスのセキュリティは、古い脆弱なファームウェア・バージョンのインストールを防ぐメカニズムである「セキュリティ・ラチェット」に依存していることが多い。正しく実装されていれば、セキュリティ・パッチが適用された後、攻撃者が既知の脆弱性を悪用するためにデバイスを以前のバージョンにロールバックすることを防ぐことができる。しかし、Tesla Wall Connector (AW-CU300) の最近の分析により、このラチェットの強制力がどのように適用されているかにおける重大な欠陥が明らかになった。

アップデート・フローと、ファームウェア・アップデーターとブートローダー間の相互作用を分析することで、研究者は、ダウングレード防止チェックがアップデート・プロセス中のみ実行され、起動時には実行されないことを発見した。この設計上の見落としにより、レガシーな脆弱性へのアクセスを復元する高度なバイパスが可能になる。

アップデート・メカニズムとセキュリティ・ラチェット

Tesla Wall Connector は、デュアルスロット・ファームウェア・アーキテクチャを採用している。すなわち、1つの active スロット（現在実行中）と、1つの passive スロット（アップデートの対象）である。標準的なアップデート手順は、Unified Diagnostic Services (UDS) プロトコルを使用した Single-Wire CAN (SWCAN) を介して、厳格なシーケンスに従う：

  1. Session Initialization: UDS セッションを開き、特定のセキュリティ・アクセス・アルゴリズムを使用して認証を行う。
  2. Preparation: ルーチン 0xFF00 を実行して、passive スロットを消去する。
  3. Data Transfer: 新しいファームウェア・イメージを passive スロットにプッシュする。
  4. Validation: ルーチン 0x201 を実行して、イメージを検証し、スロットを切り替える。
  5. Reboot: ルーチン 0x202 を実行して、デバイスを再起動する。

バージョン 24.44.3 において、Tesla は check_image_and_antidowngrade() を導入した。この関数は、ファームウェア・セグメントを解析して、バージョン記述子 (VRSN) とラチェット値 (VRS2) を解析する。ファームウェアのラチェット値が、Persistent Storage Manager (PSM) に保存されている現在の値よりも低い場合、アップデートは拒否され、passive スロットは直ちに消去される。

設計上の欠陥：ブートローダーの盲点

重大な脆弱性は、ファームウェア・アップデーターとブートローダー (boot2) の間の役割分担にある。アップデーターはセキュリティ・ラチェットのチェックを熱心に行うが、ブートローダーはそうではない。

デバイスが起動する際、boot2 はいくつかの不可欠なチェックを行う：

  • マジック・ヘッダー (SBFH) を検証する。
  • セグメントごとの CRC32 値をチェックする。
  • 保存されたキーに対して RSA 署名を検証する。

決定的なことに、ブートローダーはセキュリティ・ラチェットの概念を持っていない。 署名が有効で CRC が正しいファームウェア・イメージであれば、バージョン番号に関係なく実行する。 ダウングレード防止保護は、UDS ルーチン 0x201 の呼び出し中の switch_to_new_firmware() 関数によってのみ強制される。

バイパス戦略

ラチェットをバイパスするには、攻撃者は、特定のイメージに対して 0x201 検証ルーチンをトリガーすることなく、署名済みの古いファームウェア・イメージを active スロットに導入する必要がある。研究者は、デバイスがどのスロットが active であるかを決定する方法を悪用することで、これを達成した。

ブートローダーは、パーティション・テーブル内の gen_level (世代レベル) に基づいて active スロットを選択する。gen_level が最も高いスロットが選択される。part_write_layout() 関数はこのカウンターをインクリメントしてスロットを切り替える。

攻撃シーケンス

  1. Legitimate Update: 攻撃者は、有効で最新のファームウェア・バージョンを passive スロットにプッシュし、ルーチン 0x201 を呼び出す。検証は通過し、パーティション・レイアウトが更新され、このスロットに最も高い gen_level が付与される。
  2. Slot Erasure: 再起動せずに、攻撃者はルーチン 0xFF00 を再び呼び出す。セッション中のブート・フラグが変更されていないため、デバイスは同じ物理スロットを「passive」として選択し、たった今検証されたファームウェアを消去する。
  3. Malicious Payload: 攻撃者は、空になったスロットに、署名済みだが脆弱な古いファームウェア・イメージをプッシュする。
  4. Forced Reboot: 攻撃者はルーチン 0x201 (これが古いファームウェアを拒否するはずである) をスキップし、ルーチン 0x202 を再起動のために呼び出す。

再起動時、ブートローダーは、古いファームウェアを含むスロットが最も高い gen_level を持っていることを確認する。RSA 署名を検証し（ファームウェアは Tesla の公式リリースであるため、署名は有効である）、ブートローダー・コード内にラチェット・チェックがないことを確認し、古いファームウェアを実行する。

影響と対策

このバイパスは、Wi-Fi 認証情報の UDS リーク、telnet によるデバッグ・シェルへのアクセス、および引数パーサーのバッファ・オーバーフローを含む、一連の脆弱性を実質的に復元する。 Wall Connectors は通常、家庭用またはビジネス用ネットワークに接続されているため、侵害された充電器は、攻撃者がローカル・ネットワーク内で横移動（ラテラル・ムーブメント）を移動するための持続的な足がかりとして機能する。

提案された修正策

この欠陥を閉じるために、研究者はいくつかの対策を提案した：

  • Bootloader Enforcement: ラチェット・チェックをブートローダーに移動し、どのような方法でフラッシュに書き込まれたとしても、バージョン番号に関係なく、いかなるバージョンも起動できないようにする。

  • Layout Invalidation: ルーチン 0xFF00 を修正して、スロットが消去された際にパーティション・レイアウト・エントリを無効化し、消去・再書き込みされたスロットが起動できないようにする。

  • Session Constraints: アップデートの成功後に強制的な再起動を要求するか、あるいはレイアウトがコミットされた後に新しいアップデート・セッションを・スロットを切り替える。

Tesla はその後、この脆弱性をファームウェア・アップデートで修正した。これは、組み込みセキュリティにおける繰り返されるテーマをハイライトしている：セキュリティ・チェックは、ブート・チェーンにおける最も弱いリンクに依存する。システムが状態遷移を処理する方法によって強制メカニズムがバイパスされると、システム全体のセキュリティ・モデルが崩壊する。

Sources