BitLocker 攻撃

BitLocker に対する公開攻撃の一覧です。BitLocker を攻撃する可能性はあるものの、正確な手法がまだ公開されていない公開攻撃（baton drop など）は対象外です。

ほとんどの攻撃は、VMK が TPM のみによってシールされる設定（デフォルト設定）を対象としています。これは、自動 BitLocker が回復キーの Microsoft アカウントへのエスクローと併せて使用する設定です。

既定では、Windows 8 以降、Secure Boot が有効な場合に Secure Boot 整合性検証が使用されます。

VMK を TPM のみでシールする必要がある場合、最も安全な構成は、PCR 0、2、4、7、11 を使用したレガシ整合性検証を使用することです（また、システムを完全に更新し続けることも重要です）。
これはソフトウェア攻撃に対してのみ保護することに注意してください。

Contents

• ハードウェア攻撃
• ソフトウェア攻撃

ハードウェア攻撃

ハードウェア攻撃は、通常、攻撃者が VMK が TPM のみでシールされているシステムに物理的にアクセスできる場合にのみ有用です。

ソフトウェア攻撃

ソフトウェア攻撃は、通常、bootmgr または他のブート アプリケーションの脆弱性であり、任意のボリュームについてメモリ内の導出された BitLocker キーを使用して悪用が可能です。
ブート アプリケーション内でコード実行を取得できる場合、「evil cleaner」攻撃者は、導出されたキーがメモリ内にある状態（またはキーがまだ導出可能な状態）で実行されるブートキットをインストールし、TPM の代わりにまたは TPM に加えてパスワードまたはスタートアップ キーが使用されているシステムを侵害する可能性があります。

dangerous association

影響を受けるシステムには、2022年5月または2022年6月の更新プログラムがインストールされていますが、それ以降の更新プログラムはインストールされていません。

関連オプションの GUID はハッシュ化されたデータの一部であるため、使用されるデバイス要素は「未検証」としてマークされる必要があります。
Windows 7 以前で使用できる要素はありません（ただし、カスタムの非デフォルト設定が使用されている場合は、依然として可能な場合があります）。
Windows 8 以降では、osloader!osdevice はデフォルトでは検証されないため、使用できます。
これを悪用する最も簡単な方法は、BCD の生デバイス エディター bcdeditmod を使用することです。BCD レジストリ ハイブを手動で編集することも可能ですが（自分で理解してください）。

悪用の手順は次のとおりです：

• ターゲット デバイスから BCD を取得し、2 つのデバイス要素を作成します
• {default} から最初のデバイス要素に osdevice をコピーします
• {default}!osdevice の関連オプション GUID を最初のデバイス要素に設定します
• {first}!osdevice の関連オプション GUID を 2 番目のデバイス要素に設定します
• 2 番目のデバイス要素に任意の「危険な」オプション（debug など）を設定します
• その BCD と、ターゲット デバイスが使用していたのと同じ bootmgfw バイナリを使用してターゲット デバイスをブートします

bitpixie

この脆弱性は 17 年以上存在していました。導入された最も初期の既知ビルドは、2005年10月の 6.0.5231.2 (winmain_idx03.051004-2120) です。
セキュア ブート整合性検証が使用されている場合、この脆弱性を悪用するにはダウングレード攻撃が依然として有効です。Set up a PXE boot server with a vulnerable bootmgfw.efi (where legacy integrity validation is used, this must be the bootmgfw.efi from the target device) renamed correctly for EFI booting.

PXEブートサーバーを、脆弱性のある bootmgfw.efi（レガシー整合性検証が使用される場合、これはターゲットデバイスの bootmgfw.efi でなければなりません）をEFIブート用に正しくリネームしてセットアップします。

For the BCD, set up one default entry where device is the BitLocker encrypted osdevice; path is "\"; and a recovery sequence.

BCDでは、device が BitLocker で暗号化された osdevice であるデフォルトエントリを1つ設定し、path を "\" にし、回復シーケンスを設定します。

The recovery sequence should point to a single startup entry, where device is boot, path points to an EFI application to run (from the PXE server); and pxesoftreboot is enabled.

回復シーケンスは、単一の startup エントリを指すようにします。ここで device は boot、path は（PXEサーバーから）実行するEFIアプリケーションを指し、pxesoftreboot が有効になっている必要があります。

When Secure Boot is disabled, that EFI application can just be an application to scan physical memory looking for a BitLocker keytable to dump.

Secure Boot が無効な場合、そのEFIアプリケーションは、物理メモリをスキャンしてダンプする BitLocker キーテーブルを探すアプリケーションだけで構いません。

When Secure Boot is enabled, that EFI application can use a known Secure Boot bypass (where physical access is required if needed).

Secure Boot が有効な場合、そのEFIアプリケーションは既知の Secure Boot バイパスを利用できます（必要に応じて物理アクセスが必要です）。

For exploiting a Windows boot application in this way, you will need to replace the BCD with your second one on the PXE server.

この方法でWindowsブートアプリケーションを悪用するには、PXEサーバー上のBCDを2番目のものと置き換える必要があります。

This means pressing an arrow key during bootmgr startup to force the boot menu to show; and then replacing the BCD on the PXE server at that point.

つまり、bootmgr 起動中に矢印キーを押してブートメニューを強制的に表示させ、その時点でPXEサーバー上のBCDを置き換えるということです。

プッシュボタン復号

Exploitation involves:

悪用の手順は次のとおりです。

• Dump the bitlocker protected osvolume to a disk image. This method to get the FVEK leads to actual data loss!

• BitLocker で保護された osvolume をディスクイメージにダンプします。 この方法で FVEK を取得すると、実際にデータが失われます。

• Boot to WinRE using whatever means (force it by startup repair if needed, or just set bootsequence BCD element, etc).

• 任意の手段で WinRE にブートします（必要に応じてスタートアップ修復で強制するか、単に bootsequence BCD 要素を設定するなど）。

• Start a reset (Troubleshoot -> Reset this PC -> Remove everything). It's quicker to choose "Local reinstall". Be sure to choose "Just remove my files".

• リセットを開始します（トラブルシューティング -> このPCをリセットする -> すべてを削除する）。"ローカル再インストール" を選択する方が高速です。必ず "ファイルを削除するだけ" を選択してください。

  • Choosing to "keep files" will ask for recovery key.

  • If the system's WinRE is not vulnerable, it will also ask for a recovery key.

  • "ファイルを保持する" を選択すると、回復キーを求められます。

  • システムの WinRE が脆弱でない場合も、回復キーを求められます。

• When the reset gets to ~98%, shut the system down forcefully (via holding power button down 7 seconds / etc).

• リセットが約98%に達したら、システムを強制的にシャットダウンします（電源ボタンを7秒間押し続けるなど）。

• Power the system back on, it should boot to WinRE again and show an error. Dismissing the error should reboot.

• システムの電源を再度オンにすると、再び WinRE が起動してエラーが表示されます。エラーを閉じると再起動します。

• When you see the blue "updating" screen, press Shift+F10 to get to a shell.

• 青い "更新しています" 画面が表示されたら、Shift+F10 を押してシェルを起動します。

• Execute manage-bde -pause C: followed by manage-bde -protectors -delete C:

• manage-bde -pause C: を実行し、続けて manage-bde -protectors -delete C: を実行します。

• Shut the system down forcefully (again).

At this point, the on-disk BitLocker metadata will contain a plaintext VMK.
Dump it, and use that VMK to decrypt the FVEK.
The decrypted FVEK can be used on the disk image made previously to decrypt the partition.

この時点で、ディスク上の BitLocker メタデータには平文の VMK が含まれます。
それをダンプし、その VMK を使用して FVEK を復号します。
復号された FVEK は、先ほど作成したディスクイメージに対して使用して、パーティションを復号できます。

Please note: I only successfully exploited this issue on Windows 10 in very specific circumstances (TPM-only BitLocker with no recovery key). However, others have successfully exploited this issue using a vulnerable WinRE on Windows 11 (Nickel).

注意: 私は、この問題を Windows 10 のごく特定の状況（回復キーのない TPM のみの BitLocker）でのみ悪用に成功しました。 ただし、他の研究者は、脆弱な WinRE を搭載した Windows 11 でこの問題を悪用することに成功しています（Nickel）。

RAMリーク

As far as I am aware, this vulnerability has existed as long as the boot manager has - it appears to be present as early as 6.0.5098.0 (winmain_beta1.050628-1740) from June 2005, although that pre-dates the BCD so exploitation would be different in builds that early. Relevant code seems to also exist earlier too (the ramdisk-related code appears to be the same in build 5048 from April 2005), but build 5098 is the earliest dumped build with BitLocker present in some form.

私の知る限り、この脆弱性はブートマネージャーが存在する限り存在してきました。2005年6月の 6.0.5098.0 (winmain_beta1.050628-1740) という初期ビルドにも存在しているようです。ただし、それは BCD より前のものであるため、そのような初期ビルドでは悪用方法が異なります。関連するコードはさらに以前にも存在しているようです（ramdisk 関連のコードは2005年4月のビルド5048でも同じようです）が、ビルド5098は何らかの形で BitLocker が存在する最も初期のダンプ済みビルドです。

To exploit this, you need to set up a default entry and a recovery sequence like in bitpixie. This is to so the keys are derived for the OS device when the file is loaded.

これを悪用するには、bitpixie のようにデフォルトエントリと回復シーケンスを設定する必要があります。これは、ファイルが読み込まれたときにOSデバイス用のキーが導出されるようにするためです。

The recovery sequence must have an additional device entry to set up the ramdisk. Use bcdeditmod for this. Use a custom element here like custom:21100000. An example of a device entry to use here would be !raw:block[ram[part2[hd[gpt[{D2E23617-2338-4685-A2D7-F3133312E12E}]],gptsig[{1B85332B-AD73-4D9A-BFC3-B39443D3DFE4}]],:\hiberfil.sys:]] - you'd want to replace the part2 block device here with the one from your target system's BCD.

回復シーケンスには、ramdisk をセットアップするための追加のデバイスエントリが必要です。これには bcdeditmod を使用します。ここでは custom:21100000 のようなカスタム要素を使用します。ここで使用するデバイスエントリの例は !raw:block[ram[part2[hd[gpt[{D2E23617-2338-4685-A2D7-F3133312E12E}]],gptsig[{1B85332B-AD73-4D9A-BFC3-B39443D3DFE4}]],:\hiberfil.sys:]] です。この part2 ブロックデバイスは、ターゲットシステムの BCD 内のものと置き換える必要があります。

The file can then be dumped out of memory using whatever method that works for you. I prefer to use older winload into self-signed mcupdate via advanced options menu, but other options are available (PXE soft reboot into a third party operating system for example; memory dumping from WinPE by using a bugcheck or a known vulnerable driver is possible, but winload will mark the memory area as free in the NT memory map so it might get overwritten without some other settings to mark that memory as bad/etc in winload).

その後、ファイルは自分に合った任意の方法でメモリからダンプできます。私は、詳細オプションメニューから自己署名の mcupdate に古い winload を使用する方法を好みますが、他のオプションもあります（例えば、PXE ソフトリブートでサードパーティのオペレーティングシステムに移行する方法。WinPE からバグチェックや既知の脆弱なドライバを使ってメモリダンプすることも可能ですが、winload は NT メモリマップ内のそのメモリ領域を空きとしてマークするため、winload でそのメモリを不良などとしてマークする他の設定がない限り、上書きされる可能性があります）。

A proof of concept implementation of my preferred method is included in this repository as ramleak.zip. Read the included readme for usage instructions.

私が好む方法の 概念実装 は、このリポジトリに ramleak.zip として含まれています。使用手順については、同封の readme をお読みください。

Shout out to Maxim Suhanov, this was inspired by reading CrashXTS writeup and figuring out some other way to possibly dump hiberfil.sys.

Maxim Suhanov に感謝します。これは、CrashXTS の記事を読み、hiberfil.sys をダンプする別の方法を考え出したことがきっかけでした。

And now for my own thoughts, about this bug and about yellowkey:

そして最後に、このバグと yellowkey についての私自身の考えです。

This was the first time I had a real issue with submitting to MSRC, and was mainly a misunderstanding from their side related to Secure Boot. Given that other bitlocker 0day being dropped I decided to release this now, I've been sitting on this for almost a year now wondering what to do with it.

MSRC への提出で実際に問題が起きたのはこれが初めてでしたが、主に Secure Boot に関する先方の誤解が原因でした。他の BitLocker ゼロデイが公開されたことを受けて、これを今リリースすることにしました。私はこれをどうするか約1年間悩みながら保留していました。

Unlike yellowkey, I won't make overblown calls about this being a "backdoor", in my opinion I don't think yellowkey is a backdoor, the related component is to do with WinPE (not WinRE-specific), and the main "vuln" there is getting winpeshl.ini deleted to reach that codepath, I can totally understand why MS thought deleting it in a WinRE+bitlocker scenario wasn't possible.

yellowkey とは異なり、私はこれを「バックドア」であると大げさに言うつもりはありません。私の意見では、yellowkey はバックドアではないと思います。関連するコンポーネントは WinPE（WinRE 固有ではありません）に関するものであり、そこでの主な「脆弱性」は、そのコードパスに到達するために winpeshl.ini を削除させることです。MS が WinRE+Bitlocker のシナリオでそれを削除することは不可能だと考えたのも完全に理解できます。

Given that loading a ramdisk from a bitlocker encrypted partition is actually a feature in the boot environment, although I had to use an existing trick to actually get it to work, other people could also say this was a backdoor if they wanted, but I'm not going to go that far. The boot environment is complex (and keeps getting bigger, latest bootmgfw_ex.efi no longer fits in a 2.88MB image - end of an era), several vulns have been discovered because of how certain features interact with each other.

BitLocker で暗号化されたパーティションから ramdisk を読み込むことは実際にはブート環境の機能であることを考えると、実際に動作させるために既存のトリックを使わざるを得ませんでしたが、他の人々は望めばこれをバックドアと言うこともできるでしょう。しかし、私はそこまでは言いません。ブート環境は複雑であり（そして拡大し続けており、最新の bootmgfw_ex.efi はもはや 2.88MB のイメージに収まりません - 一つの時代の終わりです）、特定の機能が互いにどのように相互作用するかによって、いくつかの脆弱性が発見されてきました。