マイクロソフトシステムレベル0day脆弱性の分析と利用

はじめに

最近、Microsoftのセキュリティパッチがハッカーに利用されているwin32k特権昇格の脆弱性を修正しました。この脆弱性は主に初期のWindowsシステムバージョンに影響を及ぼし、Windows 11には無効のようです。この記事では、現在の新しい防護手段が進化している状況の中で、攻撃者がこの種の脆弱性をどのように利用し続ける可能性があるかを深く分析します。私たちの分析環境はWindows Server 2016です。

! Numen独占:Microsoft 0-day Vulnerability Can Knock Out Web3 Cards at the System + Physical Level

脆弱性の背景

0day 脆弱性は、未公開で未修正のセキュリティ脆弱性を指し、金融市場における T+0 取引の概念に似ています。この種の脆弱性が悪用されると、甚大な被害をもたらすことがよくあります。今回発見された Windows システムレベルの 0day 脆弱性は、攻撃者にシステムの完全な制御権を与えることができます。

攻撃者に制御されたシステムの結果は深刻であり、個人情報の漏洩、システムのクラッシュ、データの喪失、財産の損失、悪意のあるプログラムの埋め込みなどが含まれます。暗号通貨ユーザーにとって、秘密鍵が盗まれる可能性があり、デジタル資産が移転されることがあります。より広範囲に見ると、この脆弱性はWeb2インフラストラクチャに基づくWeb3エコシステム全体に影響を与える可能性があります。

! Numen独占:Microsoftの0日間の脆弱性は、システム+物理レベルでWeb3ゲームをダウンさせる可能性があります

パッチ分析

パッチコードを分析すると、問題はオブジェクトの参照カウントが何度も処理されていることにあるようです。以前のソースコードのコメントを確認すると、以前のコードはウィンドウオブジェクトのみをロックし、ウィンドウ内のメニューオブジェクトをロックしていなかったため、メニューオブジェクトが誤って参照される可能性があります。

! Numen独占:Microsoftの0日間の脆弱性は、システム+物理レベルでWeb3カードをノックアウトすることができます

脆弱性の検証

脆弱性関数のコンテキストを分析したところ、xxxEnableMenuItem() に渡されるメニューは通常、上位関数でロックされていることがわかりました。それでは、具体的にどのメニューオブジェクトを保護すべきでしょうか？さらに、xxxEnableMenuItem におけるメニューオブジェクトの処理を分析した結果、MenuItemState 関数が返すメニューには2つの可能性があることがわかりました：ウィンドウのメインメニューまたはサブメニュー(、そしてサブサブメニュー)を含みます。

脆弱性を検証するために、私たちは特別な4層のメニュー構造を構築し、xxxEnableMenuItem関数内の検出を回避するための特定の条件を設定しました。xxxRedrawTitleがユーザー層を返す際に、メニューCとBの参照関係を削除し、メニューCを正常に解放しました。最後に、カーネル内のxxxEnableMenuItem関数がxxxRedrawTitle関数に戻るとき、参照されたメニューCオブジェクトは無効になっています。

! Numen独占:Microsoftの0日間の脆弱性は、システム+物理レベルでWeb3ゲームをダウンさせる可能性があります

エクスプロイト

全体的な考え方

利用方法を決定する前に、通常は理論分析を行い、実行不可能な方法に時間を無駄にするのを避けます。今回の脆弱性の利用は、主に二つの方向を考慮しています:

1. シェルコードを実行する: 以前の類似の脆弱性を参考にしていますが、高バージョンの Windows では解決が難しい問題に直面する可能性があります。

2. 読み書き原語を利用してトークンを修正する: 最近の2年間でも公開された参考事例がある。我々は、UAFメモリが再利用される際に最初にcbwndextraを特大値として制御する方法に重点を置く必要がある。

したがって、私たちは全体の利用プロセスを二つの部分に分けます: UAF脆弱性を利用してcbwndextra値を制御する方法と、その値を制御した後に安定した読み書き原語を実現する方法です。

! Numen独占:Microsoftの0日の脆弱性は、システム+物理レベルでWeb3カードをノックアウトすることができます

初回データ書き込み

脆弱性が発生した後、システムが即座にクラッシュするわけではありません。制御されたメモリのウィンドウオブジェクトデータの誤使用は、主に xxxEnableMenuItem 関数の MNGetPopupFromMenu() および xxxMNUpdateShownMenu() において発生します。

私たちは、WNDClassというウィンドウクラスのウィンドウ名オブジェクトを使用して、解放されたメニューオブジェクトのメモリを占有します。重要なのは、私たちが構築できるアドレス構造の中で、たとえ1バイトだけでも任意のデータを書き込むことができる位置を見つけることです。

最終的に、私たちは xxxRedrawWindow 関数の中で2つの実行可能なソリューションを見つけました。いくつかの制約要因を考慮して、フラグ AND 2 操作に依存するソリューションを選択し、ウィンドウオブジェクトの cb-extra ではなく HWNDClass の cb-extra に書き込むことに決めました。

! Numen独占:Microsoft 0-day Vulnerability Can Knock Web3 Cards at the System + Physical Level

安定したメモリ配置

私たちは、少なくとも連続した3つの0x250バイトのHWNDオブジェクトのメモリレイアウトを設計しました。中間オブジェクトを解放し、0x250バイトのHWNDClassオブジェクトを占有します。前のHWNDオブジェクトの尾部データは、xxxRedrawWindowフラグを介して検証され、次のHWNDオブジェクトのメニューオブジェクトとHWNDClassオブジェクトが最終的な読み書き原語のメディアとして機能します。

ウィンドウオブジェクトとHWNDClassオブジェクトのサイズが一致するように努め、ウィンドウオブジェクトの拡張データが十分に大きいことを確認します。ヒープメモリに漏れたカーネルハンドルのアドレスを通じて、要求されたウィンドウオブジェクトが期待通りの順序で配置されているかどうかを正確に判断できます。

! Numen独占:Microsoftの0日間の脆弱性は、システム+物理レベルでWeb3カードをノックすることができます

読み取り/書き込みプリミティブの実装

任意の原語の読み取りには GetMenuBarInfo() を使用します。任意の原語の書き込みには SetClassLongPtr() を使用します。TOKEN の書き込み操作が第二のウィンドウのクラスオブジェクトに依存する以外は、他の書き込みは最初のウィンドウオブジェクトのクラスオブジェクトを使用してオフセットを利用して実現されます。

! Numen独占:Microsoft 0-day Vulnerability Can Knock Web3 Cards on the System + Physical Level

まとめ

1. win32kの脆弱性は長い間存在していますが、マイクロソフトはRustを使用して関連するカーネルコードを再構築しており、今後の新しいシステムではこのような脆弱性を防ぐことができるかもしれません。

2. この脆弱性の悪用プロセスはそれほど難しくなく、主な難点は最初の書き込みをどのように制御するかです。脆弱性は依然としてデスクトップヒープハンドルアドレスの漏洩に大きく依存しており、これは古いシステムにとって依然として安全上のリスクです。

3. この脆弱性の発見は、より洗練されたコードカバレッジ検出のおかげかもしれません。システムAPIがターゲット関数の実行パスが最も深い脆弱性ポイントに達し、ウィンドウオブジェクトが多重ネスト参照状態にある場合、ファズテストがこの脆弱性を発見する可能性があります。

4. 脆弱性の悪用検出については、脆弱性を引き起こす関数の重要なポイントに注目するだけでなく、異常なメモリレイアウトやウィンドウまたはウィンドウクラスの追加データへの非常規オフセットの読み書きにも注目すべきです。これにより、同種の脆弱性を発見するのに役立つ可能性があります。