はじめに
Bring Your Own Vulnerable Driver(BYOVD)は、脅威アクターがマルウェアと一緒に既知の脆弱な署名付きドライバーを持ち込み、それをカーネルにロードし、それを悪用して、他の方法では実行できないカーネル内で何らかのアクションを実行するという、ますます人気のある攻撃者手法です。 カーネルアクセスを達成した後、セキュリティソフトウェアを改ざんまたは無効にしたり、アクセスできない資格情報をダンプしたり、オペレーティングシステムの動作を変更してその存在を隠したりする可能性があります。 Joe Desimone と私は、Black Hat USA 2018 で、 他のカーネルモードの脅威の中でも特に、これについて詳しく説明します。 BYOVDは、10年以上にわたって高度な脅威アクターによって採用されており、ランサムウェアやコモディティマルウェアでますます一般的になっています。
Driver Signing Enforcement (DSE) は、 2007 年に Windows Vista x64 によって最初に導入されましたが、Microsoft が初めて管理者の力を制限しようと試みたものでした。 DSEの導入により、管理者はコードをカーネルに即座に読み込むことがなくなりました。 管理者の制限は、 Boot Guard、 Secure Boot、 および Trusted Boot の展開により、以前は独自のブート ローダー/ブートキットをインストールすることができた管理者マルウェアからブート チェーンを保護するとともに、時間の経過とともに拡大しました。
管理者の力をさらに制限するために、Microsoftは最近、Windows 11 22H2からデフォルトで脆弱なドライバーブロックリストを展開しました。これは正しい方向への動きであり、Windows 11 デフォルトでより安全になります。 残念ながら、ブロックリストのデプロイモデルは、新しい脅威に適応するのに時間がかかる場合があり、通常は年に1〜2回しか更新が自動的にデプロイされません。 ユーザーは手動でブロックリストを更新できますが、そのような介入により、「デフォルトで安全」の領域から抜け出すことができます。
セキュリティ境界
修正する脆弱性を決定する際に、Microsoft Security Response Center (MSRC) は、次のように 定義 するセキュリティ境界の概念を使用します。
セキュリティ境界は、異なるレベルの信頼を持つセキュリティ・ドメインのコードとデータを論理的に分離します。 たとえば、カーネル モードとユーザー モードの分離は、従来の単純なセキュリティ境界です。
この定義に基づくと、ユーザーモードで実行されているマルウェアはカーネルメモリを変更できないはずだと考える傾向があるかもしれません。 結局のところ、境界は「単純」です。 論理的には、その境界の違反は、パッチやブロックリストの更新などの是正措置で対処する必要があります。
残念ながら、ここから状況は不透明になります。 この文書では、管理者からカーネルへの接続はセキュリティ境界ではないと後で述べられており、次のように説明されています。
管理プロセスとユーザーは、Windows の Trusted Computing Base (TCB) の一部と見なされるため、カーネル境界から分離された強力な [原文ママ] ではありません。
この時点で、私たちは一見相反する2つの視点を持っています。 一方で、MSRCは、admin-to-kernelは防御できない境界であり、修正する価値がないと述べています。 一方、Microsoftは、Driver Signing Enforcement、Secure Boot、Vulnerable Driver Blocklistなどのメカニズムを使用して、この境界を防御しようとしています。 防御が不完全であるため、MSRC では代わりに "多層防御セキュリティ機能" と呼んでいます。
同様に、MSRC では、管理者と PPL をセキュリティ境界とは見なさず、多層防御のセキュリティ機能として分類しています。 これについては、次のセクションで詳しく説明します。
この記事の残りの部分では、MSRC と Microsoft を別々に参照します。 MSRC は Microsoft の一部ですが、Microsoft は MSRC よりもはるかに大きなエンティティです。両者を同一視すべきではありません。
脆弱性の悪用
2022年9月、私はMSRCにVULN-074311を提出し、Windowsの2つの ゼロデイ 脆弱性(1つはadmin-to-PPLともう1つはPPL-to-kernel)を通知しました。 両方のエクスプロイトのソースコードを提供しました。 回答は、脆弱性を理解し、以下のとおりそれ以上の措置を講じることを拒否したことを簡潔に示しています。
この研究では、PPLバイパスを利用してカーネルコードを実行するマルチステップ攻撃について説明しています。 提案されたすべての攻撃は、実行するために管理者権限を必要とするため、報告された問題は即時の対応の基準を満たしていないことに注意してください。 これ以上の措置は期待しておらず、ケースの終結に向けて進めます。
この用語では、「サービス」とは「パッチ適用」を意味します。 彼らの応答は、前述のポリシーと、管理者とカーネルの境界の 歴史的な取り扱い と一致しています。 彼らの行動も一貫しており、 11 か月以上経ちますが、まだどちらの脆弱性にもパッチを適用していません。 マイクロソフトがカーネルメモリを変更できるドライバーをブロックする意思があるのに対し、MSRCは同じことをする可能性のある脆弱性をサービスする気がないのは興味深いと思います。
私がBlack Hat Asia 2023 の講演「 PPLdump Is Dead」を発表したとき。MSRCの報告から5か月後のTwitterで、Windows Defenderチームはすぐに詳細を知るために連絡を取りました。 MSRCは、 数億台のWindowsマシンを保護するためにPPLに依存している製品であるDefenderチームに、PPLバイパスについて伝えずにケースを解決したようです。 このような誤解が続くことは許されません。
ターンキーツーリング
EDRSandBlast は、脆弱なドライバーを武器にして AV および EDR ソフトウェアをバイパスするツールです。 カーネルメモリを変更して、AV & EDRによってインストールされたフックを削除し、システム上の悪意のあるアクティビティに対して一時的または恒久的にそれらを盲目にすることができます。
私がBlack Hat Asiaの講演で論じたように、MSRCは事実上、管理者からPPLおよび管理者からカーネルへの脆弱性に対処するつもりはなく、Microsoftを行動に駆り立てるためにGitHub上の ターンキーツール の存在が必要であることを示している。 これをきっかけに、管理者から PPL へのエクスプロイトである PPLFault と、管理者からカーネルへのエクスプロイト チェーンである GodFault を使いやすいツールとして GitHub でリリースすることになりました。 簡潔にするために、以下ではそれぞれ「PPL脆弱性」と「カーネル脆弱性」と呼びます。
この同じ「ターンキーツール」の精神で、既知の脆弱なドライバーをブロックすると同時に、管理者からカーネルへのエクスプロイトチェーンへのパッチ適用を拒否するという矛盾を強調するために、PPLFaultを統合したEDRSandBlastのバージョンを リリース して、脆弱なドライバーなしで同じ結果を示します。 ここで、WindowsDefenderドライバーを無効にしていることがわかります。これをリリースする私の目標は、MSRC が PPL とカーネルの両方の脆弱性をより緊急に扱うように動機付けることです。
緩和
私は、PPLFaultとGodFaultと一緒に 、PPL エクスプロイトを破るNoFaultと呼ばれる小さなカーネルドライバをリリースしました。 Windowsが修正されるまで、マルウェア対策ベンダーはこのコードを使用してPPLの脆弱性を軽減できます。 NoFaultの保護機能をElastic Endpoint/Defendの最新バージョンに組み込んでいますので、まだ8.9.0+にアップデートしていない場合はアップデートしてください。 包括的な修正の 1 つは、メモリ マネージャーが PPL に読み込まれるすべての実行可能イメージに対してページ ハッシュを強制することです。これは、完全に保護されたプロセスで 既に採用されている 機能です。
GodFaultは、カーネルの脆弱性を悪用した最初のツールではありません。 ANGRYORCHARD は、現在パッチが適用されている KnownDLLs PPL の脆弱性で最初に使用しました。 その後、PPLの脆弱性は修正されましたが、カーネルの脆弱性は修正されていません。 GodFaultのカーネルの脆弱性を簡単に再利用することができました-それはわずか 数行のコードです。 これにパッチが適用されていない場合、将来の PPL エクスプロイトはすぐにカーネルにチェーン可能になります。 NoFault は、必要な PPL コードの実行を防ぐことでカーネルのエクスプロイトチェーンを断ち切りますが、カーネルの脆弱性自体は修正しないことに注意してください。
議論
EDRSandBlastをドライバーレスにすることは、このようなエクスプロイトでできることの一例にすぎません。 Admin-to-Kernelエクスプロイトは、通常、ユーザーモードでは不可能なマルウェア機能の全メニューを有効にします。
- カーネル モード テレメトリ (プロセス、スレッド、オブジェクト マネージャー、ファイルシステム、レジストリ コールバックなど) を無効にします。 EDRSandBlast は、これらの一部を実行します。
- カーネル ETW ロガーを無効にする
- PPL マルウェア対策プロセスにマルウェアを終了または挿入する
- LSA RunAsPPL をバイパスして資格情報をダンプするか、Credential Guard を改ざんします
- PPL として実行されるシールドされた VM ワーカー プロセスのメモリの読み取り/書き込み
- マルウェア対策よりも高い特権でマルウェアを実行するため、スキャンしたり、ユーザー モードから終了したりすることはできません
- ルートキットの動作 (プロセス、ファイル、レジストリ キーの非表示など) を実装する
- 物理メモリへの完全な読み取り/書き込みアクセスを取得
このようなカーネル駆動型の機能は、多くの場合、BYOVDによって可能になりますが、 犯罪者は セキュリティ 製品を 無効化 して 劣化 させるために 定期的に 使用され 、人々や企業に損害を与えることができます。PPLとカーネルの脆弱性は、これらの同じ機能を可能にするため、MSRCは、脅威アクターがそれらを悪用した後ではなく、事前にそれらを処理する必要があります。
問題の難しさを過小評価したくはありません - 管理者からカーネルを守るのは難しく、新しいバイパスが見つかるたびに継続的な努力が必要になります。 それは解決されるのではなく、むしろ困難で進行中の軍拡競争です。 幸いなことに、Microsoftは最近、「もはや難しいことを避けない」という新しい哲学を採用しました(タイムスタンプ付きリンク)。 これらのタイプの脆弱性に対処することは、今日のWindowsセキュリティに影響を与える「難しいこと」であり、Microsoftは何かをすると同時に、 管理者のいない未来というビジョンに向かって進むことができます。 彼らは、一度に複数の問題に対処できる、賢い人々でいっぱいの資金力のある大規模な会社です。
まとめ
Microsoftは、管理者がカーネルを改ざんするのを防ぐために脆弱なドライバーブロックリストを作成しましたが、 11 か月以上前に報告された管理者からカーネルへのエクスプロイトチェーンについては何もしていません。 GodFault を介して EDRSandBlastから脆弱なドライバーの要件を削除する ことで、管理者からカーネルへのエクスプロイトが脆弱なドライバーと同じくらい危険であり、MSRCがそれらを真剣に受け止める必要があることを証明したいと考えています。Windows 11 の デフォルトのセキュリティの目標と 、脆弱なドライバー ブロックリストがデフォルトで有効になっているという事実を考えると、MSRC は PPL とカーネルのエクスプロイトに対する無関心のポリシーを再考する必要があります。