【ITニュース解説】I built a Windows driver vuln hunter in a day — and learned why heuristics lie

Windowsの内部で動作するドライバーは、ハードウェアの制御やOSの根幹に関わる処理を行う、非常に重要なプログラムだ。そのため、もしドライバーにセキュリティ上の脆弱性があれば、システム全体が危険にさらされる可能性がある。こうしたドライバーの脆弱性を見つけることは、サイバーセキュリティ分野において常に重要な課題の一つとされている。

これまでの脆弱性発見手法の一つに「ファジング」があった。これは、ドライバーにランダムなデータを大量に送り込み、ドライバーがクラッシュ（予期せぬ停止）しないかを監視するというものだ。しかし、この方法では見つけにくいタイプの脆弱性が存在する。それは、ドライバーがクラッシュするのではなく、意図的に「設計された」脆弱性だ。例えば、OSの核となる部分が利用するメモリ領域であるカーネルメモリを、任意のユーザーが読み書きできてしまうようなドライバーは、クラッシュはしないが、悪用されればシステムを完全に制御されてしまう危険性がある。このような設計上の脆弱性は、ランダムな入力を与えるファジングではなかなか見つからず、一つ一つのドライバーを手動で解析するのは膨大な時間と手間がかかるのが現状だった。

そこで、ドライバーを実際に実行することなく、そのコードを解析する「静的解析」という手法を用いて脆弱性を見つける新しいツールが開発された。このツールは「driverhunter」と名付けられ、わずか一日で開発されたという。このツールの大きな特徴は、脆弱性のあるドライバーを実際に動かす必要がないため、Windowsのセキュリティソフトによって危険なコードとして検出・隔離される心配がなく、通常のWindows環境でも安全に実行できる点にある。

driverhunterは、Windowsドライバーファイルである.sysファイルを読み込み、それを実行せずに大きく三つの処理を行う。

一つ目は、「インポート関数と文字列の解析」だ。Windowsプログラムは、他のライブラリやOSの機能（API）を呼び出すことで動作する。これらのAPIは、プログラムが起動する際に「インポートテーブル」という場所にリストアップされる。driverhunterは、まずこのインポートテーブルを解析し、MmCopyVirtualMemoryのような、カーネルメモリの操作に関わる危険性の高いAPIが使われていないかを確認する。さらに、インポートテーブルには直接現れないが、プログラムの内部で動的に解決されて呼び出されるAPIも存在する。例えば、MmGetSystemRoutineAddressという関数を使ってAPIのアドレスを後から取得するようなケースだ。このような動的に呼び出されるAPIは、インポートテーブルには載らないものの、そのAPI名が文字列としてプログラムのバイナリデータ内に残されていることが多い。そのため、driverhunterはバイナリデータ内のASCII文字列もくまなくスキャンし、危険なAPI名がないかを検出する。

二つ目は、「IOCTL（Input/Output Control）の抽出」だ。IOCTLとは、アプリケーションがドライバーに対して特定の操作を要求するためのコマンドだ。例えば、デバイスからデータを読み込む、設定を変更するといった指示をドライバーに送る際に使われる。driverhunterは、ドライバーの実行コードが格納されている.textセクションを逆アセンブル（機械語を人間が読めるアセンブリ言語に変換）し、IOCTLコードを比較する命令（cmp reg, imm）を見つけ出す。これにより、どのようなIOCTLコードがドライバーで処理されているかを把握する。特に注目するのは「METHOD_NEITHER」と呼ばれるIOCTLのデータ転送方式だ。この方式は、ユーザーアプリケーションとドライバーの間でデータをやり取りする際に、ユーザーが指定したメモリ領域をドライバーが直接利用するため、細心の注意が必要となる。もしこのMETHOD_NEITHER方式のIOCTLで、ProbeForReadやProbeForWriteといった、ユーザーから渡されたメモリ領域が本当に読み書き可能で安全な領域であるかを確認する処理がドライバーの中に存在しない場合、driverhunterはこれを危険な兆候としてフラグを立てる。これらの保護処理がないと、ドライバーが悪意のあるユーザーによってOSの重要なメモリ領域を不正に操作される危険性があるからだ。

三つ目は、「スコアリング」だ。driverhunterが検出した危険なAPIの使用や、METHOD_NEITHER IOCTLにおける保護処理の欠如といった要素それぞれに、危険度に応じた重み付けを行い、点数（スコア）を計算する。例えば、保護処理のないMETHOD_NEITHER IOCTLは危険度が高いため、追加のボーナス点が加算される。最終的に、合計スコアに基づいてドライバーの全体的な危険度をCRITICAL（致命的）、HIGH（高）、MEDIUM（中）、LOW（低）のいずれかに分類し、ユーザーに提示する。

このツールの有効性を示すデモンストレーションとして、二つの事例が挙げられている。一つは「Blackbone」という、悪用を目的としたドライバーの解析だ。driverhunterはこれを解析するとすぐに、MmCopyVirtualMemoryなどの危険なAPIが多用されていることを検出し、最高ランクのCRITICALと判定した。このドライバーは、ユーザーが指定したプロセスIDとメモリアドレスに対して、検証なしでカーネルメモリの読み書きを可能にする、まさに「設計された」脆弱性を持っていた。driverhunterは、この危険性をわずか一秒足らずで見つけ出したのだ。

もう一つのデモンストレーションは、「WinDivert」という、正規のネットワークドライバーの解析だ。初期バージョンのdriverhunterでこれを解析したところ、MmMapLockedPagesSpecifyCacheというAPIが使われているという理由でHIGHという危険度判定が出されてしまった。しかし、このAPIは実際には数多くの安全なドライバーでも、その内部でメモリを効率的に扱うために広く利用されているものだ。つまり、このHIGH判定は「誤検知（False Positive）」だった。この事例から、「単に危険そうなAPIをリストアップして点数を加算する」という単純な手法では、不正確な結果を招き、ツールの信頼性を損なうことが明らかになった。

この教訓を受けて、driverhunterは「スコアリング」の仕組みを改善した。具体的には、検出された各危険な要素に対して、その危険度や悪用される可能性に応じた「重み付け」を行うようにしたのだ。例えば、MmCopyVirtualMemoryはユーザーが意図的に悪用できるよう設計されているケースが多いことから、高い重み（3点）が与えられた。一方、MmMapLockedPagesSpecifyCacheは安全な用途でも広く使われるため、低い重み（1点）に設定された。この改善により、Blackboneドライバーは引き続きCRITICAL（10点）と正しく評価される一方で、WinDivertドライバーはLOW（2点）と、その実態に合った評価が下されるようになった。このように、単に検出数を数えるのではなく、シグナル（危険な兆候）に重み付けをすることで、ツールはより信頼性の高いものへと進化したのだ。誤検知が多いツールは、ユーザーに「どうせまた間違いだろう」と思わせてしまい、肝心な危険信号を見逃す原因となるため、このようなチューニングは非常に重要である。

もちろん、このdriverhunterツールも完璧ではない。これはあくまで「トリアージ」（優先順位付け）を行うためのツールであり、検出されたものが「確実に悪用可能である」という証明をするものではない。例えば、CRITICALという評価が出た場合でも、それは「まずここを詳しく調べてみるべきだ」という優先順位を示すものであって、すぐに脆弱性として報告できるわけではない。このツールはデータがどのように流れていくかを追跡する「データフロー解析」までは行わないため、ユーザーから提供された不正なデータが実際に危険なAPIに到達し、悪用される可能性があるのかどうかまでは判断できない。この最終的な判断には、やはり人間による手動のリバースエンジニアリング（プログラムの動作を詳細に解析すること）が必要となる。また、IOCTLの検出についても、cmp命令を使ったシンプルな比較処理以外に、ハッシュテーブルやスイッチ文などを用いた複雑なディスパッチ（処理の振り分け）方法が使われている場合、それらのIOCTLを見逃してしまう可能性も指摘されている。

しかし、大量に存在する署名済みのWindowsドライバーの中から、手動解析の時間と労力をかける価値のある「掘り出し物」を効率的に探し出す「最初のフィルター」として、このdriverhunterは非常に強力なツールであることは間違いない。開発者の意図通り、このツールは調査すべきドライバーを正確に指し示し、問題のないドライバーについては静かに見過ごすことで、セキュリティ研究者の作業を大幅に効率化する。このツールのコードは公開されており、比較的少ない依存ライブラリで動作するため、誰でも試すことができる。任意の.sysファイルを指定して解析させ、その結果が出たら、古くからの手法である手動のリバースエンジニアリングで、本当にその評価が正しいのかを検証してみるのも良いだろう。このツールは、「このドライバーは危険かもしれない」という初期の示唆を与える第一歩であり、そこから「このIOCTLとこの構造体が脆弱性の具体的な証拠である」という詳細な発見へと繋げるための重要な橋渡しとなるのだ。