はじめに
こんにちは。基礎技術研究部の松尾です。 8 月に、ラスベガスのマンダレイベイにて行われた Black Hat USA 2024 に登壇してきました。 また、9 月に、当社の新ローレイヤー勉強会にて登壇に至るまでの経緯について話させていただきました。 この記事では勉強会の内容を簡易化したものに加え、プラットフォームセキュリティにまつわる他の面白かった発表や、当日の感想や余談について紹介させていただきます。
Black Hat について
Black Hat はサイバーセキュリティの分野における世界トップレベルの産業系カンファレンスです。 最新の研究についての講演 (Briefings) や、ツールの展示・デモ (Arsenal)、企業紹介 (Business Hall) などが同じ会場で同時並行に行われます。 毎年世界中のセキュリティ関係者が、最新の技術動向や研究発表を知るために集まります。
発表した内容について
You've Already Been Hacked: What if There Is a Backdoor in Your UEFI OROM?
今回私は Briefings にて、PCIe デバイスの Option ROM (OROM) に身を置き、UEFI BIOS のモジュールとして動作するバックドアについて発表しました。
BIOS とは、PC のハードウェアを初期化し、OS をブートするためのシステムファームウェアです。UEFI は、BIOS の仕様です。UEFI では例えば、PC の電源が入れられてからシャットダウンするまでのブートフェーズや、デバイスアクセスに必要なインターフェースで BIOS が用意するべき物などを定義づけています。BIOS を悪用すると、OS やその下のハイパーバイザーに備わるセキュリティ機構を改ざんしてバイパスする事が可能となります。また、BIOS はディスクではなく SPI フラッシュチップという不揮発性メモリに格納されているため、ここにマルウェアを置くことでディスク取り替えや OS 再インストールでも取り除けなくなります。
OROM とは、そのデバイスを初期化して利用するための UEFI モジュールが格納されているフラッシュメモリです。例えば、マザーボードにユーザーが任意の PCIe デバイスを挿せる空き PCIe スロットがある場合、BIOS は事前にそこへ何のデバイスが挿さるかわかりません。故に、そのデバイスを初期化・利用するためのモジュールを事前に持っておくことができません。したがって、PCIe デバイスは自分を初期化・利用するための UEFI モジュールを OROM に入れておき、それを BIOS に使ってもらう事でこの問題を解決しています。具体的には、ネットワークアダプターならば、その "ドライバー" となる UEFI モジュールが入っています。この UEFI モジュールは、OS の起動や BIOS セットアップ画面の表示よりも前のブートフェーズにて BIOS にロードされ、エントリーポイントのコードが実行されます。この UEFI モジュールは、OS 起動後にもメモリに常駐させる事ができます。
この研究の新規性は、まず「OROM にバックドアが入っていたら」という脅威シナリオにあります。 BIOS 本体を開発する企業と、デバイス (OROM) を開発する企業は異なる場合があるため、BIOS 自体にバックドアを入れるシナリオとは違ったアクターからのバックドア混入の可能性を提示しています。 また、多くのバックドアはユーザーランドからのインストールが必要である一方、この脅威シナリオの場合はいきなり BIOS レベルに感染できます。 故に、BIOS のみで動作させる、あるいは BIOS とカーネルのレイヤーまでで動作させるといったように、いくつかの新たなシナリオが考えられます。 このように感染方向がボトムアップなため、バックドアの機能も特殊な実装になっており、その点もまた新規性のあるポイントとなっています。
この研究は、安全保障の文脈において特に重要性があります。政府やその関連企業が用いる PC をバックドアから防御するためには、まずどのような形でそれが混入されるのかや、そのインパクトについて明らかにする必要があります。OROM バックドアは、PC の製造過程から調達・納入に至るまでのサプライチェーン上の任意のタイミングで混入させる事ができます。かつ、OS の起動より前の段階から動作可能という点でインパクトも大きい物になっており、安全保障に大きく関わる脅威と言えます。
登壇に至るまで
この研究は、2023 年 4 月 ～ 2024 年 3 月のちょうど 1 年間で行いました。この時私は早稲田大学の森研究室にて修士 2 年の学生をしており、当社とは共同研究という形で関わっていました。
本研究を始めたきっかけですが、最初からこのテーマに設定していたわけではなく、何度もテーマ変更を繰り返してこれにたどり着きました。始めは、当社が EDR を作っている事を活かし、BIOS 用の EDR を作るというテーマで進めていました。しかし、UEFI に感染するマルウェアはどれも UEFI 自体で悪いことをしている訳ではなく、OS より上のレイヤーでの悪性挙動を検知しにくくするために UEFI を用いている事に気が付きました。よって、UEFI だけで悪性挙動を検知する仕組みは的外れだという考えに行き着きました。
次に、逆に UEFI だけで悪性挙動を行うマルウェアを考えれば良いのではと思い、テーマを変更しました。しかし、攻撃者が欲しい情報は OS 起動前にはあまり無いことに加え、BIOS のみで動作するランサムウェアやキーロガー等はちらほら既存研究がありました。強いて言えば、BIOS だけで C2 通信するという物は無かったのでこれを実装してみましたが、流石にこの 1 点だけでは弱いため、テーマを少し広げる事にしました。
BIOS だけで悪性挙動を実装している際に、UEFI プロトコルというデバイスアクセスを抽象化するインターフェースが重要であるとわかりました。 故に、UEFI-protocol based malware とテーマを変更し、逆にこのプロトコルを OS 起動後にも使えるように拡張する方針に変更しました (本来は OS 起動後に使えなくなる)。しかし、これは単純に実装が難しく実現できなくなったためボツになりました。
ここで一旦手詰まりになったのですが、私がこの時期に趣味でカーネルドライバーの勉強をしていた事もあり、BIOS とカーネルだけで悪いことをするというのでも新規性はあるのではと思いました。故に、テーマを BIOS + カーネルマルウェアのように変更し、UEFI モジュールからカーネルの機能を用いて C2 通信する PoC を実装しました。しかし、今度は単純に私の調査不足で、BlackLotus などの UEFI マルウェアは既にユーザーランドを使わない実装になっていました。とはいえ、細かく実装方法単位で見れば差分はあり、先程の BIOS だけでの C2 通信の実装と組み合わせれば新規性は上がってきた一方、もう一押しほしいなと思っていました。
当社の基礎研の他の方々と議論をしていた所、ユーザーランドにまで手を伸ばしても、検知を困難にする新しい手法はまだあるのではと思いました。 既存の UEFI マルウェアは、Protected Process Light (PPL) や Event Tracing for Windows (ETW) には触れていないので、これらを UEFI 独自の仕組みを用いてバイパスすれば、新規性があるのではと気づきました。 よって、PPL と ETW をバイパスする UEFI 疑似マルウェアを実装しました。
ここまでで新規性は 3 つ出せました。 しかし、どれも実装面の細かい話で、それぞれを紹介すると話にまとまりが無いため、これら 3 つが活きるシナリオを後付けで考えました。 この時期、私はちょうど IoT ハードウェアハッキングの動画を見るのにハマっており、Bus Pirate などのツールを購入し、OROM 等の色々なフラッシュメモリを読むといった事をやっていました。 そこで、OROM にバックドアが入っているというシナリオであればいきなり UEFI に感染が可能で、そこから UEFI のみ、UEFI + カーネル、UEFI + カーネル + ユーザーランドのように感染する場合分けを考えれば話が綺麗に収まると思いました。 このようにして研究が完結し、CFP を 3 月に提出しました。
参加してみての感想と反省
Black Hat USA は毎年ラスベガスで行われますが、周りの建物のインパクトにまず圧倒されました。
会場のマンダレイ・ベイという金ピカのホテルは、高級ホテルが並ぶストリップ通りの末端に位置しています。
この通りには例えば以下のようなホテルがありました。
その他感想の中で、これは共有した方が良いと思った物を以下にリストアップしました。
- 海外の方は名刺交換を滅多にせず、交換するとしたら LinkedIn なので用意しておいた方が良い
- 私は私用 PC のパスワードマネージャーにログイン情報を置いてきたので、当日ログインできずに使えませんでした
- Speaker とバッジに書いてあっても、相手からガンガン話しかけてくれる訳では無いので話しかける勇気は必要
- コミュ障なので待っていたら話しかけてくれるだろうと期待してましたが、当日もぼっちでした
- 発表してる様子は録画に残るので、後味を悪くしないために身だしなみや発表の仕方も練習した方が良い
- 発表前に髪型をちゃんとしようと思いお手洗いに行きましたが、普段何もしてないのでどうセットしたら良いのかわからず諦めました
- Briefings 期間の前日に day 0 としてスピーカー向けのイベントが色々あるので、前日の午前に着くフライトを予約したほうが良い
- VIP パーティーの終了 1 時間前にダッシュで駆け込み、既に出来上がってる輪に入れず話しかけづらかったです
- 共同研究者には Contributors として Briefings パスを渡せるが、共同研究者が現地に行かない場合でもオンラインパスがあるので Contributors に指定した方が良い
- 指定したら現地参加しないといけないと思っている方が私以外にも多数いました
- 壇上含め会場が全体的に寒いので、厚手の下着やジャケットを用意した方が良い
- 下着、T シャツ、シャツ、パーカー の 4 レイヤー でちょうどよかったです
その他のプラットフォームセキュリティにまつわる発表
Black Hat USA 2024 での他の Briefings 発表や Arsenal のツールで、私の分野に近い発表で面白かった物を 3 点紹介させていただきます。
Locked Down but Not Out: Fighting the Hidden War in Your Bootloader
この Briefings 発表では、BIOS の中で最も有名と言っても過言ではないセキュリティ機構「セキュアブート」の課題について説明されています。
セキュアブートは、信頼された署名が付いている UEFI モジュール以外は実行させない機構であり、脆弱性が見つかるなどして実行させたく無いモジュールを意図的に禁止する事もできます。 どのような署名が許可されているかに関しては、UEFI 変数である DB に格納されています。具体的には、署名にはその UEFI モジュールのハッシュがあり、DB にも許可されているハッシュが入っています。この UEFI 変数は任意の UEFI モジュールから書き換えられるとセキュアブートをバイパスできてしまうため、変更にはそれ用の署名を持っている必要があります。故に、一部のベンダーしかこれを変更できないようになっています。 また、DBX という UEFI 変数もあり、こちらには許可されていない UEFI モジュールのハッシュが入っています。 セキュアブートは仕組み自体強力なものの、実際の運用では多くの課題が残っています。 互換性の問題で失効できない場合や、1 つ脆弱性が見つかればそれを含む全てのバージョンのモジュールを失効しないといけないので抜け漏れがある等の課題があります。加えて、DBX は 32KB と比較的小さなサイズであり、600-800 個のハッシュしか入りません。これは、Microsoft が約 1 万のブートイメージを持っていて、かつそれらには共通するコードが多くある事を踏まえると少ないと言えます。 現段階で最も新しい UEFI マルウェアである BlackLotus は、既知の脆弱性の対応漏れのあるバージョンのブートローダーを悪用して、セキュアブートをバイパスしています。
この問題を解決するために、セキュアブートの証明書を管理する第一人者である Microsoft は、revoke by version という仕組みを実装し、2024 年 4 月にリリースしました。 モジュール 1 つ 1 つのハッシュを登録して失効させる従来の方法とは違い、バージョン情報を含むハッシュを登録させる事により、複数のバージョンを 1 回の登録で一気に失効させる事が可能になっています。 これにより、DBX の容量を大幅に節約できるようになります。
この発表で私が面白いと思った点は、セキュアブートの運用にはまだ多くの課題が残っているという点です。セキュアブートは、アンチウイルスのように悪性な挙動を判別して弾く仕組みではなく、信頼されたベンダーのモジュール以外の実行を許可しないという物なので、仕組みとしては非常に強力な物です。第三者の攻撃者は、アンチウイルスであれば悪性モジュールを良性と思わせれば良いですが、セキュアブートの場合は署名を持っていないので基本悪性モジュールを入れることができません。また、セキュアブートを前提としたセキュリティ機構も多くあります。例えば、Windows の仮想化ベースのセキュリティはセキュアブートが有効に機能している事が使うための条件になっています。故に、UEFI レベルでの攻撃を考える上で必ずつきまとう問題がセキュアブートであり、それをバイパスする方法として運用面の脆弱性を突くという観点は重要だと思いました。逆に、セキュアブートの運用の重要性についてよくわかる発表でした。
Damn Vulnerable UEFI (DVUEFI): An Exploitation Toolkit and Learning Platform for Unveiling and Fixing UEFI Firmware Vulnerabilities
この Arsenal で発表されたツールは、UEFI BIOS のエクスプロイトを練習するために多くの既知の脆弱性をあえて実装した DVWA のような環境・ツールです。UEFI セキュリティにおける実践形式の教育コンテンツは私が知る限りではこれが初めてです。
BIOS 周りを触る上で面倒なのが環境構築ですが、DVUEFI はこれを手軽に Docker で出来るよう工夫されています。BIOS のエクスプロイトを実機で行う場合、BIOS の当該バージョンにエクスプロイト可能な脆弱性が存在するか、DBX に何のハッシュが入っているかなどを考慮する必要があります。また、環境依存が激しいコードなので、別の環境で用いられたエクスプロイトは環境が変わると動かないといった事も多いです。こういう問題点を吸収し、BIOS のエクスプロイトにとっかかりやすくしてくれているこのツールは貴重です。
内容も単にバッファオーバーフローの対象が UEFI になっただけという感じではありません。 BlackLotus 等の実際の UEFI マルウェアが使うセキュアブートバイパス手法や、UEFI が格納されている SPI フラッシュのファイルシステムの解析など幅広く触れられています。しかし、流石に UEFI からブートローダー、そして OS へと感染するタイプの攻撃などはエミュレーター (QEMU) だけだと実装出来なかったとの事なので、物によっては実機環境を要します。とはいえ、網羅的に様々な攻撃が含まれており、今後は System Management Mode (SMM) と呼ばれる CPU の最高権限のモードのエミュレーションも実装していく予定との事です。ちなみに、SMM に権限昇格する事で BIOS が格納されている SPI フラッシュへの書き込みが可能になり、かつより多くのセキュリティ機構をバイパスできるようになります。
BIOS やブートキットに興味はあるが、実機の購入や環境依存の考慮がハードルとなっている方には非常に良いツールだと思います。また、BIOS にはスタックカナリーや ASLR などのエクスプロイト対策が少ないので、そういう面でも UEFI ならではの特徴を学びやすいと思います。
Compromising Confidential Compute, One Bug at a Time
この Briefings 発表では、Intel Trust Domain Extensions (TDX) のロジカルバグを複数見つけた内の 2 つを紹介しています。 具体的には、TDX のエミュレーター (Cornelius) を作り、それにて脆弱性を見つけています。
Intel TDX はいわゆる Trusted Execution Environment (TEE) の Intel CPU でのハードウェアサポートです。 クラウドでは、複数の企業・ユーザーの仮想マシン (VM) が同じハイパーバイザー (VMM) 上で動作しています。この時、VM が別の VM (ある企業が別の企業) のデータを見る事ができたり、そもそも VMM やその下の BIOS が改ざんされていてデータが筒抜けになっていたりしたら困ります。これに備えるため作られたのが Intel TDX で、これを用いると Trust Domains (TD) というハードウェアレベルで分離された機密 VM を作成できます。機密 VM のメモリは CPU の外に出ることは無い鍵にて暗号化されており、BIOS や VMM からであっても中を見ることはできないようになっています。TD を立ち上げるなどの管理を担うモジュールを TDX モジュールといいます。TDX モジュールは、SEAM Range というハードウェアレベルでアクセスが制限されたメモリ領域に置かれています。SEAM Range には、TDX モジュール以外の VMM 等のモジュールからはアクセスできません。
紹介されている 1 つ目の脆弱性は、Intel Processor Trace (Intel PT) を用いて SEAM Range を任意に読み書きできる脆弱性です。 SEAM Range を任意に読み書きできる事で TDX モジュールを改ざんでき、全ての TD から機密データを盗むことが可能になります。 Intel PT は、命令をトレースするための Intel CPU の機能です。Model Specific Register (MSR) という CPU のレジスタを用いてこの機能を有効化したり、どのメモリアドレスにトレース結果を保存するかを指定したりできます。 VMM から依頼を受けて TDX モジュールが TD を立ち上げる際、 VMM から指定された TD の初期レジスタをシステムに設定してから vmlaunch 命令を実行して TD に制御を移します。vmlaunch 命令を実行するまでは、CPU は SEAM VMX root mode という CPU モードになっており、SEAM Range にアクセスできる状態となっています。つまり、Intel PT の MSR が指定されていれば、このレジスタをセットしてから vmlaunch 命令が実行されるまでの間だけ TDX モジュールに対し Intel PT が使えます。 実際はもう一捻りありますが、ここでは簡略化して紹介しています。 VMM は Intel PT の設定でどこに何のデータを書くかをある程度指定できるため、信頼されていない VMM から SEAM Range を改ざんできる事になります。 よって、VMM で任意コード実行が可能な攻撃者は、TD のメモリから機密データを盗むことができます。
紹介されている 2 つ目の脆弱性は、仮想マシン (VMM1) の上にさらにもう 1 つ仮想マシン (VMM2) が動いているネスト構造の仮想化環境において問題となる脆弱性です。これは例えば、クラウドプロバイダーがコンテナ単位で貸し出しているようなケースに相当します。 通常ハイパーバイザーは、命令のエミュレート方法がわからない場合は、その命令の発生源であるゲストを kill するという挙動を取ります。 よって、TDX に対応していない VMM 上でコンテナが seamcall 命令等の TDX 特有の命令を実行した場合、コンテナから VMM1 に VMM2 を kill させる事ができます。 これにより、VMM2 の上にある (他の企業の) VM を全て kill する事が出来てしまいます。
Intel TDX や AMD-SEV のようなハードウェアレベルで分離された VM を構築する技術は、UEFI セキュリティに大きく関連する分野です。このようなハードウェアレベルでのサポートがある仮想化ベースのセキュリティは、BIOS や SMM を信用していません。つまり、BIOS を攻撃者が制御できるとしても、機密 VM のデータにはアクセスできない事を想定しています。しかし、ハイパーバイザーは BIOS よりも後に起動されるため原理的には BIOS はハイパーバイザーを好きにし放題です。そのため、この周りのセキュリティ機構は非常に複雑になっており、BIOS から本当に機密 VM の内容が守られているかを研究していく必要があります。この研究発表は、BIOS からの攻撃では無いものの、ハードウェアレベルで隔離された VM に対しどのような攻撃の糸口があるかを知れる貴重な発表だと考えられます。
Microarchitecture Vulnerabilities: Past, Present, and Future
この Briefings 発表では、Spectre や Rowhammer、CLKscrew や tempest などのサイドチャネル攻撃の歴史について網羅的に説明されています。 アカデミアと産業系の研究内容両方を含み、その歴史において脅威モデルがどのように変化していったかや、どの研究がゲームチェンジャーとなったか等が非常に良く説明されています。 さらに、これらサイドチャネル攻撃の対策の要となるマイクロアーキテクチャの重要性や、アカデミアと産業系とのギャップについても説明されています。
サイドチャネル攻撃の歴史は 1943 年のタイプライターへの TEMPEST 攻撃から始まりました。それから少し経った 1970-1980 年代辺りにてセキュア OS が出てきましたが、これの唯一対応できない攻撃がサイドチャネル攻撃でした。一方、1973 年にサイドチャネルを使って秘密の通信をする Covert Channel という概念が登場しました。Covert Channel の文脈にて、サイドチャネルによる漏洩が十分少なければ問題無いという考え方が出てきて、これが主流になりました。
しかし、1996 年に暗号鍵がサイドチャネルから漏洩できる事が発表され、大きな問題となりました。この場合、少しの漏洩 (数ビットの漏洩) で重要な情報が漏れてしまいます。この研究により、サイドチャネル攻撃の脅威モデルの対象は暗号にシフトしていきました。これが 1996-2015 年の主流でした。
2015 年になり、サイドチャネル攻撃は暗号からシステムセキュリティの分野まで広がりました。 ISCA 2014 や BHUSA 2015 にて Rowhammer、USENIX 2015 にて Cache Template Attacks、CCS + BHUSA 2016 にて KASLR バイパスが出てきました。 さらに、2017 年では TEE へのサイドチャネル攻撃がアカデミアの方で多く研究され始めました。そして、2018 年の USENIX と BHUSA や 2019 年の S&P において、CPU の投機的実行を悪用した Spectre と Meltdown が発表されました。これ以降の現在の傾向として、暗号の文脈でのサイドチャネル攻撃は減ってきており、Spectre のようなエクスプロイト周りの研究が増えてきています。特に、Spectre はアカデミック界隈では非常に有名で、GhostRace のような別の攻撃の一部としても頻繁に用いられています。
また、電力解析の研究も増えてきています。2020 年までは電力はフィンガープリンティング用途ばかりでしたが、2020 年の Platypus 攻撃という暗号鍵を割り出す攻撃により、脅威モデルが暗号へ広がりました。さらに、2023 年の Hertzbleed 攻撃により、時間を電力消費のプロキシとして利用する事でリモートから電力を使った攻撃が可能になりました。そして、同年の Collide+Power 攻撃により、暗号だけでなく汎用的なデータに対し電力解析による攻撃が使えるようになりました。Collide+Power 攻撃は、キャッシュを攻撃者がある値で埋めておき、被害者がアクセスして別の値へ変えたときに生じる電力消費で何のデータかわかるというものです。
ソフトウェアベースのフォールト攻撃も増えてきています。この分野においてゲームチェンジャーであった研究は Rowhammer で、これにより従来は物理アクセスを必要としていたフォールト攻撃がソフトウェアからも可能になりました。また、Rowhammer は未だ解決されていない (DDR4、DDR5 でも見つかっている) という点も注目すべきポイントです。 これ以外にも、2017 年にオーバークロックで Arm TrustZone を攻撃する CLKscrew や、2020 年に SGX を攻撃する Plundervolt などが出てきています。
これら攻撃の対策を考える上で重要なポイントは、「ハードウェアは一度世に出たら変えられない」という点です。そして、これを緩和するために出てきたのが、ハードウェアに限りなく近いマイクロコードです。マイクロコードだけでなく、ファームウェアも重要ですし、ハードウェアの機能を有効/無効に切り替えられる対策などもあります。また、Spectre のような分岐予測を悪用する攻撃に関しては、根本的な問題はメモリアクセスが遅いことにあります。メモリアクセスが遅いので、キャッシュや分岐予測という仕組みがあり、これら仕組みを悪用するのが Spectre 等だからです。
今後も、分岐予測を悪用する新しい攻撃が研究されると予想できます。また、GPU、NPU、AI 用のアクセラレータ等の新しいハードウェアへのサイドチャネル攻撃も増えてくると予想できます。このような攻撃を防ぐために、マイクロアーキテクチャによる対策は必要不可欠になってくると思われます。
私の感想です。この発表は、Rowhammer や Spectre 等のよく名前を聞く攻撃が、何故有名でその分野にどのようなインパクトを与えたのかという点が説明されている非常に有益な発表だと思います。今後サイドチャネル攻撃やマイクロアーキテクチャ周りを研究される方には、アカデミアや産業系に問わず必見の内容だと思います。また、自分のようなファームウェアセキュリテイを生業とする人間にとってもこの分野について考える事は重要だと思っています。ハードウェアに柔軟性をもたせるためのファームウェアという観点で、BIOS 等のシステムファームウェアからできる事は何かという点について考えさせられました。
おわりに
Black Hat USA での登壇という貴重な機会をいただけたことに感謝しています。 また、この研究は当社の他の研究者や大学の教授、その他外部の方等非常に多くの方々と議論を重ねて完成した物ですので、関係者の方々にも大変感謝しています。
今後もより深く UEFI セキュリティを突き詰めていこうと思います。また、私自身セキュリティ・キャンプで出会った方々や色々な企業・大学の共同研究者から様々な事を教わり現在に至るため、これを次に継げられるようなアウトプットにも力を入れていければと思います。
エンジニア募集
ＦＦＲＩセキュリティではサイバーセキュリティに関する興味関心を持つエンジニアを募集しています。 採用に関しては採用ページをご覧ください。
