20年以上前のネットワーク規格が自動車や人命をセキュリティリスクにさらす：セキュリティ業界、1440度（20）（2/2 ページ）

「クルマ×セキュリティ・マップ開発の先端」セミナーと、2017年で4回目の開催となる「escar Asia」において興味深かったセッションをピックアップして紹介します。

[株式会社FFRI，＠IT]

AGL（Automotive Grade Linux）に存在した脆弱性

　NRIセキュアテクノロジーズでサイバーセキュリティ技術開発部上級セキュリティコンサルタントを務める野口大輔氏は、講演で「AGL（Automotive Grade Linux）」のセキュリティ分析から明らかになった脆弱性を取り上げました。

AGLとは

　AGLは、IVIをはじめとした車載機器向けLinuxディストリビューションです。Linux Foundationのワーキンググループが主導して、AGLの開発を進めています。その目的は、現在、各社がプロプライエタリソフトウェアとして実装しているOSなどのソフトウェア基盤を共通化することです。共通化により各車両特有の脆弱性が発見、修正しやすくなることで、セキュリティの向上が期待できます。

　AGLは、IVIのシステム基盤だけではなく、車両の制御機能などへの拡張性も有しています。上述のワーキンググループには、トヨタやマツダなどの自動車メーカー、デンソーやHarmanなどのサプライヤー、IntelやNVIDIAなどの機器メーカーも参画しています。

　トヨタは、2017年夏に発売された2018年型「カムリ」のIVIにAGLを採用すると発表。AGLは今後、同ワーキンググループに参画する自動車メーカーの実装するIVIシステムにおいて、主流のOSになると考えられます。

「ConnMan」のDNSレスポンスメッセージ処理部分に脆弱性

　続いて野口氏は、Wi-Fi（802.11）による無線接続を主な攻撃経路として、AGLの関連領域であるカーネルドライバやサプリカント、ネットワークマネジャーが受ける影響を調査した結果を公表しました。これらの領域は、OSI参照モデルの物理層からネットワーク層のコンポーネントです。同調査では、Raspberry Pi 2と仮想マシンでAGL 3.0（Charming Chinook）を実行し、検証を行ったとのことです。

　検証の結果、ネットワークマネジャーとして採用されている「ConnMan」のDNSプロキシ機能において、DNSレスポンスメッセージの処理部分に脆弱性を発見したとのことです。この脆弱性は「ConnManDo」という名称で“CVE-2017-12865”として報告されており、2017年8月に修正されました。この脆弱性では、悪意のあるDNSサーバより受け取ったレスポンスメッセージを処理する際、文字列の長さチェックが適切に行われないことで、スタックバッファオーバーフローが生じます。攻撃には再現性がありますが、ConnManの動作する端末が直接通信を行う、DNSサーバを乗っ取って攻撃を行う必要があります。これらの点から、CVSS v2 Scoreは7.5、CVSS v3 Scoreは9.8（注5）とされています。

注5：CVSS v3は、CVSS v2を発展させたものであり、脆弱性の評価方法や攻撃可能性などの観点を加え、コンポーネント単位で評価する脆弱性評価システム

　なお、この脆弱性は、ConnManに存在するものであり、AGLに特有の脆弱性ではありません。ConnManの脆弱性の存在するバージョンを利用している全てのディストリビューションが影響を受けます。

　発表中のデモでは、VMware Workstation上で動作する2台のLinuxマシンを使って、攻撃者（Kari Linux）からPythonで作成したPoC（攻撃実証コード）を実行。Ubuntuで動作する「ConnMan Version 1.34」に存在する脆弱性を利用し、root権限のshellを奪取していました。

攻撃者のKari Linuxから、Ubuntu上で動作するConnMan Version 1.34にPoCを実行している様子

自動車は今や、“走るコンピュータ”

　野口氏は、今後必要なこととして、システム全体をユーザー空間とカーネル空間に分けた上で、それぞれの空間で実施すべきセキュリティ対策を紹介しました。

　「カーネル空間では、シリアルコンソールの無効化や不要なドライバの無効化、製品出荷時にデバッグ機能の制限を行うこと。ユーザー空間では、DEPやASLRなどの攻撃緩和技術の有効化や最新版のパッチ適用、セキュリティオプションの利用、不要なサービスなどの無効化など、通常のコンピュータと同様の多層防御が重要だ」（野口氏）

製品のソフトウェアアップデートを行う手段についても、検討すべき

　なお、講演後の2017年9月12日に「BlueBorne」と呼ばれるBluetoothの実装における脆弱性の情報が公開されました。BlueBorneは複数の脆弱性の総称です。その影響は、WindowsやLinux、Androidなど多岐のOSに及んでいます。AGLで採用されているBlueZモジュールも影響を受け、遠隔からのコード実行攻撃を受ける可能性が指摘されています。

　製品出荷後に脆弱性が発見された場合、何らかの手段でパッチを適用する必要があります。車両ソフトウェアには大量のバグが潜んでいるといわれ、AGLの場合も、OTAアップデート（注6）は必須です。

注6：無線ネットワークを経由した通信で行うアップデートのこと

　製品そのもののセキュリティ対策だけではなく、その後の製品のソフトウェアアップデートを行う手段についても、検討する必要があるでしょう。

CANの暗号化は有効であるが、十分ではない

　車両向けのオーディオ機器やシステムなどを手掛けるHarmanで、研究開発・自動車向けサイバーセキュリティ担当シニアディレクターを務めるYuval Weisglass氏の講演は、CANメッセージ認証の課題と限界、同認証を狙った攻撃手段を取り上げました。CANメッセージの標準フォーマットはデータフレームの送信先の識別情報を含んでいますが、送信元の識別情報は含んでいません。

　現在主流である「CAN 2.0」は、1991年にドイツのBoschが発行したものです。当時は、現在のように高度な車内ネットワークを想定していなかったため、メッセージ送信元の識別情報を含まない仕様になったと考えられます。

　「CANを採用している車内ネットワークでは、CANメッセージの送受信において認証を行っていない点が重大な問題であり、なりすまし攻撃などを受ける可能性がある」（Weisglass氏）

　現在、この問題の解決策として、CANメッセージのペイロード中に認証情報を追加する手法が普及しています。ただし、CANメッセージの標準フォーマットは、通信に必要なフィールドを除いたデータのペイロード長（payload length）（注7）を最大8バイト（64bit）と規定しています。そのため、必要なデータと認証情報を8バイト以内に収める必要があり、十分にセキュアとはいえません。

注7：通信パケットのうち、転送可能なデータの最大量。ヘッダ部分のデータ量を除く

　Weisglass氏は、実際にPoC（攻撃実証コード）を作成し、レインボーテーブルを使った手法やブルートフォースアタック（総当たり攻撃）などの攻撃手法により、暗号化された認証情報が復号可能であると示しました。上述のCANのペイロード長も、1バイト文字であれば8文字分と考えれば、容易に復号が可能であることが想像できます。

CANの標準フォーマットについての発表資料。赤で塗りつぶされている部分がペイロードであり、1バイトとなっている

　CANの通信帯域が最大で500kbpsであることから、同氏は、「大量のメッセージをネットワークに流し込む事で、DDoS攻撃を受ける可能性もある」と指摘しました。この点については、広島市立大学の井上氏による講演でも、デモを紹介しています。

　「CANの暗号化は有効であるが、十分ではない。そのため、他の防御手段と組み合わせる必要がある。IPSやIDSを用いた侵入への対策やハードウェアによる安全な鍵管理などの多層防御、車両設計の段階からセキュリティを考慮するSbDが重要」（Weisglass氏）

自動車サイバーセキュリティとIoTがもたらすモノ

　身の回りのあらゆる機器がネットワークに接続するIoTの急速な隆盛に伴い、多くのセキュリティ課題も露見しています。従来は、サイバーセキュリティを考慮する必要性が薄かった業界も、対策に迫られつつあります。特に、自動車サイバーセキュリティは、人命にかかわる分野であり、多くの企業が対策に慎重になっています。

　現在、世界各国の政府や組織では、自動車サイバーセキュリティの標準化や規格化が進んでいます。今後、輸出入される自動車も、各国の規格へ準拠する必要が出てくるのは明らかです。総務省がIoT機器の脆弱性調査に乗りだすなど、サイバーセキュリティを官民一体で推進する機運が高まっています。

　多様なハードウェアやソフトウェアの開発競争が進むことで、その恩恵は、自動車業界のみならず、モバイル機器やデジタルサイネージなどのIoT機器にまで波及していくでしょう。自動車サイバーセキュリティの動向には、今後ますます注目が集まりそうです。