自動車の脆弱性トレンド｜国内最大規模の自動車セキュリティ診断実績から見る傾向とは

　2015年、北米である車両が脆弱性を突かれ、遠隔からのサイバー攻撃を受けるという実証実験に晒されて大規模なリコールに至ったことをきっかけに、自動車に対するセキュリティに注目が集まりました。それから毎年のように、自動車の電子機器に関する新たな脆弱性が報告され、その波はまだ収まっていません。自動車業界では、サイバーセキュリティ脅威に対抗する活動を急速に進めており、代表的な活動として車両に対するサイバーセキュリティの国際基準（WP29/UN-R155, ISO/SAE21434）により、今後公道を走る自動車においてはサイバーセキュリティへの対応が必須となることが決まっています（車両型式認証）。

　そんななか、NRIセキュアと世界的自動車部品サプライヤであるDENSOによって、2018年12月に株式会社NDIASが設立されました。NDIASは、自動車分野に専門性を発揮できるセキュリティサービス提供企業として、車両および車載ECU（Electronic Control Unit）に対するセキュリティ診断や自動車セキュリティの法規対応を含めた幅広いコンサルテーションサービスを提供しています。

　NDIASでは、これまでのセキュリティ診断実績から、自動車の脆弱性傾向を分析し、「DEF CON 28 Car Hacking village」で報告しました。本記事では、NDIASがDEF CON 28のCar Hacking Village内で発表した、「Realistic Trends in Vulnerability based on Hacking into Vehicle」の内容から、自動車のセキュリティと脆弱性の傾向について紹介します。

ネットワークシステムの様なコネクテッドカーの構成

　近年、多くの自動車には車両外（out-car）との接続を行うECUが搭載され、インターネットに常時接続されるようになりました。これらの自動車はコネクテッドカーと呼ばれ、大きなネットワークシステムのような構成をしています。これは自動車が多くのITシステムと同様に、リモートから攻撃を受ける可能性が増えたことを意味し、特に自動車では、リモートからの攻撃により、内部にまで侵入された場合に、「走る・止まる・曲がる」といった自動車の基本制御を奪われ、人命に影響する重大な事故につながる可能性があることを意味します。

車載ECUは、大きく3つのカテゴリに分けられます。

• １．情報系ECU
• バックエンドサーバやインターネットなどの自動車の外部環境と接続するインターフェースを持つ車載ECUです。ユーザインタフェースを持つIVI（In Vehicle Infotainment）や携帯電話網に接続する機能をもつTCU（Telematics Control Unit）などが代表的な例です。自動車へのサイバー攻撃の最初のステップとして、セルラー、Wi-Fi、Bluetooth、USBなどが経路として使われる可能性があります。
•  
• ２．GW (Gate Way)
• 情報系と制御系を分離するファイアウォールの役割を持つ車載ECUです。情報系ECUから内部の制御系ECUへの攻撃の踏み台として使われる可能性があります。
•  
• ３．制御系ECU
• 自動車の制御に関わる車載ECUです。例えば、エンジン・ステアリング・ブレーキなどの制御、自動運転、ドアのロック/アンロックなどを直接行います。これらの車載ECUにまで攻撃が及ぶと、自動車の制御を奪われ重大な事故に繋がる可能性があります。

図１：車載ECUと自動車の構成

自動車のセキュリティ診断方法

　自動車のセキュリティ診断には2つの方法があります。1つ目は、車両自体を対象とするセキュリティ診断です。2つ目は、各車載ECUを対象とするセキュリティ診断です。これらの診断方法には、それぞれ異なる特徴があります。車両自体を対象とするセキュリティ診断は細部まで確認することは難しいですが、車両の挙動への影響をすぐに確認することができます。⼀方、車載ECUを対象とするセキュリティ診断では、細部まで確認することができますが、車両全体への影響を見ることができません。

　以上の特徴から、いきなり車両自体を対象としたセキュリティ診断を行うよりも、まずは車載ECUごとにセキュリティ診断を行い、車載ECUにおける脆弱性を洗い出すことが必要です。その後、車載ECUごとに検出された脆弱性が自動車全体にどのような影響を与えるのかを、車両の統合テストにより確認することがより良い方法だと考えています。

　車載ECUは、ハードウェア（HW）、インタフェース、OS/OSS、アプリケーションなど複数の要素で構成されており、脆弱性はそのどこにでも存在する可能性があります。セキュリティ診断では、HW/SWのスタックごとに、インターフェースとソフトウェアの視点でテストを行います。インターフェーステストは、車載ECUのインターフェースから脆弱性を検出する「ブラックボックステスト」の⼀つです。ソフトウェアテストは、「ホワイトボックステスト」や「グレイボックステスト」の1つです。

インターフェーステスト

　物理インターフェースのテストでは、車載ECUの基板に実装されたチップに対して、JTAGやUARTのようなデバッグ用のポートにアクセスできてしまわないかを確認します。ファームウェアの抽出や書き換え、内部シェルへのアクセスなどを試みます。

　リモートから攻撃される可能性がある、セルラーインターフェースやWi-Fi、Bluetoothといったインターフェースでは、その無線通信の使い方に問題が無いか、またその上で行う通信内容に脆弱性（例えば、重要なデータを平文で送る、接続先の認証を行っていないなど）はないか確認します。

ソフトウェアテスト

　ソフトウェアテストは、2つの方法で確認します。1つは、動的解析によるテストです。車載ECUが動作している状態で、SSHやUARTからシェルアクセスをして、内部の動作を確認します。実行中のプロセス、ログファイル、ライブラリのバージョン、設定、クレデンシャルファイルなど、確認観点は多岐に渡ります。

　もう1つは、静的解析による脆弱性の確認です。物理I/Fのテストによってファームウェアを抽出できた場合、それをIDA proやGhidraといったツールを使い、逆アセンブラや疑似コード化して、脆弱性が無いか調査します。ファームウェア内にファイルシステムが含まれている場合は、それらをファイルごとに抽出して解析することで、個別のアプリケーションの実装上の脆弱性を特定することが可能になります。

図２：車載ECUの構成とテスト方法のカテゴリ

300以上の脆弱性から見える自動車における脆弱性の傾向

　NDIASでは、これまで10社以上の自動車メーカ・サプライヤが開発した40個を超える車載ECUに対してセキュリティ診断を実施し、延べ300件以上の脆弱性を検出してきました。

　対象とした車載ECUの内訳は、IVIが⼀番多く全体の37%、次いでTCU、GWが18%、それ以外が27%です。このことから、攻撃経路となるインターフェースを持つ情報系ECUのセキュリティ診断が最も重要と考えられていることがうかがえます。

車載ECUの脆弱性の検出箇所の傾向

　次に、これらの車載ECUで検出された脆弱性が、車載ECUのどの部分から検出されたかを見ます。まず注目すべきはOS/OSS/Off-the-shelf領域で、脆弱性のおよそ70%が検出された点です。これらの多くは、OSの設定不備や、CVEに脆弱性が報告されているOSSを利用しているなどです。この脆弱性は、自社開発以外の部分であり、既に解決策があるという特徴を持ちます。そのため、適切なソフトウェアの設定を実施したり、製品のバージョン管理を行ったりするだけで多くの脆弱性を削減することが可能と考えられます。

図３：対象ECUの内訳と脆弱性構成カテゴリ

脆弱性のカテゴリ別の傾向

　NDIASでは、検出した脆弱性について弊社基準による5段階のリスク値（High、Medium、Low、Very Low、Info）で示しています。ここでは、リスク値が高い（High & Medium）脆弱性だけに絞ってその傾向を分析しました。グラフからも明らかなように、認証に関する脆弱性とソフトウェアアップデート処理に関する脆弱性が非常に多くの割合を占めています。この2つの問題は自動車に大きな脅威を与え得る問題です。

　認証の脆弱性の多くは、クレデンシャルの保管方法に問題がありました。ID/PASSを平文でそのまま保存しているなどが⼀例です。アップデート処理に関しては、アップデート用ファイルの署名検証を厳密に行っていない問題が多くみられました。これはOS/OSSの使い方に問題がある場合とアプリケーションのコーディング上に脆弱性があるパターンどちらも多く見られています。

図４：リスク値が高い脆弱性カテゴリの検出傾向

リモートアタックI/F別の脆弱性の検出傾向

　次に、リモートからの攻撃経路となるI/Fについて見ていきます。実はBluetoothが⼀番多くの脆弱性が検出されています。特に認証バイパスに関する脆弱性が多く検出されました。これは、Bluetoothのセキュリティ対策がまだ浸透していないからだと考えています。⼀方で、Wi-Fiやセルラーはそれほど多くの脆弱性は検出されていませんが、中には認証バイパスできるような重大な脆弱性も検出されました。

図５：リモートアタックI/F別の脆弱性の検出傾向

物理I/Fの脆弱性が残存する車載ECUの割合

　次に、車載ECUの物理デバックI/Fの脆弱性の傾向を見ていきます。全ての車載ECUのうち、約70%で何かしらのデバッグI/Fが残っていました。まだ多くの車載ECUで対策がされていないことが分かります。その内訳としては、JTAGなどのCPUに対するデバッグアクセスができる車載ECUが41%、UARTなどからシェルアクセスができる車載ECUが32%、外付けのeMMCなどからファームウェアが抽出できる車載ECUが44%です。

図６：物理デバックI/Fの脆弱性の残存率

テスト方法の違いによる脆弱性の傾向

　インタフェーステストだけで脆弱性を検出するのは限界があることも見えてきています。例えば、通信データをキャプチャした結果を見てもわかるのは、通信路におけるセキュリティ対策がされているか否かだけであり、その通信データを処理するソフトウェアや通信の認証処理に脆弱性があるかどうかまでは読み取れません。

　そのため、私たちはソフトウェアテストによって、より多くの脆弱性を検出しています。実際に、ソフトウェアテストで検出した脆弱性はインタフェーステストで検出した数の2倍あります。また、ソフトウェアテストでは、インタフェーステストと比較して、リスクの高い脆弱性を検出できる傾向にもあります。その理由は、すでにある程度の対策を実施しているからだと考えられます。 特にツールを利用したスキャンで検出できるような脆弱性やリスクが高い脆弱性はすでに対策されているように見受けられます。

図7：テスト方法の違いによる脆弱性検出傾向

5つの解決策でリスクが高い脆弱性の85%を緩和する

　最後に5つの解決策について紹介します。ここで紹介する内容を実施すれば、リスクが高い脆弱性の85%を緩和することができます。

1. 認証機能がある場合、クレデンシャルや秘密鍵はTrust Zone, TPM, HSMなどのセキュアエレメントに保管する。
   認証に関する脆弱性の多くは、クレデンシャル・秘密鍵の保管方法に問題があるため、セキュアな方法で保管することが求められます。
   
   
2. 署名検証は厳密に実施する。
   署名検証はしているが、タイミングによっては回避できるような脆弱性もあるため、より厳密な実装が求められます。
   
   
3. 乱数/暗号アルゴリズムは推奨されているものを使用する。
   独自に実装した関数を用いて強度が不足するケースがあるため、推奨されたアルゴリズムを使用することが求められます。
   
   
4. OS/OSSについて3つの注意事項を守る。
   OS/OSSに関する脆弱性の多くは、既に解決策が用意されており、それらを適切に利用することが求められます。
   ▼OSSをセキュアに使用する。例えば、TLS接続においてサーバ証明書の検証をスキップしていないかなどです。
   ▼ソフトウェアの構成とバージョン管理をする。
   ▼OS/OSSのセキュアな設定をする。
   
   
5. ハードウェアのデバッグポートを閉じる。
   デバッグポートからファームウェアを抽出されることは直接的な問題ではありません。しかし、その結果、ソフトウェア解析をされ、リスクの高い問題につながる可能性があるため、対策することが求められます。

ご参考

株式会社NDIAS

NDIASは、自動車に関連するあらゆるセキュリティ上の課題解決を支援します。
In-Car、Out-Car問わず、セキュリティ診断、コンサルティング、教育、PSIRTおよび運用をご支援するサービスを提供しています。