Windowsドライバー署名の迂回によりカーネルルートキットをインストール可能な恐れ
(bleepingcomputer.com)- 表面上は最新パッチが適用された Windows でも、Windows Update プロセスが掌握されると、古いカーネルコンポーネントへ戻され、Driver Signature Enforcement の迂回やカーネルルートキットの配布につながる可能性がある
- SafeBreach の研究者 Alon Leviev は BlackHat と DEFCON でダウングレード／バージョンロールバック攻撃を実演しており、Windows Update takeover はまだ完全にはパッチ適用されていない状態で残っている
- 管理者権限を持つ攻撃者は、最新の Windows 11 でも ci.dll を未パッチのバージョンに差し替え、署名されていないカーネルドライバーのロードを可能にできる
- Virtualization-based Security は UEFI ロックとレジストリ設定に依存するため、Mandatory フラグがない構成では、レジストリの変更や重要ファイルの差し替えが迂回経路になり得る
- Microsoft は古い VBS システムファイルを廃止するセキュリティ更新プログラムを開発中だが、影響を受けるバージョンの調査、互換性テスト、回帰防止のため、公開時期は不明確
最新パッチ状態を無力化するダウングレード攻撃
- 攻撃者は Windows Update プロセスを制御し、最新状態に見えるシステムへ古い脆弱なコンポーネントを再投入できる
- OS は依然として完全にパッチ適用済みに見えるが、実際にはすでに修正済みの脆弱性に再びさらされる
- ダウングレード対象には DLL、ドライバー、NT kernel などが含まれる
- Alon Leviev は Windows Downdate ツールを公開し、カスタムダウングレードを作成できることを示した
Driver Signature Enforcement の迂回とルートキットのリスク
- Leviev は、カーネルセキュリティが強化された後でも Driver Signature Enforcement(DSE) の迂回が可能であることを実演した
- DSE の迂回に成功すると、攻撃者は署名されていないカーネルドライバーをロードできる
- このようなドライバーは、セキュリティ制御を無効化し、侵害検知を困難にするルートキット型マルウェアの配布に悪用される可能性がある
- Leviev は自身の手法を
"ItsNotASecurityBoundary" DSE bypassと呼んでいる- この手法は ItsNotASecurityBoundary エクスプロイトをダウングレードする形を取る
- このエクスプロイトは、Elastic の Gabriel Landau が特定した Windows の**偽のファイル不変性（false file immutability）**脆弱性群を利用し、カーネル権限での任意コード実行を可能にする
ci.dll の差し替えと再起動条件
- 新たな研究で Leviev は、管理者権限を持つ攻撃者が Windows Update プロセスを悪用し、完全に更新済みの Windows 11 でも DSE 保護を迂回できることを示した
- 核心は、DSE を強制する ci.dll を、ドライバー署名を無視する未パッチのバージョンに差し替える手法である
- コンポーネントが脆弱なバージョンへダウングレードされた後は、通常の更新プロセスと同様にシステムの再起動が必要になる
- Leviev は、完全にパッチ適用済みの Windows 11 23H2 システムで DSE パッチをダウングレードで元に戻した後、そのコンポーネントを悪用するデモを公開した
VBS 設定が弱い場合に開く迂回経路
- Leviev は Microsoft の Virtualization-based Security(VBS) を無効化または迂回する方法も扱っている
- VBS は Windows の必須リソースとセキュリティ資産を保護するために、隔離された環境を作る
- 保護対象には、セキュアカーネルのコード整合性メカニズムである skci.dll と、認証済みユーザーの資格情報が含まれる
- VBS は一般に、UEFI ロックやレジストリ構成といった保護機構に依存している
- VBS が最大セキュリティ設定である “Mandatory” flag で構成されていない場合、標的のレジストリキーを変更することで無効化される可能性がある
- VBS が部分的にしか有効化されていない場合、SecureKernel.exe のような重要な VBS ファイルを破損したバージョンに差し替え、VBS の動作を妨害できる
- この状態は、“ItsNotASecurityBoundary” の迂回と ci.dll 差し替えにつながる経路を開く可能性がある
Microsoft の対応と残る空白
- BlackHat と DEFCON で公開されたダウングレード攻撃に使われた CVE-2024-21302 と CVE-2024-38202 は対処されたが、Windows Update takeover の問題はまだ残っている
- Microsoft はこの問題が定義済みのセキュリティ境界を越えるものではないと見なし、管理者権限でカーネルコード実行を得ることはセキュリティ境界の侵害ではないと判断した
- Leviev は、Microsoft が問題を修正するまで、セキュリティソリューションがダウングレード攻撃を監視・検知すべきだと強調している
- Microsoft は、このリスクを防ぐための緩和策を積極的に開発中だと述べている
- 同社は、古く未パッチの VBS システムファイルを廃止するセキュリティ更新プログラムを開発中である
- このプロセスには、影響を受けるすべてのバージョンの調査、更新プログラムの開発、互換性テストが含まれる
- 顧客保護と運用停止の最小化のため、統合失敗や回帰を避ける必要がある
- 問題の複雑さから、更新プログラムの提供時期は不明確である
- 10月27日の更新で、攻撃には管理者権限が必要である点が明確化され、Microsoft が緩和措置を取らないという混乱を減らすための情報が追加された
1件のコメント
Hacker News のコメント
MS は UAC はセキュリティ境界ではないと言っているが、これは一部のユーザーが管理者権限へ昇格する問題を指している。
ところが今回のように管理者からカーネルへ進むこともセキュリティ境界ではないと言い、その一方で ドライバー署名の強制 はセキュリティ機能だと言っている。
ここではまさにその機能が回避されているのに、セキュリティ境界を越えたわけではないと言うのだから、筋が通るように説明してほしい。
UAC はすでに管理者グループに属しているユーザーのためのものであって、「一部のユーザーが管理者になる」機能ではない。
セキュリティ境界は管理者ユーザーの周囲ではなく、標準ユーザー の周囲にある。
気に入らないかもしれないが、セキュリティ境界が欲しいならユーザーを Administrators グループに入れなければよい。
意見の衝突にはたいてい、定義の不一致と価値体系の不一致があると思う。
この場合 Microsoft はこの問題を小さく見せることに価値を置いており、それが最優先事項なら、彼らの判断はその基準では一貫しているように見えるかもしれない。
定義の不一致は比較的解決しやすい。たとえばソフトウェアシステム設計について全員がデザインパターン用語で話していても、各自が A を A′ や A″ と違って理解していると、大きな混乱が起こりうる。
企業が管理するオープンソースソフトウェアでも同じだ。
本当の疑問は、なぜ人々が知的エネルギーをデスクトップ Linux の改善に使わず、Microsoft のために無料でセキュリティ研究をしているのかということだ。
UAC と sudo はどちらも OS レベルのクッキー同意ダイアログに近く、3つともなくしたほうがよいと思う。
UAC/sudo のようなユーザーベースの権限昇格方式は諦めて、Android や iOS のようにユーザーではなく アプリをサンドボックス化 すべきだ。
Windows と Linux のどちらでも、通常権限のローカルアカウントは実際にはほぼ root 相当の権限 のように振る舞うという点も興味深い。
Linux ではシステム関連の作業の前に sudo を付けるよう訓練され、Windows では UAC プロンプトをクリックして通過するよう訓練される。
sudo がパスワードの入力ミス以外の理由で誰かに「だめだ」と言ったのは最後にいつだっただろう、と思う。
UAC はシステムが管理する UI である一方、sudo は単なるプログラムなので、攻撃者が悪意あるシェルエイリアスで sudo を置き換えてパスワードを盗めるという点では、UAC のほうが少しはましだ。
デフォルト設定では sudo と UAC をなくし、root と主ユーザーのローカルアカウントの間に強固なセキュリティ境界があるふりをしないほうが、ユーザーにとっても便利で、実際のセキュリティ状態にも合っている。
ターミナルでも sudo の代わりに pkexec を使える。
任意のコマンドを root として実行するのではなく、アプリケーションは
org.freedesktop.udisks2.filesystem-mountのような事前定義された動作を使え、アプリが何をしようとしているのかをローカライズされたメッセージでユーザーに示して、許可するかどうかを判断させられる。システム管理者は flatpak の更新のような特定の動作に認証を求めないようにしたり、逆に特定の動作を完全にブロックするよう設定したりもできる。
インストールを行ったユーザーがシステムを制御すべきだという前提があるのだと思う。そもそもインストールしないこともできたのだから。
sudo も UAC と同じく、人に「だめだ」と言うための装置ではない。どちらも、管理者が予期していない管理作業をしようとしたときに、人が「だめだ」と言えるようにするためのものだ。
管理者権限はないがそうした作業が必要な人は、管理者の承認を受ける必要がある。
1人用のシステムでないなら、マシンを設定する人が日常利用用の制限付きアカウントを作るべきだ。
root になることは頻繁にはなく、必要なときはたいてい複数の作業を続けて行うからだ。
sudo は会社所有・管理のコンピューターのようなマルチユーザーコンピューターで、管理者が一部のユーザーに制限された特権操作だけを許可したいときに有用だと思う。
root ではない別アカウントを常に使う主な理由は、セキュリティよりもミス防止だ。意図しないファイルを削除したり上書きしたりするのを避けるためだ。
だから、まれに役割を切り替えるためにパスワードを入力しなければならない程度なら、十分に正当化できると思う。
ただし「確認するには ctrl+alt+delete を押せ」というトリックはない。
Windows には、すべてをスクリプトで組む必要がないという利点がある。
望めばすべてのツールを
runas/System.Management.Automation.PSCredentialで包むこともできるが、ほとんどの場合その必要はない。カーネルがファイルを開くとき、開いているすべてのファイルハンドルを走査して衝突する 強制ロック を確認し、ファイル共有ルールを強制している一方で、衝突する権限を持つメモリマッピングは確認していない構造に見える。
ミスではあるが、修正は比較的単純に見える。
興味深いことに、Linux は強制ロックの最後の痕跡をちょうど取り除いたところだ。今ではロード済みの実行ファイルに書き込んでも EBUSY にはならない。
同じ機能が、ある OS ではセキュリティインフラの荷重を支える部分であり、別の OS では消すべきレガシーの残滓であるという点が興味深い。
セキュリティ専門家ではなく基本的なことだけ理解しているが、何か概念モデルを見落としている気がする
Windows はなぜこんなにハックされやすいのか不思議だ
Windows は金になる標的、とくに企業環境で最も広く導入されているデスクトップ OS なので、侵入のために多くの時間と投資が注ぎ込まれる
本当に安全なコンピューティングプラットフォームを作るための投資が十分になされていなかった
理想的なセキュリティプラットフォームは、fdroid のように公開検証可能なインフラで再現可能なビルドを提供し、信頼できないすべてのアプリケーションをサンドボックス内で仮想化し、最小権限モデルを実装すべきだ
現状は最悪のセキュリティ状態だ。CPU の ME、UEFI コンポーネント、OS のサードパーティドライバに至るまで、すべてのリングで正体不明で、おそらく十分にテストされていない安全でないコードが実行されている
SeL4 は完全に検証済みのカーネルを持っているが、まだ仮想化はしていない
Windows マルウェアのかなりの部分は、どこかの時点で脆弱なサードパーティ製カーネルドライバに依存している
逆に Linux ではサードパーティのカーネルモジュールは珍しく、好ましくないものと見なされ、macOS ではそもそも禁止されている
そして、昇格した権限で何でも実行するようユーザーを説得するのがあまりにも簡単だ
2022年に CERT アナリストの Will Dormann がなぜなのか尋ねて、ようやく対処された
今は定期的に更新されているが、本当にあきれる https://www.bleepingcomputer.com/news/microsoft/microsoft-fi...
この件については、Microsoft 側の立場にある程度同意する
管理者はコンピュータに任意のことをできるし、今さらの話ではない
深刻度を高めるような細かな違いがあるのかは分からない
Raymond Chen がこの種の攻撃を整理した記事も参考になる
https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
誰かがすでにシステム上の任意の DLL を置き換えられるなら、この「エクスプロイト」が動作するための前提条件はすでに満たされており、その時点ですべて終わっている
ドライバ署名を回避できる能力は、心配事の中でもおそらくかなり小さい部類に入るだろう
攻撃が怪しいほど単純に見える
更新プロセスをだまして、既知の脆弱性がある古いカーネルコンポーネントをインストールさせる方式だ
専門家でなくても、Microsoft はすでにこういうことを想定して、ブロックリストや廃止メカニズムのようなものを持っているべきではないかと思うので気になる
根本原因が OS の設計問題なのか、それとも壊れた、あるいは悪いハッシュを正しい場所に記録できなかったプロセス上の失敗なのかが重要だ
後者ならはるかに直しやすいが、いつものように、少し取り繕ったセキュリティ告知は前者を主張しているように見える
デモがあるのに Microsoft が反論しているというのが信じがたい
その Vimeo アカウントには他のセキュリティ発見もたくさんある。たとえば WhatsApp が Python スクリプトを実行するものもあったが、本物なのか詐欺なのか気になる
「管理者プロセスとユーザーは Windows の信頼コンピューティング基盤（TCB）に属すると見なされるため、カーネル境界から強く分離されない」という基準がある [0]
最近の別の事例もある
https://arstechnica.com/security/2024/03/hackers-exploited-w...
[0] https://www.microsoft.com/en-us/msrc/windows-security-servic...
Windows で Microsoft が初めてドライバ署名を要求したときに [1] で皆が経験した苦労を思い出す
[2] 向けのディープパケットインスペクション用ドライバを作っていたが、初見では Apple Store のアプリ承認よりも厳しい手続きのように見え、ドキュメントもまったく明確ではなかった
企業が Microsoft の要件を満たすために注ぎ込んだリソースを考えると、このような形で悪用されたというのは大きな後退のように感じる
脆弱性は常に存在するものだが、誰かがもっと早くこれを見つけていたなら安心できただろう
発見した Alon Leviev と SafeBreach には拍手を送りたい
[1] https://www.nektra.com/
[2] https://www.verizon.com/business/en-nl/products/security/man...
「管理者としてカーネルコード実行を得られる」というのは、結局のところ root ユーザーが rootkit をインストールできるという、ありふれた話
かっこいい名前を付けるのを忘れてはいけない。ああ、すでに研究者が Windows Downdate というツールを公開している
0xF 分間の名声は確保できたのだから、よくやったと言える
ユーザーアカウントも OS 内のオブジェクトにすぎず、スーパーユーザーアカウントを制限しつつ、すべてのユーザーアカウントに特定のルールを強制する OS を設計することもできる
たとえば管理者アカウントが侵害された場合でも、TPM のように特定の秘密を保護したり、管理者が誤ってシステムを起動不能な状態に壊してしまうのを防いだりする正当な理由があり得る
より議論を呼ぶ目的としては、DRM の強制もある
Windows で Microsoft がやろうとしているのも、まさにこれ。OS が、管理者アカウントによるカーネルへの干渉や rootkit のインストールを防ごうとしている
この議論では、OS 内の管理者ユーザーアカウントと、物理的・ハードウェア的なアクセス権を持つ「管理者」である人間を区別することが常に重要
0xFと書いているのが気になる間違いではないが、妙な選択なので好奇心をそそられる。単なるスタイルだったのか気になる
Windows を使わなければならないときは、いつもそのコンピューターはすでに 侵害されている と仮定している