なぜジャンクションが機能しなくなったのか: Windowsのリダイレクトにおける信頼の軽減策を探る

This post is also available in: English (英語)

概要

近年、特権昇格型の脆弱性に分類される代表的な脆弱性の1つがファイルシステムリダイレクト攻撃の脆弱性です。このクラスの脆弱性は、非特権ユーザーによる書き込みが可能なファイルやディレクトリを、特権を持つコンポーネント(Windowsサービスなど)が操作する、という点を突くものです。ハードリンクやジャンクションなど異なる種類のファイルシステムリンクを使い分けることで、攻撃者が特権コンポーネントを騙し、意図しないファイルを操作できるようになります。こうした攻撃の最終目標の多くは、攻撃者の提供する実行ファイル(DLLやスクリプトなど)をディスクに書き込み、システムパーミッションで実行させることにあります。

こうしたエクスプロイトの例は筆者によるBlueHat IL 2020での講演やCVE-2020-0787 Metasploitモジュールなどで確認できます。

本稿ではジャンクションについて説明し、脅威アクターがファイルシステムリダイレクト攻撃でジャンクションを使用する方法と、軽減策の開発について解説します。

パロアルトネットワークスのお客様は、Cortex XDRにより、ファイルシステムリダイレクト攻撃をねらうさまざまな種類のエクスプロイトから保護されています。

目次

ジャンクションとは何か
リダイレクトの信頼の軽減策
リダイレクトの信頼の仕組み
軽減策は有効になっているか
結論

ジャンクションとは何か

ジャンクションはNTファイルシステム(NTFS)の機能の1つで、あるディレクトリを別のディレクトリにリンクさせられる機能です。ジャンクションはデフォルトで利用されていて、たとえばC:\Documents and Settingsなどのディレクトリもジャンクションでリンクされています。

Microsoftは2019年に「ハードリンクの作成者がリンク先への書き込みアクセス権を持つこと」を要求する軽減策を導入しました。それ以降はジャンクションがファイルシステムリダイレクト攻撃の悪用手段となっています。

よくある脆弱性のパターンはたとえば次のようなものです。

• ある特権サービスがリモートプロシージャコール(RPC)などのプロセス間通信(IPC)の仕組みを通じてトリガーできる機能を公開しているが、その機能が低い権限レベルで実行されているユーザーからもトリガーされうる。
• その機能はグローバルに書き込み可能なディレクトリ下のファイルに対する操作(たとえばそのファイルへのデータ書き込み)を行うが、その操作が偽装なしで行われる(つまりそのシステムサービスの権限で行われる)。

こうした問題をエクスプロイトする場合、攻撃者はまずそのディレクトリとターゲット(通常、C:\Windowsまたはそのサブディレクトリの1つ)との間にジャンクションを作成します。次に攻撃者はRPCの呼び出しをトリガーしてジャンクションをたどり、システムのDLLファイルを上書きします。最後に悪意のあるDLLが何らかのサービスによってロードされ、攻撃者が提供するコードがシステムのパーミッションで実行されるようになります。

リダイレクトの信頼の軽減策

BlueHat IL 2020でDavid Weston氏が講演「Keeping Windows Secure」で紹介したこのクラスの脆弱性に対し、Microsoftは軽減策のリリースを発表しました。この軽減策は最近のWindows 10ビルドで登場したばかりなので、リバースエンジニアリングしてその仕組みを探りました。

リダイレクトの信頼の仕組み

軽減策はごくシンプルで、マイクロソフトのBlueHat講演で発表されたガイドラインに従ったものです。その目的は、特権を持たず整合性レベルMediumのアクターが作成したジャンクションをマーキングして特権プロセスがそのジャンクションをたどらないようにすることです。

ジャンクションが作成されるたび、ntfs.sysはnt!IoComputeRedirectionTrustLevelを呼び出して、呼び出し元の信頼(trust)レベルを計算します。このレベルは呼び出し元トークン(あれば偽装トークン、あるいはプライマリトークン)に基づいて決定されます。その後、計算した値をそのジャンクションのファイル制御ブロックの標準情報に設定します。

現時点の信頼レベルは2段階のみです。

• レベル1: 整合性レベルがMediumのアクターによって作成されたジャンクションであることを示す
• レベル2: 特権アクター(Administrator、System、ないしKernel)に作成されたジャンクションであることを示す

軽減策を完全なものにするため、ジャンクションは信頼レベルの検証がすんでからたどられます。これは軽減策が有効である場合にのみ実行されますが、これを制御するのが新しいプロセス軽減策ポリシーProcessRedirectionTrustPolicyです。このポリシーには、監査(audit)モードと実施(enforce)モードの2つのモードがあります。

SetProcessMitigationPolicyに有効な引数を指定して呼び出すと、これが最終的にnt!PspSetRedirectionTrustPolicyを呼び出します。これによりプロセスのプライマリトークン上の軽減策が有効になります。

最終的にntfs.sysがジャンクションのリダイレクトのさいにnt!IoCheckRedirectionTrustLevelを使って呼び出し元トークンに対する検証を行います。これは特権サービスが自身のシステム特権での操作を行う場合に、信頼されていないジャンクションはたどらない、ということを意味します。リダイレクトに失敗すると、エラー0xc00004be(The path cannot be traversed because it contains untrusted mount point パスをトラバースできません。信頼されていないマウントポイントが含まれています)が表示されます。

軽減策は有効になっているか

軽減策をリバースエンジニアリングしてみて、現在のWindowsビルドでこれが有効になっているか、なっているとすればどのモードが有効なのかを確認したくなりました。そこで、実行中の全プロセスの状態を照会するサンプルのアプリを(GetProcessMitigationPolicyを使って)作成しました。この結果、現時点では、数種類のサービスで監査モードの軽減策が有効になっているのみであることがわかりました。できれば近いうちにMicrosoftが実施(enforce)モードで軽減策を有効にしてくれるように願っています。

結論

ここ数年Microsoftはファイルシステムリダイレクト攻撃に対処するべく数々の軽減策をリリースしてきました。その上で、まだ不具合が悪用されてしまうようなスキや条件を見つけ出し、その有効性を評価することが重要です。

パロアルトネットワークスのCortex XDRは、さまざまなファイルシステムリダイレクト攻撃用のエクスプロイトをブロックする保護機能を多数備えており、実際の攻撃を防ぐことを実証済みです。