8月25日2015年

テスラ Model Sのハッキング: そこで得た発見と教訓

投稿者 Kevin Mahaffey コメントなし

多くの人がコネクテッドカーを「時速100マイル以上で移動できるコンピュータ」として考えているのであれば、最悪の事態についてより真剣に考えることでしょう。しかし、コネクテッドカーのセキュリティ対策は確立されておらず、ベストプラクティスはいまだ実現されていません。

インターネットセキュリティの経験が全くない産業がモノのネット接続を始めたとき、システムの安全対策やセキュリティ業界との連携において、多くの過ちを犯すであろうということは想像に難くありません。

私は、同僚のマーク・ロジャースと共に、テスラモーターズ社のModel Sのセキュリティ調査を行いました。テスラの開発陣が持つ豊富なソフトウェア分野の経験からこの車が強力なセキュリティアーキテクチャを備えていると仮説を立て、その仮説を明確にしたかったのです。この調査結果を元に、自動車産業におけるセキュリティ面での簡潔で明確なベストプラクティスについてお話をしたいと思います。

私たちの仮説は正しかったことは証明されました。テスラのModel S は非常に精巧に設計されたセキュリティアーキテクチャを備えており、この業界の他社の手本となるべきものであると感じました。同時に私たちは多くの脆弱性も発見しました。例えば、自動車への物理的アクセスがあれば、インフォテイメントシステムのうち2つでルート化権限の獲得が可能であることを発券しました。ステアリングホイール上部にあるインストルメントクラスター（IC）、およびコンソールの真ん中にある17インチのタッチスクリーンによるセンターインフォメーションディスプレイ（CID）がその2つに当たります。これにより、私たちは遠隔操作によるトランクやバンパーの開閉、ドアの施解錠、車の発進、停止など様々なタスクを実行できました。

しかし、今回の調査で私たちが焦点を絞ったのは次の疑問への答えです；攻撃者がインフォテイメントシステムに侵入できたと想定して、攻撃に直面した時にも安全に運転できる車はどうやって作ればいいのか。なお、使用したエクスプロイト攻撃はどれも物理的アクセスがあって作動するもので、遠隔操作で作動するエクスプロイトを使用した検証は行いませんでした。自動車が遠隔操作で操られてしまうことは既に別の調査によって証明されています。また、WebKitを使用しているブラウザは攻撃者に十分な知識や設備があれば悪用される可能性があるとするのは過言ではないと思っています。

安全・倫理に関する指針

こうした脆弱性の認定作業に入る前に、今回の調査を行う際に配慮した安全・倫理に関する指針について言及しておきたいと思います。

  • 車両・安全システムには触れないこと。インフォテイメントシステムとそのネットワークのみとする。初期段階の調査を行うに当たり、不注意によって自動車の安全保持に関わる重要な機能そのものを損なうことは避けたいと考えました。
  • テスラサーバーには触れないこと。接続端末の監査では、検査しているのが端末なのか、それに接続している企業システムなのかが定かでないことがあります。そこで複数のテスト（待機時間の計測を含む）を用意し、検査を行っているシステムが実際に車両に搭載されているものであることを確認するようにしました。この指針は後に修正し、テスラのバグバウンティプログラムで許可があった場合に限り、テスラのインフラストラクチャの一部も対象とすることとしました。
  • ハードウェアまたはソフトウェアに恒久的な変更を加えないこと。Model S は決して安価なものではないため、損壊はできるだけ避けたいと考えました。

システム概要

TH-1

インフォテイメントのコンポーネントは車載LAN経由で通信します。車載（CAN）ネットワークと通信するには、すべてのコマンドがインフォテイメントネットワークとCANネットワークの双方にまたがる「ゲートウェイ」を通して届く必要があります。

TH2

調査内容

まず初めにModel Sについて情報収集行ったあと初期検査をし、攻撃手法の可能性を持つ要素を多数リストアップしました。この検査で自動車の物理的ハードウェアを分析し、自動車を標的にした物理的な攻撃手法の可能性となるものを整理しました。この分析から、以下のことが明らかになりました。

  • CIDボードに差し込み式のメモリーカードが2つ
  • CIDボードにUSBポートが1つ
  • 不明な4PINコネクタが1つ
  • テストポイントと診断用のインターフェースが多数

TH3

その後、初めにリストアップした攻撃対象領域のすべてについて侵入テストを行いました。結果は以下の通りです。

  • ブラウザ：脆弱性その１。WebKitベースのブラウザが利用されており、直近のテストで使用した自動車に搭載されているバージョンは534.34で、リリースから数年が経過しています。これには他のシステムへの不正アクセスに利用される既知の脆弱性が複数ありました。そのうちの2つを攻撃用利用し、ブラウザクラッシュの再現に成功しましたが、任意のメモリの読出しや書き込みはできませんでした。システム内のデバッガにアクセスができなければ、あてずっぽうに悪用することは困難と思われます。
  • Bluetooth：安全でないと思われるものは特に見つかりませんでした。
  • USB：USBポートをCIDのボードに接続し、端末をNVIDIA Tegraのリカバリーモードで起動することに成功しました。Bootloaderはパスワードで保護されるよう設定（パスワードは不明）されているため、このインターフェースを使ったファームウェアの復元はできませんでした。
  • メモリーカード：メモリーカードの1つにはファイル、carkeys.tarが格納され、自動車のOpenVPNの認証情報、詳しくはx509証明、RSA秘密キー、およびOpenVPNの静的キーがそこに保存されています。次世代の車キーはもちろん暗号技術を使用したものです。他にはマッピングデータが大量に格納されていました。
  • Wi-Fi：この自動車には開放ポートが見当たりません。しかし、有効なインターネット接続があると判断すると、OpenVPNサーバーへの接続を試みようとします。OpenVPNは正確に設定されており、サーバーの証明書と車の証明書が同じルート証明発行者までチェーン接続した場合に生じうる、中間者攻撃についても脆弱性はありませんでした。
  • 不明なコネクタ：これは非標準のインターフェースを持つイーサネット用コネクタであることが分かりました。私たちは標準のCat-5 UTPケーブルを解体してPINの設定を定義し、内部ネットワークとの通信に成功しました。

TH4

次にインフォテイメントシステム内部のさまざまなコンポーネントによって提供されるサービスの全体像を把握するため、内部ネットワークの検査を行いました。私たちは内部ネットワークにあるアクセス可能なサービスを30件以上確認しました。

このサービスのうちの2つは旧式で、既知の脆弱性があるものでした。

  • 安全ではないDNSプロキシ：The Model S はdnsmasq 2.58を使用しています。（脆弱性その2）
  • 安全ではないHTTPサービス：The Model S はmini_httpd 1.19を使用しています。（脆弱性その3）

これらのサービスを実行するシステムへアクセスを行う場合の脆弱性の利用方法についてはなかなか思いつかなかったため、発見された脆弱性の影響については調査しませんでした。

また、CIDとICが共にアクセス管理の形態を持たずにX11を使用していることを突き止めました（脆弱性その4）。

TH5

最後にICおよびCIDそれぞれで実行しているICアップデータおよびCIDアップデータ、2つのサービスを確認しました。これは「ステータス」コマンドを受信すると、インフォテイメントシステムに関する膨大な内部技術のステータス情報を共有するものです。

横やりが入ったことも

この調査の最中、イーサネットのインターフェースに関して他の人物による発見がネット上で伝えられたため、テスラがOTA経由でアップデートを発行し、内部LANとの通信ができなくなる事態となりました。

しかし、ICはそもそもネットワークであり、類似の4PINイーサネットケーブルが付属していたことを理解していたため、ICのイーサネットポートの裏側にインターフェースを作ってこれを外部イーサネットに接続してICと内部スイッチを繋ぎ、内部LANへのアクセスを維持できました。

TH6

目覚ましい発見

私たちはある日、CIDアップデータのステータスアウトプットに次のような、非常に特異なURLが含まれていることに気づきました。

firmware_download_url = hxxp://firmware-bundles.vn.teslamotors.com:4567/…

このために車のファームウェアがどこからダウンロードできるかわかったのです（脆弱性その5）。

またほぼ同時期に、テスラがバックエンドシステムのセキュリティを監査するパーミッションを与え、バグバウンティプログラムを開いていることも知りました。そこでこちらで持っているVPNキー（上述のメモリーカードから取り出したもの）と、Model SのOpen VPN設定に関する知識を駆使し、VPN接続を確立して車のファームウェアアップデートをダウンロードしました。

ファームウェア: 後に646,422,592 バイト となる

ファームウェアのバンドルはSquashFSファイルシステムで、 いつでも抽出可能です。

このファームウェアの分析結果から導き出された所見を以下に述べます。

  • この車がサーバーとなっている：通常のデータセンターシステムに備わっているようなログローテーションや他のスクリプトが備わっています。
  • テスラのエンジニアはモンティ・パイソンのファンである： hxxp://firmware-bundles.vn.teslamotors.com:4567/custom-packages/knights-who-say 宛てにリクエストを送るスクリプトが車内にあります。そしてレスポンス本文には「ni」の言葉の行が何千行も含まれています。
  • ファームウェアバンドルには秘密キーがないこと。
  • ICには暗号化されたパスワードファイル（シャドウファイル）があること。
  • シャドウファイルの解読を試みると、IC上のユーザーアカウントの多くはそのパスワード強度が非常に低いため、容易に突破できることが分かりました（脆弱性その6）。

これらの認証情報を使用してICにログインすると、このアカウントがsudoerであり私たちはルート化特権を獲得できることにすぐに気づきました。

次の段階はCIDへのアクセスですが、CIDはインフォテイメントシステムの「メイン」部分です。ファームウェアをさらに分析すると、CIDにはキーローテーションのスキームがあり、ランダムなセキュリティトークンがテスラの「母艦」（サーバー本来の名称）から車に24時間毎に新しく送信されることが分かりました。CIDはその後このトークンに対し「tesla1」アカウントのパスワードを設定し、ICに新しいトークンを通知します。ICはこのトークンをプレーンテキストで自身のファイルシステムに保管します。

私たちはICから送信されたこのトークンを利用し「tesla1」としてCIDにログインしましたが、このアカウントもまたsudoerでした。こうして、CIDとICを両方ともルート化に成功したのです。

その他の調査結果

この結果、その他にも数多くの発見がありました。

  • ローカルでX11サービスにアクセスすると、運転中にインストルメントクラスターのディスプレイを妨害できること。
  • CIDはDSAキーを保管しており、これがSSH経由でICにログインする場合に使用されること。
  • 私たちはUDPブロードキャストパケットを送信してイーサネットポートを再有効化することに成功しました。これには30秒ごとに送信されるセキュリティトークンから引き出したキーを使用しました。ダッシュボードの分解は以降必要なくなりました。
  • VPNキーを使用すると、車の分解やICのイーサネットインターフェースのハッキングをすることなく最新のセキュリティトークン（毎24時間で更新）の取得が可能であること。
  • ファームウェアバンドルにはドライブシステムファームウェアのイメージらしきものが格納されていること。今回はこのアップデート過程のセキュリティメカニズムについての評価は行いませんでした。この分野での更なる調査を期待します。
  • サービスセンターで使用されている「テスラサービスWi-Fiネットワーク」は不変かつ静的なWPAキーを使用していること。これはファームウェアのバイナリの1つに格納されています。

自動車のコントロールは可能か

インフォテイメントシステムの制御を奪うとどの程度まで自動車全体の制御を奪えるかの答えを知るべく、私たちはCIDに搭載されている「正規の」自動車制御システムの仕組みを調べることにしました。

Model S の内部LANは比較的トラフィック量が多く、UDPブロードキャストメッセージが1秒間におよそ500-1000回発生しています。これらのメッセージの中から有効な自動車制御用のメッセージを選りだすのは非常に根気を要する作業です。

これを解明するため、私たちはtesucat（githubで公開しているオープンソース）というツールを構築し、特定のポートについてのUDPブロードキャストパケットをモニターしつつ、過去には見られなかったパケット（一意性は固定ウィンドウのバイト数の算出で決定）を受信した場合にはすぐ判別を行いました。

トラフィックの標準化、そしてCIDおよびスマートフォンアプリから種々の自動車制御コマンドを実行したことで、目的とするパケットの判別、およびCIDにあるそれらを送信する役割を担うサービスの判別が短時間で可能となりました。

このサービスのリバースエンジニアリングの一部から、テスラのModel Sではインフォテイメントシステムから自動車に未処理のCANフレームが送信されることはないらしいことが分かっています。その代替として、「自動車用API」（VAPI）があり、これを使用してCIDがゲートウェイに「許可されている」アクション群のうちのいずれかを行うよう要請します。

このような方法で遂行されるゲートウェイの存在は自動車の復元能力にとっては非常に有益です。これはインフォテイメントネットワークがたとえ不正アクセスされたとしても、攻撃者に未処理のCANフレームを車載ネットワークに注入する権限を認めることにはつながらないことを意味するからです。攻撃者にできるのはせいぜい「正規の」VAPIリクエストの送信だけです。

インフォテイメントの不正アクセスが即、攻撃者が車載システムと直接通信する能力を獲得するわけではないということは、攻撃に耐えうる能力がゲートウェイに備わっていると言っていいでしょう。今回はゲートウェイのセキュリティ能力について掘り下げた監査を行なわなかったため、今後この分野で更に調査が勧められることを期待します。

調査中、私たちは実行可能な「正規の」VAPIコマンドを多数確認しましたが、おそらく最も注目すべき点は自動車の「電源オフ」能力と思われます。テストの実施によって、自動車運転中にVAPIコマンド送信ができること、また自動車が確実に電源オフを遂行しようとすることを確認しました。低速（およそ時速約5マイル（約8キロ）以下）の場合、Medel Sは直ちにブレーキを使用して急停止します。時速5マイル以上の場合、Medel Sは効率的にニュートラルにシフト移動し、ブレーキを使用せずに加速を停止します。この時点では運転者が引き続きステアリングやブレーキの制御を行えることを書き添えておきます。

これらの運転制御システムのインタラクションの安全性を閉じられた環境内で、すべて時速10マイル以内でテストしました。

この問題に対するテスラの対応
私たちはテスラと非常に良好な協業関係を築くことができました。また、テスラがModel S全車を対象にOTA経由でアップデートを迅速に（1-2週間以内）プッシュできたことは、本当に喜ばしい限りです。

このアップデートの配布によって私たちが指摘した数多くの脆弱性が修正されました。また、システムがゲートウェイと通信できる機能を閉じたほか、ブラウザへの不正アクセスに耐えうるようにCIDの能力を向上させたことなど、全体的なシステム強化が行われました。

テスラの開発陣が自社製品のセキュリティに真摯に取り組む姿勢はこちらにも伝わり、チームとの情報交換は非常に実り多いものとなりました。

調査結果の要約

Model Sへのアクセスを果たすには、複数の脆弱性を利用し複数の段階を経た攻撃を行わなくてはなりませんでした。この自動車への不正アクセスは企業を標的にした高度な脅威における手法と似ており、攻撃者による単純な埋め込みシステムへのハッキングではなく複数システムへの侵入を同時進行で行うものでした。

これらの調査結果は下図で示す「キル・チェーン」に要約されます。この図では外部の人間に入手可能な方法全てを具体的に記載しています。これらの方法によって Model S内部に対する侵入を並行して進め、悪意ある攻撃者にとってのゴールである、運転者や自動車そのものを妨害するということが実現されてしまうのです。

TH7

この調査は多くの脆弱性を指摘し、テスラはそれに対処しました。一方で、以下のような非常に優れたアーキテクチャがテスラの開発陣によって行われたことは間違いありません。

  • OTA経由のアップデート処理：テスラにセキュリティ脆弱性を修正する必要が生じた時には、運転者がボタンを1度押すだけでその作業が適用されます。リコールやメールによるUSBキーの送信は必要ありません。さらに、こうしたアップデートの受信のためのワイヤレスデータ通信サービスへの登録も不要で、アップデートは無料で配布されます。
  • VPN設定：Model Sは適切にVPNが設定されており、ありがちな設定ミスによる問題はありませんでした。
  • アカウントパスワードローテーション：自動車に設定されたアカウントパスワードは24時間毎に上書きされます。
  • 車載システムとインフォテイメントシステムとの分離：Model Sにはゲートウェイシステムが搭載されており、インフォテイメントシステムに明確なAPIを提供するためインフォテイメントシステムがCANに直接接続することはありません。

同時に、Model S には改善が必要な部分も数多く存在すると思われます。

  • 「テスラサービス」のWi-Fiは静的WPAキーを使用します。静的キーを自動車間で共有することがないよう、WPAエンタープライズ証明の使用が望ましいでしょう。
  • 境界セキュリティモデル。Model Sは非常に強力な境界セキュリティのセットを備えていることは歓迎すべきことです。しかし内部システムには同レベルのセキュリティがありません。自動車のセキュリティモデルの構築では攻撃者にインフォテイメントネットワークを乗っ取る能力があると想定すべきです。
  • プレーンテキストによる認証情報の保管。VPNキーおよびセキュリティトークンはいずれもプレーンテキストで保存されています。ハードウェア領域（TPMやTrustZone、セキュアエレメントなど）に保存する方が望ましいと思われます。
  • インフォテイメントシステム間のトラフィックが暗号化されていない、また証明されていない場合があります。インフォテイメントLAN上で通信するサービスは暗号化の形態が全く取られていないため攻撃者による全トラフィックの監視が可能です。
  • さらにサービスの中で認証を行うものは極めて限定的です。境界セキュリティモデルからコンポーネントレベルのセキュリティモデルへ移行するにあたり、コンポーネント間のすべての通信についてネットワーク自体がゼロトラスト（信頼せずに常に検証する）であると想定すべきです。

業界全体に向けたベストプラクティスの提言

私たちは今回の調査によって自動車関連のサイバーセキュリティ周辺の議論が、特にコネクテッドカーの製造に際して、全ての自動車メーカーが実践すべきベストプラクティスの確立について発展することを願い、以下の提言をします。

  • OTA経由のアップデート処理：所有者による他サービスへの登録が不要であれば理想的です。
  • 車載システムとインフォテイメントシステムの分離：これを適切に設定して、あらゆるゲートウェイシステムが最大限のセキュリティ監視を受けることが重要です。
  • 各コンポーネントのハードニング：修復能力に優れたコネクテッドカーにおけるサイバーセキュリティアーキテクチャを構築したいなら、 不正アクセスされるコンポーネント（ウェブブラウザなど）があることを想定して対策すべきです。コンポーネントの1つが不正アクセスされてもシステム全体の機能性は損なわれないシステムを構築する必要があります。

数多くのプロジェクトがこうした議論の活性化を目的として動いています。Five Star Automotive Cyber Safety Programはその一例です。サイバー攻撃に対して、さらに修復能力に優れたコネクテッドカーの製造に向けて、あらゆる支援が望まれます。

最後にこのプロジェクトに有形無形の貢献をしてくださった方々－John Hering、Alissa Rogers、Vishal Verma、Meghan Kelly、Steve Regester、Michael Bentley、Alicia diVittorio、Kurt Opshal （EFF：電子フロンティア財団）、 Joe Grand、Tim Wyatt、Blaine Schanfeldt、Daniella Vallurupalli、Jeremy Linden、Tim Strazzere、Caleb Fenton、Nam Bui、Lauren Hampton、Dana Palmie、Heather MacKinnon－に心より感謝の意を表したいと存じます。

その他の最近の記事

コメントを入力