はじめに
こんにちは。基礎技術研究部の松尾です。 8 月に、ラスベガスのマンダレイベイにて行われた Black Hat USA 2025 の Briefings に登壇してきました。 この記事では登壇に至るまでの経緯や、プラットフォームセキュリティ及び低レイヤーにまつわる面白かった発表について紹介させていただきます。
Black Hat について
Black Hat はサイバーセキュリティの分野における世界トップレベルの産業系カンファレンスです。 最新の研究についての発表 (Briefings) や、ツールの展示・デモ (Arsenal)、企業紹介 (Business Hall) などが同じ会場で同時並行に行われます。 毎年世界中のセキュリティ関係者が、最新の技術動向や研究発表を知るために集まります。
発表した内容について
Shade BIOS: Unleashing the Full Stealth of UEFI Malware
今回私は Briefings にて、OS 起動後も BIOS 環境をメモリに維持して使用する事により、OS やアンチウイルスから独立して悪性挙動を行う技術 Shade BIOS について発表しました。
BIOS とは、PC のハードウェアを初期化し、OS をブートするためのシステムファームウェアです。UEFI は、BIOS の仕様です。UEFI では例えば、PC の電源が入れられてからシャットダウンするまでのブートフェーズや、デバイスアクセスに必要なインターフェースで BIOS が用意するべき物などを定義づけています。BIOS が悪用された場合のリスクは高く、OS やその下のハイパーバイザーに備わるセキュリティ機構を改ざんし、自由にバイパスする事が可能となります。また、BIOS はディスクではなく SPI フラッシュチップという不揮発性メモリに格納されているため、ここにマルウェアを置くことでディスク取り替えや OS 再インストールでも取り除けなくなります。
UEFI BIOS は、独自のメモリ管理システムやデバイスドライバーを持ちます。例えば、UEFI ブートサービスの gBS->AllocatePages() を用いることで、BIOS のメモリマネージャーに新たなページを要求できます。また、HttpProtocol 等の UEFI プロトコルを用いることで、UEFI ドライバーを用いたデバイスアクセスが行えます。しかし、UEFI ブートサービスや UEFI プロトコル、UEFI ドライバーは BIOS から OS に制御が移行するタイミングで破棄され、使用できなくなります。
正確には、BIOS が OS に制御を移す際、OS ローダーは gBS->GetMemoryMap() を実行することで BIOS からメモリマップをもらいます。この時、UEFI ドライバー等が置かれているメモリ領域は OS 起動後には不要と判断し、OS のコード等でそのメモリ領域が上書きされます。
本研究では、本来 OS のコードで上書きされてしまう BIOS 環境 (UEFI ドライバー等) をメモリに残し、OS 起動後も BIOS の機能を用いる手法 Shade BIOS を提案しました。 これにより、OS のセキュリティ機構やアンチウイルスとは独立した環境で悪性挙動を行う事ができます。
既存の UEFI マルウェアは全て、C2 通信やファイル窃取等の悪性挙動を最終的にユーザーランドかカーネルにて行っています。 その悪性挙動が検知されないよう、既存のマルウェアは OS のセキュリティ機構を BIOS 側から無効化します。 詳細については、過去のエンジニアブログをご参照ください。 しかし、このアプローチだと全ての OS のセキュリティ機構を無効化しない限り、OS レベルのセキュリティ機構から検知される可能性があります。 また、攻撃者は攻撃対象で何のアンチウイルスが動作しているかを把握し、かつそのアンチウイルスにてどのようなカーネルドライバーが用いられているか等を把握した上で、それらを無効化する必要があります。 Shade BIOS は、C2 通信等の悪性挙動を行うのに、アンチウイルスや OS のセキュリティ機構が存在しない BIOS の環境を用いるため、既存の UEFI マルウェアよりも検知困難となります。
発表では、純 BIOS マルウェア (OS 等に頼らず、BIOS だけで悪性挙動を行う) が実現可能である事を示しました。 また、それらを検知するためには悪性挙動を観測してからではなく、"事前に" マルウェアの存在を検査する必要がある事を主張しました。 このようなマルウェアの事前検査は、特に安全保障の文脈における政府調達の PC のバックドア検査等で重要になります。
登壇に至るまで
本研究は、私が修士 2 年の 2023 年 8 月 ～ 2023 年 12 月の間で取り組んでいたのですが、実現できそうになく一度中断しました。2024 年 12 月 ～ 2025 年 3 月にリベンジして成功し、3 月末に CFP を提出しました。大体八ヶ月間で行ったという事になります。
本研究を始めたきっかけですが、私の去年の Black Hat USA 2024 の研究を始めた修士 2 年の時にこれを思いつきました。 去年は、Option ROM バックドアから行なわれる悪性挙動を、BIOS だけで行うもの、カーネルの機能を用いるもの、ユーザーランドを用いるものに場合分けし、各々において既存手法より検知困難な手法を発表しました。 詳細は BHUSA 2024 の登壇経緯のエンジニアブログをご覧ください。 しかし、研究していた当時から BIOS だけで悪性挙動を行えれば一番ステルスである事はわかっていたので、今回の Shade BIOS を実現し、発表したいと考えていました。
そもそも何故 Shade BIOS を思いついたかですが、これは私が UEFI マルウェアについて勉強するためにその解析レポートを読んでいた際に抱いた疑問がきっかけでした。 せっかく BIOS という一番権限の高いレイヤーまで感染できたのに、何故またカーネルやユーザーランドという弱い権限の所にシェルコード等を配置して悪性挙動を行うのだろうかと思ったのが始まりです。 その後、これは研究テーマにできるのではと思い、実際に BIOS のモジュールだけで完結するマルウェアを作成しようとしました。 しかし、BIOS の機能は OS 起動後にはほとんど使えず、ろくな機能を実現できない事にすぐ気が付きました。 そこから、BIOS をメモリに残し、かつちゃんと動くようにする方法を模索しました。
最初は BIOS の機能全てではなく、特定の UEFI プロトコルだけを使えるようにしようと考えていました。
ゆえに、特定の UEFI プロトコルのコードを EfiRuntimeMemoryServicesCode (OS 起動後もメモリに残るコードのメモリ属性) のメモリ領域にコピーする方法を取りました。
しかし、コードを動かすということは "再配置" と同じであり、アドレスの調整等ができずすぐに断念しました。
そうではなく、UEFI プロトコルが置かれているメモリの属性自体を変更しようという方針に切り替えました。
続いて問題となったのは、OS 起動後にメモリが仮想化されるので、UEFI プロトコルを実行しても中で物理アドレスへのアクセスが生じ、ページフォールトによりブルースクリーンが起きるという問題です。 最終的にこの問題は、去年の Black Hat USA 2024 で発表した partial identity mapping を使用する事で解決しました。 実はこの技法は去年の研究ではなく、この Shade BIOS の問題を解決するために生まれた手法でした。
ここまでは修士 2 年の 12 月の段階で出来ていたのですが、次の問題が中々解決できず、UEFI プロトコルをメモリに保存する手法を中断する事になりました。
それが、ハードウェアデバイスの設定が OS デバイスドライバーに奪われているという問題でした。
当時、メモリに保存した UEFI プロトコルを実行すると、PCI バス関連の UEFI ドライバーのどこかのコードでクラッシュするという問題を抱えていました。
WinDbg との長い格闘の末、メモリアドレス 0xe00a8004 の書き込み時にクラッシュする所までわかっていました。
しかし、この原因箇所を特定するデバッグだけでも、何度も再起動してデバッガをアタッチしてシンボルの無いコードを読む必要があり疲弊しており、ここで断念しました。
ちょうど一年経った 2024 年の 12 月、年末年始に実家で Peripheral Component Interconnect (PCI) の仕組みに関する本を暇つぶしに読んでいました。
そこで、0xe00a8004 の物理メモリアドレスは PCI Config 空間のアドレスである事に気づきました。
2025 年の最初の出勤日にあれこれ調査した所、結局は単純に partial identity mapping のページテーブルの内容に誤りがあったとすぐにわかりました。
0xe00a8004 の仮想アドレスへのアクセスが 0xfffffe00a8004 の物理アドレスに解決されてしまっていました。
PCI の仕組みは結局関係無かったものの、どういう処理で詰まっていて、本来どう動くはずというのがわかっていたからこそ、この原因を突き止める事が出来たといえます。
年末年始にはもう一冊、uchan_nos さんの USB 3.0 ホストドライバ自作入門を読んでいました。 対象としていた UEFI プロトコルは USB ドライブの読み書きに関するプロトコルだったのですが、この本のおかげで UEFI ドライバーの処理内容の意味が明快になりました。 これらをきっかけに研究が進み、3 月にギリギリ完成させて CFP を提出しました。
参加してみての感想と反省
今回、参加前から体調不良でかなり衰弱しており、案の定 Black Hat 期間中には大きく体調を崩してしまいました。 何とかアドレナリンで無事発表はできたものの、その前後は基本ホテルで療養していたため、特段記述する事がありません。 とはいえ、海外での体調管理の大切さを痛感したため、同じような人が現れないようここに感想と反省を記述します。
まず、ラスベガスで病気になったら本当に地獄です。
- 救急車が高額
- 海外保険で利用可能な病院が会場の近くに無い
- 昼夜逆転の時差により自律神経が乱れる
- 重くて割高な食事しか売っていない
- 外はお祭り騒ぎでうるさい
- 室内はどこも極寒
- ホテルの部屋では冷房を消しても寒い
- ホテルに体温計などは置いていない
発表や帰国のフライト等のずらせない予定が差し迫る中、一本 1000 円程度の水を買い続けてお金が溶けていき、慣れない食べ物を普段寝てる時間帯に摂取しながら体調を治す必要があります。
私は胃の不調でご飯が入らない状況だったのですが、幸いカロリーメイトを 5 箱持ってきていたので、何とかそれで食事問題は解決しました。 また、部長も Briefings に採択されてラスベガスに来ていたため看病していただいたのもあり、何とか無事帰国できました。 しかし、もし一人だった場合、どうなっていたかは考えたくもありません。
この反省を踏まえ、以下に体調不良に備えて絶対やっておくべき Tips を共有させていただきます。
- 体温計及び、期間中の全日数分の常備薬は必ず持っていきましょう
- 特に、時差で普段寝てる時間に慣れないものを食べる事になるので、胃薬は必須です
- おかゆやカロリーメイト等、非常食を用意しておきましょう
- 同伴者、いなければ他の日本人参加者と連絡を取れるようにしておきましょう
- Briefings 発表者は Mandalay Bay ホテルの部屋が無償提供されますが、このホテルは部屋のカードキーが無いとエレベーターでその階まで行くこと自体ができません
- カードキーを複数もらい、事前に信頼できる人へ 1 つ渡しておくと安心です
- ホテルチェックアウトから帰国までの間、緊急時に滞在できる場所を確保しておきましょう
- DEF CON に行く日本人の宿泊先に滞在させてもらうのも 1 つの手です
- Mandalay Bay のチェックアウトは 11:00 です
- チェックアウトはオンラインでできます
- 加入してる海外保険が対象の病院で一番近い所とその営業時間を事前にチェックしておきましょう
Mandalay Bay の宿泊部屋から一番近い売店は、エレベーターを降りてすぐ隣です。ここは商品に値段が書いてありませんが、飲み物の値段は以下のような感じです。
隣の棚にはデカいサンドイッチ、ヨーグルト、フルーツ盛り合わせなどの食べ物があります。 炭水化物を取りたい場合、サンドイッチが良さげに感じますが、硬く大きなパンに、消化しづらい具材がサンドされているので食欲不振の際は厳しいかと思います。
もし付き添いの人が買ってきてくれる場合、Mandalay Bay の近くでおそらく一番安く水や食材を調達出来るのは、歩いて 10 分の Green Valley Grocery Store です。ここでは水が 2.5 ドル程度で少し安く買えます。
海外のカンファレンスは健康ならば楽しい出張ですが、体調不良の場合はトラウマレベルの体験になります。特にスピーカーは予定がずらせないので、上記の事前対策をしっかり行うことを強くおすすめします。 私はしばらく海外に行きたくないです。
その他のプラットフォームセキュリティにまつわる発表
Black Hat USA 2025 での他の Briefings 発表で、私の分野に近い発表で面白かった物を 3 点紹介させていただきます。
Ghosts in the Machine Check - Conjuring Hardware Failures to Breach CPU Privilege Boundaries
この Briefings 発表は、Machine Check Exception という特別な例外を用いて、ring 0 (カーネル権限) から System Management Mode (SMM) などへの権限昇格手法を紹介しています。
割り込みや例外をセキュリティ上安全に行うためには、排他制御が重要になります。 例えば、あるデバイスにデータ A を書き込む要求をして、その次のアセンブリ命令にてその結果をデバイスから読み取るコードがあったとします。 そして、この 2 つの命令の間で割り込みや例外が発生し、その割り込みハンドラーにて同じデバイスにデータ B が書きこまれたとします。 割り込みハンドラーの処理が終了した後、元のコードに制御が戻り、デバイスからデータを読み取った場合、本来は A が返って欲しい所、B が返ってくるという状況が起こります。 このような問題を防ぐために、排他制御が不可欠になります。 具体的には、上述のようなコードを扱う前に一定の割り込みを禁止し、終わった後に割り込みを解禁する必要があります。
しかし、昔からこの割り込みと排他制御においては多くの脆弱性が発見されています。
この脆弱性は、主に権限昇格に悪用されています。
例えば、2012 年の Wojtczuk 氏の発表では、システムコールのハンドリング中における排他制御の不備を突いて、ユーザーランドからカーネルに権限昇格しています。
システムコールでカーネルのコードを呼び出した後、sysret で元のユーザーランドのコードに戻ります。
この時、sysret の手前でユーザーランドのスタックに戻してからリターンしますが、sysret のタイミングで例外を起こすことで、ユーザーランドのスタックのまま例外ハンドラーに制御が移ります。
ゆえに、例外ハンドラーから元のカーネルのコードにカーネル権限のまま遷移するはずの所、実際はユーザーランドのスタック上のコードへリターンしてしまう事になります。
その他にも、Google Project Zero の 2023 年の発表では Trusted Execution Environment (TEE) に対して割り込みを使った攻撃がなされました。これは、信頼されていない領域の攻撃者からセキュア領域に対する攻撃です。
このような割り込みを使った攻撃の対策として、排他制御をしっかり行う、すなわち割り込みを適切に禁止する事がポイントになってきます。 しかし、この発表では、他の例外と違い禁止出来ない特殊な例外を使うことで、より対策が難しい攻撃手法を提案しています。 その特殊な例外が、Machine Check Exception (MCE) で、これはハードウェアに異常が起きた時に発生する例外です。 MCE は、主にデバイスの経年劣化、周囲の温度の許容範囲超え、静電気などの原因で発生する例外であり、一般的な例外を禁止する CLI 命令等では抑圧できません。
この発表では、MCE をソフトウェアから意図的に発生させる方法をデータシートから発見し、権限昇格へと応用しました。 具体的には、特殊な設定をある PCI デバイスに対し行った上で、存在しない PCI デバイスにリクエストを発行する事でこの例外を発生させています。 PCI デバイスの設定をいじるには ring 0 権限が必要です。ゆえに、これを用いて権限昇格する場合、ring 0 より大きい権限を狙う事になります。 候補として、ハイパーバイザーやエンクレーブ等色々ある中で、この発表では SMM を対象にしています。
この発表の攻撃手法は、SMM へ移行後に MCE を発生させ、攻撃者の用意した MCE の例外ハンドラーに制御を飛ばす事で SMM 中に任意コード実行を可能にします。 あらゆる割り込みや例外のハンドラーは Interrupt Descriptor Table (IDT) にそのアドレスが格納されています。 OS が扱う割り込みは OS が用意した IDT を、SMM では SMM が用意した IDT を用います。 ring 0 権限でいじれるのは OS が用意した IDT のみなので、本来は上記の権限昇格は行えません。 しかし、AMD の SMM の仕様では、SMM に移行してしばらくは OS の IDT のままになっており、SMM のコードの途中で SMM の IDT に切り替わります。 よって、OS の IDT にて MCE の例外ハンドラーを攻撃コードに置き換え、SMM の IDT へ切り替わる前に MCE を発生させる事で攻撃コードを SMM で実行できます。
実際にはもっと色々工程があるのですが、詳細は元の発表をご参照ください。
この発表で私が興味深いと思った点は、純粋にこの研究者の粘り強さと技術力です。 この研究は、脆弱性を見つけてそれを攻撃するという流れではなく、実現したい攻撃を通すためにデータシートを熟読して実験を重ね、必要な脆弱性も見つけるという流れで行われています。 その点において私の研究スタイルと同じである一方、仮に私がこの研究を進めていた場合、途中で私なら挫折しているポイントがいくつもあると思いました。 上述の説明では省略しましたが、攻撃を成功させるには攻撃対象のスレッドが SMM に移行してから 10,000 CPU サイクル後に MCE を非 SMM の攻撃スレッドから発生させる必要がありました。 また、そこから 100 サイクル後に IDT が SMM 用へ置き換わるので、10,100 サイクル目までの間にタイミング良く MCE を発生させる必要もありました。 しかし、SMM に移行するための割り込みである System Management Interrupt (SMI) が発行されると、全スレッドが SMM に入ってしまいます。
私であれば、このタイミングで原理的に無理だと判断し、諦めていたと思います。 しかし、この研究者は SMI があるスレッドで発生した後、別スレッドでは現在処理中の 1 命令を終えてから SMM に移行するという性質に注目しました。 そして、その命令 (MCE を発生させる命令) がちょうど 10,000-10,100 サイクル後に終わるよう調整することで、攻撃を成功させました。 この CPU サイクルレベルで攻撃を調整する技術力及び、これを含むどんな技術的障壁が出てきても粘り強く研究する姿勢に私は圧倒されました。
Booting into Breaches: Hunting Windows SecureBoot's Remote Attack Surfaces
この Briefings 発表では、セキュアブートをバイパスできるブートローダーの脆弱性をファジングで大量に見つけたという発表です。
セキュアブートとブートローダーと言えば、去年の Black Hat USA 2024 にて Demirkapi 氏が発表を行っていました。 去年のこの発表では、セキュアブートの署名管理において、互換性の都合でブートローダーに脆弱性があってもブラックリスト化する事が難しいという問題点を指摘していました。
この発表では、32 件のセキュアブートをバイパスする脆弱性を PCA2011 で署名されたブートローダーにて見つけています。 この脆弱性が修正されたものも既に出荷されているのですが、残念ながら署名管理における互換性の都合上、この脆弱性は今でも悪用可能となっています。 この PCA2011 が失効されるのは 2026 年であり、攻撃者は Bring Your Own Bootloader (BYOB) を用いて攻撃対象のセキュアブートをバイパスできます。
もう一点発表の中で触れられていた重要な点は、ブートローダーのセキュアブートバイパス脆弱性はこの発表より過去に 8 件しか見つかっていないという点です。 これはそれほど堅牢に作られているという訳ではなく、単にここを見ている研究者があまりいなかったためと予想されています。 それ故に、かなり初歩的なバッファオーバーフローなどの脆弱性も多く見つかったそうです。
発表では、バグハンターからの視点でどのような環境を用いてどう解析したかを中心に紹介しています。 各脆弱性の詳細等は元の発表をご確認ください。
ここからは私の感想です。 まず、セキュアブートは BIOS のみならずプラットフォーム全体の安全性に関わるため、このバイパス手法はとても重要なテーマだと思っています。 去年と今年とでこのテーマに関する発表が 1 つずつあったわけですが、来年からは PCA2011 の失効によりセキュアブートに大きな変化が出てきます。 一方で、セキュアブートの脆弱性自体があまり見つかっていない事から、この界隈の研究が不十分である事も問題だと考えています。 次の PCA2023 でも、このブートローダーにまた脆弱性が見つかった場合、BYOB にてセキュアブートをバイパスできる可能性があります。 その未来の脆弱性と、去年の Demirkapi 氏の発表にて説明された署名管理方法の変化との攻防に、今後の期待が高まりました。
BitUnlocker: Leveraging Windows Recovery to Extract BitLocker Secrets
この Briefings 発表では、Windows のリカバリーにおける脆弱性を悪用し、BitLocker をバイパスして復号された OS のドライブを読む複数の手法を紹介しています。
BitLocker は、主にラップトップが丸ごと盗まれてデータを読み取られる攻撃から守るための防御機構です。 発表中に紹介されていた統計では、53 秒に 1 回の頻度でラップトップは盗難されているそうです。 この攻撃は、攻撃者はその端末のクレデンシャルを持ち合わせていないという脅威モデルを想定しており、Windows にログオンできない状態でデータを引き抜く必要がある点に注意が必要です。 BitLocker は、C ドライブ等のディスク領域を暗号化し、OS 起動後にのみ復号データへアクセスできるようにしています。
一方、OS にログイン出来ない場合などに備え、WinRE (Windows Recovery Environment) があります。 リカバリー時もディスクにアクセスできないと困るので、この時もディスクは復号されています。 リカバリーは、OS にログイン出来なくてもアクセスできるため、この性質を用いてファイルを読み取ろうとするのがこの発表の趣旨です。 もちろん、リカバリーを起動すればファイル読み書きし放題という訳ではなく、不審な行動をすると再度ロックがかかり、リカバリーキーを入れない限りその OS のボリュームにはアクセスできなくなります。
リカバリーでは、recovery OS というメインの Windows OS とは独立した OS が動いています。 そして、これを含むその他各種リカバリー用の exe や dll ファイルは、全て 1 つの WinRE.wim というファイルに圧縮されています。 リカバリー自体のファイルが改ざんされないように、この WIM ファイルはブートマネージャーによってハッシュ値による検証が行われます。
紹介されている脆弱性はどれもロジカルバグで、リカバリーの起動において用いられている、検証されていない外部ファイルを改ざんする事で攻撃しています。 例えば、WIM ファイルのメモリ上のオフセットなどの情報は、暗号化されていないリカバリーボリュームにある Boot.sdi から取得しています。 しかし、この Boot.sdi に対してはハッシュのチェックが行われていませんでした。 ゆえに、正規の WIM ファイルを使って検証を通し、Boot.sdi には攻撃者の WIM ファイルを参照させることで、検証をバイパスして悪性の WIM ファイルを起動できます。
これらの攻撃の対策として、BitLocker の設定にて TPM+PIN を有効化する事を推奨しています。
ここからは私の感想です。 BitLocker は BIOS に感染するマルウェアにも影響するので、個人的に注目しています。 BIOS マルウェアの強みの 1 つとして、アンチウイルスが動作していないブート中に悪性挙動を行えるという点があります。 しかし、BitLocker が有効だとブート中に OS のファイルを読み取るといった攻撃ができなくなります。 この発表で紹介された攻撃手法は、どれも recovery OS によりディスクが復号される点を利用しているので、これを応用してブート中に OS のファイルを盗むのは難しそうです。 そうなると、今回私が発表した Shade BIOS を利用して、OS 起動後にファイルを読むことにより大きな価値が出てきます。 残念ながら Shade BIOS はまだ未成熟であり、SSD からデータを読み取る事ができるかはまだ未検証なのですが、早く検証する必要があると思いました。
おわりに
今年も Black Hat USA での登壇の機会をいただけたことに感謝しています。 本研究は特に基礎技術研究部のメンバーと多くの議論を経て出来上がったものであることに加え、私が CFP に間に合うよう他の雑務をメンバーが受け持ってくれるなど色々な協力がありました。 また同じ部署だけでなく、CFP 締め切り 2 週間前に実験対象の PC が文鎮化した際、すぐに代わりを送ってもらうなど、当社の他のメンバーの協力も非常に大きいものでした。 関わっていただいた当社のメンバー全員に、大変感謝しております。
今後は UEFI セキュリティを突き詰めるだけでなく、体調管理等にも気をつけながら研究をしていこうと思います。
エンジニア募集
ＦＦＲＩセキュリティではサイバーセキュリティに関する興味関心を持つエンジニアを募集しています。 採用に関しては採用ページをご覧ください。
