Ffri Security, Inc. · TSE:3692

Ffri Security — FFRI — Technical Presentation (December 2014)

48 slides from Ffri Security's technical presentation, Dec 18, 2014

  1. Slide 1: CODEBLUE 2014 - Takahiro Matsuki (FFRI), Dennis Kengo Oka (ETAS)

    CODEBLUE 2014.12.18-19 Takahiro Matsuki (FFRI) Dennis Kengo Oka (ETAS)

  2. Slide 2: Agenda

     はじめに  ECUソフトウェアについて  TriCore の概要  攻撃手法の検討と試行  デモ  まとめと今後の方針 2

  3. Slide 3: はじめに

     自動車セキュリティの先行研究で、車載 ECU は CAN バスへのメッセー ジのインジェクションによって攻撃者のターゲットになることが示されてい る。ECU ソフトウェアは攻撃対象になるだろうか?  ECU マイコンのアーキテクチャは従来の PC アーキテクチャとは異なるた め、従来のソフトウェア脆弱性攻撃は有効ではない?  ECU マイコンにはソフトウェアへの脆弱性攻撃を防ぐ特定のセキュリティ 対策があるのだろうか?  ECU ソフトウェアが脆弱な場合、従来の脆弱性攻撃を ECU マイコンアー キテクチャに適合させることによって、攻撃を実行することは可能? 3

  4. Slide 4: 調査内容の概要

     ECUのハードウェアおよびソフトウェア構成 ◦ ECUの機能とマイコン、バス、I/Oインタフェース ◦ どんなマイコンが使われているのか  ECUのマイコンアーキテクチャ ◦ プログラム実行方式 ◦ 命令実行フロー、レジスタ、メモリレイアウト  ECUソフトウェア実行環境および開発環境 ◦ ライブラリ、コンパイラ ◦ 開発ツールによって生成されるコードの内容 ◦ プログラムファイルのリバースエンジニアリング手法 4

  5. Slide 5: ECUソフトウェアについて

    ECUVPRUZVIZDLYT >a

  6. Slide 6: 車載ECUの数とソフトウェア規模

     基本的に現在の車は、快適機能だけでなく、安全性を提供するためにも 電子制御ユニットを多数有している  平均 70 個の ECU を搭載している  ECU ソフトウェアのソースコードは2000万行以上  2015年までに自動車の生産コストの50%程度が電子部品になる  50%がインフォテインメント、30%がパワートレイン及びトランスミッション、 10%がシャーシ制御、10%のボディと快適機能 6

  7. Slide 7: ECUの種類と機能

     エンジン制御ユニット ◦ 燃料の量と混合、空気および燃料の送出タイミング、バルブタイミング、 点火タイミング、エミッション制御···  トランスミッション制御ユニット ◦ 変速、シフトロック、シフトソレノイド、圧力制御ソレノイド···  ボディ制御ユニット ◦ 集中ロック、イモビライザーシステム、パワーウィンドウ、空調制御···  ABS/ESP 制御ユニット ◦ ブレーキ圧調整、トラクションコントロール、コーナリングブレーキ制御 ··· 7

  8. Slide 8: 典型的なフィードバック制御システム

     典型的なフィードバック制御システム  1. 入力の監視、例えば、タイマー、センサー、CAN  2. 計算あるいは適切な対応の探索  3. 対応する出力の生成 8

  9. Slide 9: ECUソフトウェアの種類

     完全にカスタムなプロプライエタリなソフトウェア  Unixベースの独自のソフトウェア  標準化されたソフトウェア、例えば、AUTOSAR 9

  10. Slide 10: TriCoreの概要

    TriCoreの概要 10

  11. Slide 11: 自動車ECU用マイコン TriCore

     自動車ECU用マイコン  製造販売 Infineon ◦ 独シーメンスの半導体部門のスピンアウト  TriCore を搭載しているECUの例 ◦ Bosch EDC17 & MED17, Siemens  TriCore 搭載 ECU の採用車種がある自動車メーカ ◦ Audi, BMW, Citroen, Ford, Honda, Hyundai, Mercedes-Benz, Nissan, Opel, Peugeot, Porsche, Renault, Seat, Toyota, Volkswagen, Volvo 11

  12. Slide 12: TriCore命令セットとレジスタ構成

     命令セット ◦ 32ビット RISC アーキテクチャ  独特なレジスタ構成 ◦ アドレス用レジスタとデータ用レジスタが完全に分離 ◦ A0~A16, D0~D16  今回調査したマイコンの型番とスペック ◦ TC1797 (AUDO Future)  TriCore アーキテクチャ 1.3.1  クロック 180 MHz 12

  13. Slide 13: Web上の公開情報・仕様書を探す

     Web 上の公開情報・仕様書を探す ◦ 公式 User’s Manual  最も信頼性の高い情報源  メモリ関連の図表に注目  セキュリティに関係するキーワードを検索  security, protection, password ◦ TriCore Architecture Overview  User’s Manual の要約資料 13

  14. Slide 14: 開発者向け情報・ツールを探す

     論文を探す ◦ TriCoreエミュレータ  QEMUにTriCoreをポーティング ◦ Linux Kernel を TriCoreにポーティング  ECU ソフトウェア開発者向け情報・ツールを探す ◦ 開発環境 TASKING VX-toolset for TriCore 評価版  コンパイラ、シミュレータ付き IDE ◦ 評価ボード Infineon Starter Kit TC1797 ◦ FlexECU development platform  バイナリをリバースエンジニアリングする ◦ IDA Pro で逆アセンブル可能  ファイルフォーマットは ELF for S

  15. Slide 15: 攻撃手法の検討

    WRERCRHLE AT >a

  16. Slide 16: 脆弱性の種類

     非メモリ破壊脆弱性  メモリ破壊脆弱性 ◦ アクセス制御の問題 ◦ バッファオーバーフロー ◦ 暗号強度の問題 ◦ 整数オーバーフロー ◦ 不適切な認証 ◦ Use After Free ◦ 競合状態 ◦ Null Pointer Dereference ◦ 証明書・パスワード管理の問題 ◦ フォーマットストリングバグ ◦ etc. ◦ etc. 実際のECUソフトウェアの入手および解析が困難であったため、 メモリ破壊脆弱性が存在すると仮定し、理論的な攻撃手法を検討 16

  17. Slide 17: 脆弱性ごとの攻撃可能性

     バッファオーバーフロー ◦ スタックオーバーフロー ◦ ヒープオーバーフロー  整数オーバーフロー ◦ ヒープオーバーフローの原因となると推測  フォーマットストリングバグ ◦ 任意のアドレスに任意の値を書き込み可、攻撃可能と推測  Use After Free ◦ TriCoreでC++コードも実行可能なため攻撃可能と推測  Null Pointer Dereference ◦ 0番地へのアクセスでトラップが発生するため攻撃不可と推測 17

  18. Slide 18: スタックオーバーフローの検討

     スタックオーバーフロー ◦ TriCore は x86 等と異なり、リターンアドレスがスタックではなく、 アドレスレジスタ(A11)に保存されるためスタックオーバーフローに よるリターンアドレスの上書きは不可  ヒープオーバーフロー ◦ TriCoreのヒープ管理については今後調査予定 18

  19. Slide 19: スタックオーバーフローによる攻撃可能性

     スタックオーバーフローによる攻撃可能性を検討 ◦ 以下のようなコードフローでスタック上にバッファと関数ポイン タが存在する場合、スタックオーバーフローによってプログラ ムの実行フローを変更できる receive() main() check(f_ptr) success() compare() f_ptr = &compare() failure() 19

  20. Slide 20: コードの例

     コードの例 failure() { ... check( f_ptr ) { } // call receive() to receive incoming value receive(); success() { .... // call compare() using function pointer } f_ptr(); } compare() { ... main () { } function_ptr = &compare; … check( function_ptr ); receive() { } // receive input value input = … char b

  21. Slide 21: メモリレイアウト

     メモリレイアウト Address Variable 0x8000 010C check() 0x8000 013C receive() 0x8000 0170 compare() 0x8000 017C success() 0x8000 0188 failure() … … 0xD000 8FC8 buffer[] 0xD000 8FE0 function_ptr 21

  22. Slide 22: 攻撃の実行フロー

    receive() main() check(f_ptr) success() compare() Failure() check() が、compare() の代わりに success() を指す f_ptr() を呼び出す 22

  23. Slide 23: 問題点

     問題点 ◦ コンパイラの最適化が有効な場合、関数ポインタがアドレス レジスタに格納される ◦ 実際のECUソフトウェアで同様パターンのコードが存在する か不明 23

  24. Slide 24: TriCoreの制御機構を利用した攻撃手法の検討

    TriCore の制御機構を利用した 攻撃手法の検討 24

  25. Slide 25: TriCoreの制御機構

     検討の前提 ◦ メモリ破壊脆弱性で任意のアドレスのデータを書換え可能 ◦ その場合に任意のコードを実行する手法を検討  TriCore の制御機構 ◦ コンテキスト管理機構 ◦ 割り込み・トラップ機構 25

  26. Slide 26: コンテキスト管理機構を用いた攻撃手法

    コンテキスト管理機構を用いた 攻撃手法 26

  27. Slide 27: コンテキストとは

     コンテキストとは ◦ レジスタの値を CSA (Context Save Area) という TriCore 独自のメモリ領域に保存・復元する仕組み  コンテキストの種類 ◦ Upper context と Lower context の2種類 ◦ Upper context  call 命令、割り込み、トラップ時に自動的に保存される ◦ Lower context  専用命令で明示的に保存、パラメータ渡しに利用 27

  28. Slide 28: 出典: Tricore Architecture Overview

    出典: Tricore Architeture Overview http://www.infineon-ecosystem.org/download/schedule.php?act=detail&item=44 28

  29. Slide 29: 出典: Tricore Architecture Overview

    出典: Tricore Architeture Overview http://www.infineon-ecosystem.org/download/schedule.php?act=detail&item=44 29

  30. Slide 30: CSAはリンクリストで管理される

     CSA はリンクリストで管理される ◦ 使用済み CSA リスト (PCX) 、未使用 CSA リスト (FCX) ◦ 各リストの先頭要素へのポインタが PCX, FCX レジスタに格納  ただし、生のアドレスではないため変換が必要 出典: Tricore Architeture Overview http://www.infineon-ecosystem.org/download/schedule.php?act=detail&item=44 30

  31. Slide 31: CSA Overwriting と CSA Injection

     手法1:CSA Overwriting ◦ 何らかのメモリ破壊脆弱性で CSA に保存された Upper context 内のリターンアドレスを上書きす れば任意アドレスのコード実行が可能  手法2:CSA Injection ◦ 何らかのメモリ破壊脆弱性で CSA の Link word を上書きすれば、リターンアドレスを含む細工され た Upper context を復元させ、任意コードの実 行が可能 31

  32. Slide 32: CSA上書きのコード実行結果

     右記コードの実行結果 func1 func2 func3  func2 内で CSA に保存されたリターンアドレ ス(*ret)を func3 のアドレス(0x80000360) に書換え  func1 に return すると A11 レジスタの値が func3 (0x80000360) に復元される  func1 の return で func3にジャンプ 32

  33. Slide 33: 評価ボードでのCSA上書き

     評価ボードでもシミュレータと同様に CSA 上書きが可 能であった ◦ デフォルトでは CSA の書き換えを防止するメモリ保護はない ◦ 実際のECUソフトウェアでの脆弱性攻撃にも適用できる可能 性がある 33

  34. Slide 34: 割り込み・トラップ機構を用いた攻撃手法

    Al AA ED T BS) Fiz Ty = >a JUTE

  35. Slide 35: 割り込みベクタテーブル(IVT)

     割り込みが発生すると割り込みベクタ テーブル(IVT)が参照され、 割り込み優先番号(PIPN)に対応する 割り込みサービスルーチン(ISR)が実行 される  IVTの開始アドレス ◦ BIVレジスタ(Begin Interrupt Vector)  各ISRのエントリポイントのアドレス ◦ BIV | (ICR.PIPN << 5)  ICR (Interrupt Control PIPN 0~255 ISRはユーザー定義 Register) 出典: Tricore Architeture Overview http://www.infineon-ecosystem.org/dow

  36. Slide 36: トラップベクタテーブル(TVT)

     例外が発生した時それを捕捉し、特 定の処理を行わせる機能 ◦ トラップ発生要因  命令による例外、不正なメモリア クセス等  トラップが発生するとトラップベクタ テーブル(TVT)が参照され、トラップ クラス番号(TCN)に対応するトラップ サービスルーチン(TSR)が実行され る 出典: Tricore Architeture Overview http://www.infineon-ecosystem.org/download/schedule.php?act=detail&item=44 36

  37. Slide 37: IVT・TVT書き換えによる攻撃手法

     手法1: IVT の書き換え ◦ IVT にある ISR へのジャンプコードを書き換えることにより、 特定の割り込みが発生した時に、任意のコードを実行  手法2: TVT 書き換え ◦ TVT にある TSR コードを書き換えることにより、 特定のトラップが発生した時に、任意のコードを実行 37

  38. Slide 38: IVT書き換えの検証

     BIVの値 0xa00f0000  __interrupt(3) hoge_isr() というISR を定義すると、 0xa00f0060 (0xa00f00+ 32*3) に hoge_isr() へのジャンプコードが配置 されるため、これを書き換え  シミュレータでは書き換え可能 ◦ しかし、割り込みを意図的に発生させられる どうか不明のため、未検証 ◦ 0xA セグメントは、実機では Flash メモリ にマップされ書き換え不可の可能性あり  TVTも同様に書き換え可能 38

  39. Slide 39: 評価ボードでのBIV・BTV

     評価ボードでは BIV と BTV の値がシミュレータと異なる ◦ BIT @ 0xF7E1FE20, BTV @ 0xF7E1FE24  プロテクトがかかっている  デバッガから書き換え可能  プロテクトを無効にしてコードから書き換えを試行したがト ラップ2が発生  実際のECUソフトウェアでの脆弱性攻撃にも適用できないと 考えられる 39

  40. Slide 40: デモ環境

    Fi7R—K & FAL TAREE

  41. Slide 41: デモ環境の構成

     HP EliteBook 2530p, Win7, Centrino2 ◦ HIGHTEC Free TriCore Entry Tool Chain ◦ BUSMASTER  Infineon TriBoard TC1797 V5.0  ETAS ES592.1 41

  42. Slide 42: デモ構成図

    CAN USB ES592.1 TriBoard Notebook Ethernet 42

  43. Slide 43: 43

    43

  44. Slide 44: デモ

    デモ 44

  45. Slide 45: まとめと今後の方針

    まとめと今後の方針 45

  46. Slide 46: まとめ

     ECU ソフトウェアにメモリ破壊脆弱性が存在する場合の攻撃手法を検討  メモリ破壊脆弱性が存在する場合、任意コードを実行できる可能性はある ◦ バッファオーバーフローが存在する場合、特定の条件で任意のコードを実行可能 ◦ CSAを改変することで任意のコードを実行可能 ◦ 割り込み・トラップベクタテーブルを改変することでの任意コード実行は不可能  脆弱なECUソフトウェアを作成し、攻撃のデモを実施  今回の調査は、理論的な攻撃手法の検討結果と脆弱なソフトウェアのサ ンプルを用いたデモのため、実際のECUソフトウェアの存在する脅威を指 摘するものではない 46

  47. Slide 47: 今後の方針

     追加調査 ◦ 今回調査したもの以外の脆弱性やアーキテクチャ固有の問題の調査  脅威の実証 ◦ ECUソフトウェアのリバースエンジニアリングを行い、メモリ破壊脆弱性が存在 するかどうか調査 ◦ 実際の脆弱性を攻撃して、ECUの停止あるいは異常動作を引き起こすことが 可能かどうか検証  対策検討 ◦ ECUソフトウェアの脆弱性対策手法の検討 ◦ プログラミングエラーに起因する脆弱性を効率的に発見する方法の検討 47

  48. Slide 48: Thank you

    Thank you 48

FFRI — Technical Presentation (December 2014) on 6ix