Windows 11でメモリダンプからBitLockerを回避する
(noinitrd.github.io)- Windows 11 24H2環境で Memory-Dump-UEFI を使ってRAMをダンプし、フルボリューム暗号化キーである FVEK を見つけ出してBitLocker保護ボリュームへアクセスするデモ
- 攻撃者がデバイスに物理的にアクセスできる場合、再起動直後のRAMに残ったキーを狙えるが、電源断の時間が長くなるほど RAM内容の破損 リスクが高まる
- デモではマザーボードの リセットピン（reset pins） をショートさせ、電源喪失なしに再起動する方式を使用し、Secure Bootの回避事例はデモの範囲外とした
- Windows 11のダンプでは、過去のWindows 7の
FVEc、Windows 8.1/10のCngbではなく、dFVEとNoneタグの下でFVEKが見つかった - Microsoftが
SymCryptSessionDestroyのような関数でキーを破棄しようとしてもヒープにキーが残る可能性があり、BitLocker実装の分析には カーネルレベルのデバッグ が最も直接的なアプローチとなる
Windows 11 BitLocker回避デモの範囲
- 対象は Windows 11 version 24H2 で、BitLockerのフルボリューム暗号化キーである FVEK をメモリから抽出する方式
- RAM内容をダンプするUEFIアプリケーション Memory-Dump-UEFI が使用される
- 核心となる前提は、攻撃者がデバイスに 物理的にアクセス できること
RAMダンプが成立する条件
- 直近で実行されていたWindowsインスタンスのRAMには、FVEKのような機密情報が残っている場合がある
- 電源が切れるとRAM内容は急速に破損するため、再起動過程でコンピュータが完全にオフになっている時間を最小化する必要がある
- RAM破損を減らす方法として、物理的な冷却や外部電源供給の維持があり、デモではマザーボードの リセットピン をショートさせて電源喪失なしに再起動した
- Secure Boot はデバイス起動時に実行可能な項目を制限するセキュリティ標準だが、shimなどで回避された事例があり、このデモでは詳しく扱わない
起動USBの準備とダンプ作成
- 起動USBには対象システムのRAM容量より大きいストレージデバイスが必要
flashimage.shスクリプトにより、起動可能アプリケーションの準備を簡素化している- 起動アプリケーションの作成と使用手順は MemoryDumpUEFI にまとめられている
- Windowsがロード中だがログイン画面が表示される前に再起動した場合、FVEKを見つけられる可能性が最も高かった
- USBデバイスから Memory-Dump-UEFI で直ちに起動した後、UEFI shellで
app.efiを実行する- 実行方法はアプリケーションの README に追加手順がある
- ダンプ時間はRAM容量とUSBデバイスの速度によって変わる
- 誤ったドライブに書き込まれるのを避けるには、他のUSBストレージは取り外しておくのがよい
ダンプファイルの処理と検索ツール
- Memory-Dump-UEFIは複数のダンプファイルを作成できる
- UEFI仕様に合わせるにはFAT32ファイルシステムを使う必要があり、FAT32には 4GBのファイルサイズ制限 がある
toolsディレクトリのconcatDumpsは複数のダンプを時系列順に1つへ結合する- ダンプは当時メモリにあった生データなので、
xxdのようなツールで読みやすく確認できる searchMemはダンプ内でhexパターンを検索し、発見位置のオフセットへ移動できるようにする
プールタグとFVEKの位置
- プールタグ（pool tag） は、Windowsカーネルメモリプールがどこかを示す4文字の識別子
- Windowsカーネルが割り当てたメモリプールは、機密情報を探すのに適した場所になり得る
pooltag.txtにはプールタグ一覧と各用途に関する情報が含まれている- 過去のWindowsバージョンではBitLockerキーの位置が異なっていた
- Windows 7では、
fvevol.sysの暗号化割り当てに該当するFVEcプールタグからキーを復元できた - Windows 8.1とWindows 10では、
ksecdd.sysモジュールに該当するCngbタグのメモリプールからキーを見つけることができた
- Windows 7では、
- Windows 11のダンプでは
FVEcとCngbからキーは見つからず、代わりに2か所でFVEKが見つかった- 1つ目は、
dumpfve.sysが割り当てたメモリを示すdFVEプールタグの下 dumpfve.sysはBitLocker drive encryptionのfull volume encryption crash dump filterに関連するdFVEの位置は、キーが最も容易かつ一貫して見つかった地点だった- この位置のキーの前には暗号化方式を示す
0x0480が付いており、デモ環境では XTS-AES-128 を意味する - 2つ目は、
ExAllocatePool呼び出しに関連するNoneタグの下 - この位置では、キーの前半が2回、後半が1回見えていた
- 1つ目は、
FVEKでBitLockerボリュームへアクセスする
- 取得したキーには、使用中の暗号化アルゴリズム値を前に付ける必要がある
- 例ではキーの前にアルゴリズム値
0x8004をlittle endian形式の0480として付ける - こうして作成した値をファイルに保存し、
output.fvekという形で使用できる - dislocker ツール群は、必要なアルゴリズムと値を確認し、BitLocker保護パーティションをアンロックするために推奨される
- 手順が正しければ、
output.fvekでBitLocker保護ボリュームのデータにアクセスできる
BitLocker実装分析とヒープに残ったキー
- BitLocker実装を理解する最も直接的な方法は、
windbgを使ったカーネルレベルのデバッグ - カーネルデバッグは仮想マシンやクロス接続したUSB 3.0 A/Aケーブルで比較的容易に行える
- Windowsの起動過程を段階的に追い、BitLockerの動作を観察したことがキー発見の助けになった
- Microsoftは
SymCryptSessionDestroyのような関数でキーを破棄しようとするが、ヒープにキーが残り、すべてのキーを除去できるわけではない
参考リンク
- recovering-bitlocker-keys-on-windows-8-1-and-10: Windows 8.1とWindows 10のBitLockerキー復元に関する資料
- dislocker: BitLockerボリュームへのアクセスに使用されたツール群
- SymCrypt: Microsoftの暗号化ライブラリ
- libbde: BitLocker Drive Encryption関連ライブラリ
- pooltag.txt: Windowsプールタグ一覧
- An Introduction to Pool Tags: Microsoftによるプールタグの紹介資料
1件のコメント
Hacker News の意見
BitLocker は TPM（PCR 7+11）+ PIN を使うときに最大の利点があると思う
PIN なしでは FVEK を読めないはずなので、この攻撃を緩和できるし、BitLocker が正しく実装されていれば、PIN を間違えすぎたときに TPM が辞書攻撃ロックアウトモードに入る
ここ数か月、Linux でも同じ構成を試そうとしていたが、systemd-cryptsetup/cryptenroll は LUKS 用で、自分の状況は遅い内蔵 eMMC 上で fscrypt を使い、機密ディレクトリをいくつか（secure boot キーと /home）暗号化したいというもの
基本を超えると TPM のコーディングは極めて難しいと感じる。PCR 7 に結び付け、カーネル/init/cmdline の更新ごとに変わる PCR 11 に結び付け、AuthValue ではなく PIN を使い、ログイン時の DA ロックアウトカウンタの初期化にも同じ承認ポリシーを使いつつ、手動初期化用の長いパスワード/AuthValue も用意し、systemd-stub が提供する PCR 11 署名と公開鍵まで合わせる必要がある
基本的な TPM ガイド以外には資料がほとんどないので、専門家がいるなら助けてほしい。個人プロジェクトだが、いつか完成したら記事にまとめるつもり
復旧メカニズムとしてその方法を検討する価値はある
趣味でオープンソースの TPM 周りを触る人が少ない理由の一つは、似たような欲求をはるかに簡単に解決する代替手段が多いからだ
重要な暗号鍵をハードウェアに結び付けたいなら Yubikey を買えばよいし、ノート PC のディスク暗号化パスワードが面倒なら、完全にシャットダウンする代わりに蓋を閉じたときにスリープにすればよい
ログインパスワードが不便なら指紋リーダーや生体認証 Yubikey があるし、無人キオスクや学校のコンピュータ室のようにパスワードなしで起動する必要があるなら、頑丈な金属箱に入れて壁にチェーンで固定すればよい
データセンターのサーバーを無人起動させる必要があるなら、信頼できる物理セキュリティのあるデータセンターに移し、それでも心配なら Dropbear や Tang を使って、正しいネットワーク上にある場合にだけ起動するようにすればよい
ホームラボ趣味で TPM を触っているなら、本当にTPM 作業が楽しいのかを点検してみるとよいし、おそらくそうではないと分かる可能性が高い
そうでなければ、ディスクブロックを復号するたびに PIN を入力しなければならないのでは？ ディスク操作のたびに TPM を呼び出す性能への影響も大きい
この攻撃は RAM からキーを読むので、TPM PIN がどう緩和策になるのか分からない
起動前にパスワードを入力し、そのパスワードを TPM キーと組み合わせなければドライブを開けないなら、後で TPM キーが見つかるような状況では役に立つ
ただし、この攻撃に対してどの対策がどれほど役立つかは判断が難しい。OS がドライブの読み書きアクセスを維持するには、どこかにキーを保持していなければならないので、キーを探す場所を変えるだけで、ほとんどのシナリオではこの種の RAM データ回収が可能になるはずだ
Apple デバイスではキーがセキュアエンクレーブの外に出ないと記憶しているので、こうした攻撃には脆弱ではなさそうだ。TPM 3.0 はそちらにはるかに近づく必要があるように見える
ThinkPad では電源投入時パスワードの代わりに指紋を使えるし、盗人にとってデバイスをほとんど使い物にならない物にできるので、BitLocker PIN よりもこの構成を好んでいる
もちろん電源投入時パスワードと指紋認証も TPM と同程度の強さでしかないが、BitLocker TPM+PIN も同じではないか
成功したオープンソース暗号化ソフトウェアの後に TPM へ移っていった流れが奇妙に感じられる。大企業が提供する超安全なストレージがあるから、心配も質問もしなくていい、というふうに見える
情報機関がすべての PIN とパスワードをダウンロードしてデータにアクセスできるバックドアが必ずあるのではないかという疑念がある
BitLocker のセキュリティモデルを根本的によく理解できていない
たいていのインストールでは、電源ボタンを押すと Windows が起動するように見える
それなら、暗号化されたハードドライブを搭載した端末を誰かが盗んだ場合、ただ電源を入れればいいだけなのか？ そんなはずはないだろうが、同時に、この特定の攻撃をどう防ぐのかも分からない
SPI バスのトラフィックは暗号化されていて、このようにキーをダンプできないと考えるべきなのだろうが、いずれにせよマシンがかなり簡単にキーを渡しているように見える
LUKS には少なくとも、ドライブのロック解除用のパスワードプロンプトがある
奇妙なことに Microsoft は TPM パラメータ暗号化を使っておらず、そのため1〜2年ごとにセキュリティ研究者が TPM スニッフィング装置を作ってデモしている
LUKS も設定次第。Linux もここでは Windows と同じ方式で構成できるし、私の自宅のビデオ監視サーバーも静かに再起動する必要があるので、そう設定してある。ウォーム／コールドブート攻撃やソフトウェア攻撃面には弱いことは分かっているが、誰かがドライブだけを抜き取っていった場合は安全だ
Windows もパスワードを要求したり、PIN 認証付きの TPM シールキーを使ったりするように設定できる
パラメータ暗号化とバススニッフィングの問題を除けば、BitLocker は境界を「誰でもドライブを読める」から「メモリ内容を得るためにプラットフォームレベルの攻撃を行うか、ログイン画面で動いているサービスをハックしなければならない」へ移してくれる
適当に再利用されたハードドライブから金融データを盗むような状況は非常によく防いでくれるので、実際にはかなり良いセキュリティ向上だ
リモートコード実行の脆弱性や、古い脆弱な Windows ブートローダーで起動するような回避が必要になる。ドライブがロックされているので、よくある「ソフトウェアキーボードを cmd.exe に置き換える」回避は使えない
BitLocker がなければ、Windows ドライブを別の PC に挿して全ファイルを見られる。BitLocker があれば、脆弱な Microsoft ソフトウェア、脆弱性、ダンプされたメモリなどと格闘しなければならず、それも常に成功するわけではない
BitLocker を TPM+PIN モードに設定すれば、TPM を開くためのパスワードがないので、それすらできない。BitLocker をパスワード専用モードにすることもできるが、総当たり攻撃にははるかに弱い
LUKS も同様で、最近のほとんどの Linux ディストリビューションは TPM と TPM+PIN をサポートしている
セーフモードで再起動したり、別の OS、ファームウェア更新ユーティリティなどで再起動しようとすると、BitLocker 回復キーの入力を求められる
指紋センサーや顔認識 Web カメラを「ハック」する場合に内部でどう動くのかは、よく分からない
TPM にキー抽出の脆弱性がない、という前提が必要になる
重要なのは電源が切れているときだ
汎用ドライブ暗号化では TPM は遅すぎるため、実際の大量データの復号は行わず、結局 OS が抽出可能なキーを持つことになる
Pro エディションでは、グループポリシーで起動時に対話ステップを要求することもできる。TPM がなくても動作し、その場合は起動のたびにパスワードを尋ねられる
これは https://trustedcomputinggroup.org/resource/pc-client-work-gr... で完全に防げる
有効化されている場合、OS が正常終了せず暗号化キーを消去する機会がなかったときは、次回起動前にファームウェアが停止して RAM を消去する
Windows がこれを使っていないのか、それともテストされたシステムが実装していなかったのか気になる
「BitLocker はキーをメモリに抽出する前に、MOR bit（Memory Overwrite Request）とも呼ばれる TCG Reset Attack Mitigation を使用する」とされている
ただし、ほとんどのプラットフォーム実装はまったく信用していない。何らかの形でまともな実装に近い UEFI プラットフォームを見たことがない
この研究者がどのプラットフォームを使ったのか、そしてそのプラットフォームが MOR bit 対応を主張しているのかが分かると興味深い
Team Tweezers が初代 Wii をどう攻略したかを見るだけでよい
本物の緩和策は、現代 CPU のメモリ暗号化機能だ。ダイ上にあるのでピンセットは届かず、キーだけ消せばよいので即座に削除され、電源サイクルを耐えたとしても妨害するのは非常に難しい
理想的には、キーは CPU の SRAM キャッシュ内にだけ残り、CPU ダイの外へは決して出ないべきだ
記事を書いた本人です。質問があればこのアカウントにメッセージを送ってもらって構いません
作業は本当に楽しかったですし、多くの関心に感謝しています
Windows 11 BitLocker 回避に関する 38C3 発表: https://media.ccc.de/v/38c3-windows-bitlocker-screwed-withou...
BitLocker は電源が切れているコンピューターだけを適切に保護し、それも BitLocker が起動パスワードを要求するよう設定されている場合に限る、という点はかなりよく知られている
[0] https://en.wikipedia.org/wiki/BitLocker#TPM_alone_is_not_eno...
Windows にはメモリ圧縮とともに提案されたメモリ暗号化オプションがある
Intel と AMD はどちらも、この機能を CPU に組み込む作業を進めている
ただし対象はノート PC ではなく、複数の仮想マシンを動かすサーバーのようだ
近いうちに、暗号化された「仮想マシン」をこうした秘密値の保管手段として活用しても驚きではない。必要なのは、コンシューマープラットフォームで広く一般化したハードウェアサポートだ
ただし、過去の CPU サイドチャネル攻撃は、暗号化メモリも攻撃可能であることを示している（https://www.usenix.org/conference/usenixsecurity21/presentat...）。CPU が通常動作のためにメモリを復号する際のキャッシュを狙うものだ
メモリダンプを無力化する助けにはなるだろうが、暗号化 RAM がメモリからキーをダンプする問題を終わらせることはできないだろう。特に、忍耐強い、または高度に熟練した攻撃者に対してはなおさらだ
https://techcommunity.microsoft.com/blog/windowsosplatform/m...
メモリ圧縮はかなり以前から存在し、少なくとも Windows 10 RTM の時点からある。主要な OS はすべてこの機能を実装しているが、セキュリティとは関係ない
関連記事: Lenovo ノート PC で安価なロジックアナライザを使って BitLocker をバイパスする
https://news.ycombinator.com/item?id=37249623
対象マシンのメモリダンプを読むことに依存する攻撃において、物理アクセスがあるなら、RAM に出入りするデータをコピーしたり変更したりするインターポーザ装置はどの程度現実的なのだろうか
昔の Gameboy 向け “Action Replay” のように、ゲームカートリッジからシステムへロードまたは実行されるメモリを改変してチートを可能にしていた装置を思い浮かべている。カートリッジを Action Replay に挿し、Action Replay を Gameboy に挿す方式だ
RAM とマザーボードの間でも似たようなことはできるだろうか。RAM を装置に挿し、その装置をマザーボードに挿して、メモリの読み書きを観察し、任意の時点のメモリ状態をキャプチャする、という形だ
そうすれば、手動で電源を切って必要なデータが残っていることを期待する面倒を避けられる
電気工学者ではないので、完全に不可能な提案かもしれない。物理的なスペースと帯域幅の制約は確かに大きそうだが、可能ではあるのか？
既製品のソリューションとして出てくるとは期待しにくい
ここ数年に発売された Intel/AMD CPU が透過的な全メモリ暗号化をサポートしていることを知っている人は少ない
RAM の内容は CPU のメモリコントローラ内に保持され、リセット時に生成されるランダムなキーで暗号化される
通常 BIOS ではオフになっているが、メモリ性能にわずかな低下（0.1%〜1%）があるためだ
しかし、この攻撃は完全に防げる