1 / 57

Deeper than Ever Before

Deeper than Ever Before. Exploring, Subverting, Breaking and Pivoting with NAND Flash Memory. A story of Research by: Josh ” m0nk ” Thomas / @m0nk_dot PacSec 2013. ./whoami. 設立パートナーおよびチーフ「破壊」オフィサー @ Atredis Partners ( www.atredis.com ) ハードウェアリバースエンジニアでセキュリティ 研究者

lajos
Download Presentation

Deeper than Ever Before

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Deeper than Ever Before • Exploring, Subverting, Breaking and Pivoting with NAND Flash Memory... A story of Research by: Josh”m0nk” Thomas / @m0nk_dot PacSec 2013

  2. ./whoami • 設立パートナーおよびチーフ「破壊」オフィサー@ Atredis Partners (www.atredis.com) • ハードウェアリバースエンジニアでセキュリティ研究者 • モバイル/スマートフォーン /組み込みシステム • メッシュネットワークファン • AI、暗号技術とルートキット元開発者 • カーネルドライバとハードウェアの境界を好む josh@atredis.com / @m0nk_dot on twitter

  3. whois atredis.com • 特定の分野に特化したセキュリティ企業 • 高度なハードウェアおよびソフトウェアアセスメントが専門 • モバイルと組み込みシステム • 社会的なインフラ • ブラックボックス • 高度なマルウェアおよびルートキットの分析 • 職人的な高度な技術とオーダーメードなリサーチ

  4. story arc • NANDフラッシュの紹介とその防御の考え方について • ハードウェアとソフトウェア視点からのNANDの動作方法 • プロジェクト NandX: 隠ぺいと破壊 • 攻撃面の選択 • プロジェクトとソースコードの紹介 • NANDフラッシュにおける防御の考え方とフォレンジック • 隠ぺいからその先へ • プロジェクトBurner: プラットフォームの完全なコントロール • Thank you / Q&A

  5. NANDとその防御

  6. NANDにおける防御の考え方 • このプレゼンテーションでは、NANDフラッシュハードウェアの機能上の側面を取り上げる • バグや欠陥ではなく、純粋にハードウェアの機能について • エレガントでコントロールされた故障メカニズムの再利用 • このハードウェアの攻撃面を保護できるのは、リエンジニアリングと高度なフォレンジックツールしかない • よりよいツールが必要

  7. NANDの動作

  8. 注意:科学は難しい

  9. NANDの動作: ハードウェアの概要 • バケツ- 技術用語ではないかもしれない • ページ- 通常は512バイト、2048バイト、もしくは 4096バイト • ブロック – 通常は16キロバイトから 512キロバイト • 初期値は1にセットされる (0xFF) • 0にシフトするのは簡単 • 1にシフトするのは難しい

  10. NANDの動作: 罠 • 電子の配置は容易 • 1個の電子をつかむのは非常に困難

  11. NANDの動作: データの作成 • NANDにデータを書き込むには、配置されている電子を取り除けばよい • 本質的には、0xFFからデータ部分を切り抜く • ファイルを保存する場合は、差分を切り抜くもしくは新しいバージョンを生成すべきかを調べる • このため、フォレンジックは困難に

  12. NANDの動作: エレガントでコントロールされた故障 • ゲートの作成は困難で、しかも壊れやすい • 通常10,000回から100,000回の書き込みで壊れ始める • 摩耗が進むため、摩耗を表面全体に分散させるウェアレべリングを実施する • ウェアレベリングが残すごみによってフォレンジックは困難になる

  13. NANDの動作: NANDフラッシュの種類 • ローNANDフラッシュ • コントローラはすべてソフトウェアによるコントローラ • ハードウェアは単純なストレージにすぎない • マネージドNANDフラッシュ • コントローラはハードウェアに組み込まれている • 組み込みチューリングコントローラ

  14. NANDの動作: マネージドNANDフラッシュ

  15. NANDの動作: ソフトウェアとAndroidカーネル • ローNAND = ドライバは複雑に • MMC/eMMC = ドライバはシンプルに • 通常はプロプライエタリ な(非公開の)ウェアレベリングアルゴリズムはハードウェアに組み込まれている • ドライバと無関係に、ハードウェアはシステムとやり取りし、故障メカニズムを明らかにしなければならない

  16. NANDの動作: MTDメタドライバ • MSM / MTD(Memory Technology Devices) サブシステム • メタドライバのようなもの • Androidのブートパーティションで多用される • 製品によってはすべてのNAND管理に使用

  17. NANDの動作: システムの構築

  18. NANDの動作: コントロールされた失敗のおさらい • ハードウェアが故障すると、NANDはフラグを立てるだけのレイジーイレースをおこなう • コントローラには読み書き不良の閾値がある • 障害に対応する実装には、誤り訂正符号と 前方誤り訂正による実装がある

  19. NANDの動作: 避けられない失敗 • 不良ブロックが検出されると、そのNANDブロックは アウトオブバンドエリア(OOB)と不良ブロックテーブル (BBT)に記録される • そのブロックはアドレス指定システムから消える • 消えてしまったブロックを読めるツールは存在しない • 不良ブロックをもとに戻すツールも存在しない

  20. NANDの動作: When things go wrong • システムによっては、BBTを完全にカーネルメモリで管理している (リブート中に「マスタ」としてディスクに書き込まれる) • デュアルページのOOBマーカーをBBTとECCに使うシステムもある (Sony!) • 最初もしくは最後のブロックを全体のBBTとECCに使うシステムもある (アドレス-10と考えてよい)

  21. NANDの動作: 攻撃面の露出 • YAFFSなどのファイルシステム • ドライバレベルのMTD • Android / Linuxカーネル • フラッシュトランジションレイヤー • ハードウェアの組み込みコントローラをリバースエンジニアリング • ユーザランドにおける不適切なコーディング

  22. プロジェクト NandX:隠ぺい

  23. プロジェクト NandX • 目標: • 問題が発生していない任意のブロックを不良としてマーク(アドレスシステムからそのブロックは削除される) • その不良ブロックに任意のデータを読み書き • Androidカーネルとdd(1)を含む他のツールが読み書きできないことを確認 • 予測: • 膨大なハードウェアのリバースエンジニアリングと組み込みコントローラファームウェアのアセスメント

  24. プロジェクトNandX:第1ステージの現実 • 30以上の機種を購入、テスト、返品 • ローNANDを探す • オープンソースカーネル

  25. プロジェクトNandX:すべての携帯を調査

  26. プロジェクトNandX:Sony Xperia Arc S!

  27. プロジェクトNandX:MTDサブシステム

  28. プロジェクトNandX:APIを変更 • 実施するのはAPIを正しくない順序で叩くだけ • 例外はBBTのOOB書き込みだけ • ステップ: • ブロックを１つ選択し、内容を消去 • ブロック全体に0xDEADBEEFを書き込む • そのブロックを不良としてマーク ( ソニーの場合、OOBに0x00) • 任意のデータを読み書き • カーネルがクラッシュしリブート

  29. プロジェクトNandX:デモ http://youtu.be/AE_oUkKKaBY

  30. プロジェクトNandX:A disappearing act • ブロック37が消える • 0xDEADBEEFが書きこまれる • もともとその場所にはAndroidのSettings.app (com.android.settings)があった • ハードウェアでダブルフリーが発生し、リブートする

  31. 証明にはソースコードが欠かせない

  32. プロジェクトNandX:主要部分のコード

  33. プロジェクトNandX:不良ブロックをマークする第1ステージプロジェクトNandX:不良ブロックをマークする第1ステージ

  34. プロジェクトNandX:不良ブロックをマークする第2ステージプロジェクトNandX:不良ブロックをマークする第2ステージ

  35. プロジェクトNandX:ログの概要

  36. プロジェクトNandX:詳細なログ

  37. プロジェクトNandX:最後に • ブロックが不良としてマークされると、現時点でそのブロックを回収できるツールは存在しない • 工場出荷時の設定に戻しても回収できない • 別のROMをフラッシュしても回収できない • dd(1)でもそのブロックはコピーできない • 0xDEADBEEFは完全に永続的な状態で隠ぺい

  38. プロジェクトNandX: ツールを武器に

  39. プロジェクトNandX:隠ぺいにとどまらない可能性プロジェクトNandX:隠ぺいにとどまらない可能性 • 思考その1: • 目的のデータを削除し、IT部門がデータを消去して廃棄するのを待って、物理的にデータを外部に持ち出す • 思考その 2: • 不良ブロックとしてマークするというのはシステムから完全に削除されるということ...

  40. プロジェクトNandX:究極の武器 • リモートからカーネルモジュールをロードし、物理的なNANDフラッシュのブロックがなくなるまで1ブロックづつ削除 • 修復は不可能でリプレースが必須 • 携帯電話に限らず、ほぼすべての組み込み機器でNANDが使用されている • SCADA

  41. プロジェクトNandX:この発表の続きについて • 機会があれば、リサーチ内容をオープンソースに • ベンダの企業秘密や知的財産が含まれるため、常に可能というわけではない • このプロジェクトは100％オープンソースのツールで成り立っているため、このリサーチはリリースが可能だった • すべては次のURLに (かなり長いホワイトペーパーも含む): • https://github.com/monk-dot/NandX

  42. プロジェクトBurner:隠ぺいの向こうへ

  43. プロジェクトBurner:概要 • 仮説: • Androidフォーンのカーネルを完全に管理下におくと、電源と電圧を内蔵バッテリからコントロールし、物理的に内蔵ハードウェアを操作できる。そのプロセスをコントロールし、それぞれのコンポーネントをターゲットを想定外の電圧によって運動学的破壊に至らしめることも可能になる • 結果: • 仮説は正しい

  44. プロジェクトBurner:Androidの電源ハードウェア • バッテリーは生の電力を供給する • USBスタックもシステムに電源を供給する • パワーマネージメントIC(PMIC)が配線上の電圧を配分する • カーネルがPMICを直接管理する • 配線は必ずしもコンデンサや抵抗で保護されているわけでない

  45. プロジェクトBurner:Androidにおける電圧制御 • ドキュメントの場所: • <kernel_source>/Documentation/power/regulator/overview.txt • ドライバをのぞくと、10個以下のCソースおよびヘッダで基板上の電圧フローを管理している • 基盤の種類と無関係に注目すべきは*_regulator.cファイル

  46. プロジェクトBurner:ターゲット • プロジェクトBurnerがターゲットにしたプラットフォームはSony Xperia Z (yuga) • Qualcommの Snapdragonリファレンスプラットフォームがベースに • NANDコントローラはSDカードコントローラにつながっている • Qualcomm MSM 7X00A SDCCはNANDおよびSDカードの配線をコントロールしている

  47. project kernel/sony/apq8064/ • diff −−git a/arch/arm/mach−msm/board−sony_yuga−regulator.cb/arch/arm/mach−msm/board−sony_yuga−regulator.c • −− RPM_LDO(L5, 0, 1, 0, 2950000, 2950000, NULL, 0, 0),++ RPM_LDO(L5, 0, 1, 0, 5900000, 5900000, NULL, 0, 0), • −− RPM_LDO(L6, 0, 1, 0, 2950000, 2950000, NULL, 0, 0), • ++ RPM_LDO(L6, 0, 1, 0, 5900000, 5900000, NULL, 0, 0), プロジェクトBurner:NANDの電圧を上昇させる

  48. プロジェクトBurner: NANDの電圧を上昇させる • 高電圧によって: • NANDの読み込みは転送過程で破壊 • NANDの書き込みはNANDハードウェアを破壊 • PMICの値は保持されたままなので、デバイスをリブートするとブートローダがカーネルを読み込む際にNANDすべてを破壊

  49. project kernel/sony/apq8064/ • diff −−git a/arch/arm/mach−msm/board−sony_yuga−regulator.cb/arch/arm/mach−msm/board−sony_yuga−regulator.c • −− RPM_LDO(L5, 0, 1, 0, 2950000, 2950000, NULL, 0, 0),++ RPM_LDO(L5, 0, 1, 0, 1250000, 1250000, NULL, 0, 0), • −− RPM_LDO(L6, 0, 1, 0, 2950000, 2950000, NULL, 0, 0), • ++ RPM_LDO(L6, 0, 1, 0, 1250000, 1250000, NULL, 0, 0), プロジェクトBurner:NANDの電圧を下げる

More Related