本記事は、Security Research & Defense のブログ “Triaging a DLL planting vulnerability” (2018 年 4 月 4 日 米国時間公開) を翻訳したものです。
ダイナミックリンク ライブラリ (DLL) の植え付け (バイナリの植え付け/ハイジャック/プリロード) の問題は数年に 1 度表面化する傾向があり、マイクロソフトがそのような報告にどう対応するかが明確でない場合があります。このブログでは、DLL の植え付けの問題をトリアージする際に検討される項目を明確にします。
アプリケーションが完全修飾パス名を指定せず、DLL を動的に読み込む場合、Dynamic-Link Library Search Order (英語情報) で説明されているように、Windows は特定の順番で適切に定義されたディレクトリ セットを探して、DLL の場所を特定しようとします。既定の SafeDllSearchMode で使用される検索順序は以下のとおりです:
- アプリケーションが読み込まれた場所のディレクトリ
- システム ディレクトリ。GetSystemDirectory 関数を使用しこのディレクトリのパスを取得します。
- 16 ビットのシステム ディレクトリ。このディレクトリのパスを取得する関数はありませんが、検索されます。
- Windows ディレクトリ。GetSystemDirectory 関数を使用しこのディレクトリのパスを取得します。
- 現在の作業ディレクトリ
- PATH 環境変数の一覧にあるディレクトリ。ただし、 App Paths レジストリ キーにより指定されたアプリケーションごとのパスは含まれません。 App Paths キーは DLL 検索パスを実行時には使用されません。
既定の DLL の検索順序は、以前のブログの 1 つ “Load Library Safely” でも記載しているように、さまざまなオプションにより変更できます。
アプリケーションにおける DLL の読み込みは、攻撃者が悪意のある DLL を、検索順序に基づき検索されるいずれかのディレクトリに植え付けることができ、植え付けられた DLL が攻撃者がアクセス権を持たない上位検索ディレクトリに見つからない場合、DLL の植え付けの脆弱性になります。たとえば、foo.dll を読み込むアプリケーションがあり、foo.dll がアプリケーション ディレクトリ、システム ディレクトリ、もしくは Windows ディレクトリに存在しない場合、攻撃者は現在の作業ディレクトリにアクセスできれば foo.dll を植え付けることができることになります。DLL の植え付けの脆弱性は攻撃者にとって便利でかつ作業量も少なく済み、DLL の読み込み時に DllMain() が直ちに呼ばれるためにコードの実行は非常に容易です。攻撃者は、アプリケーションが署名されていないバイナリを読み込むことを許可している場合、緩和策をバイパスすることに頭を悩ませる必要はありません。
悪意のある DLL が DLL 検索順序のどこに植え付けられるかによって、脆弱性は大きく以下の 3 つのカテゴリのいずれかに属します。
- アプリケーション ディレクトリにおける DLL の植え付け
- 現在の作業ディレクトリ (CWD) における DLL の植え付け
- PATH ディレクトリにおける DLL における植え付け
上記のカテゴリにより私たちの対応が決まります。では私たちが各カテゴリをどのようにトリアージするか、これらカテゴリを見ていきましょう。
アプリケーション ディレクトリにおける DLL の植え付け
アプリケーション ディレクトリは、アプリケーションが、依存する非システム系 DLL を保持し、それらを信頼のおけるものとして扱う場所です。プログラムのインストール ディレクトリに配置されたファイルは、悪意がなく信頼できると推定され、一般的にディレクトリの ACL によるセキュリティ制御はそれを保護するために使用されます。インストール ディレクトリのバイナリを置き換えることができるユーザーは、ファイルを書き込んだり上書きしたりする権限を持っていると推定されます。アプリケーション ディレクトリはコードのディレクトリと考えられ、そのアプリケーションのコードに関連するファイルが保存されています。そのディレクトリへのアクセス権がない攻撃者がアプリケーション ディレクトリで DLL の上書きを実行できる場合、それは単に 1 つの DLL を置き換える/植え付けるということと比べはるかに大きな問題です。
アプリケーション ディレクトリにおける DLL の植え付けに関するいくつかのシナリオを見てみましょう。
シナリオ 1: 信頼されたアプリケーション ディレクトリにおける悪意のあるバイナリの植え付け
適切にインストールされたアプリケーションでは、通常アプリケーション ディレクトリは ACL で保護されており、このシナリオにおいては、アプリケーション ディレクトリのコンテンツを変更するには昇格された権限 (通常管理者権限) が求められます。たとえば、Microsoft Word のインストール先は C:\Program Files (x86)\Microsoft Office\root\Office16です。このディレクトリに変更を加えるには管理者権限が必要です。管理者権限を持つ被害者は、信頼できる場所に DLL を配置するよう誘導されたり、ソーシャル エンジニアリングの手法で騙されたりする可能性がありますが、そのような状況の場合、さらに悪事を働くよう誘導・騙されることも考えられます。
シナリオ 2: 信頼されないアプリケーション ディレクトリにおける悪意のあるバイナリの植え付け
XCOPY などインストーラーを使用しないでインストールされるアプリケーション、共有フォルダーに置かれたアプリケーション、インターネットからダウンロードされたアプリケーション、または ACL で制御されていないディレクトリにあるスタンドアローンの実行ファイルなどは、信頼できないカテゴリに該当するいくつかのシナリオです。たとえば、インターネットからダウンロードされ既定の “ダウンロード” フォルダーで実行されるインストーラー (再配布可能パッケージ、ClickOnce により生成された setup.exe、IExpress により生成された自己解凍アーカイブなどを含む) が該当します。信頼できない場所からアプリケーションを起動するのは危険であり、被害者は容易にこれらの信頼できない場所に DLL を植え付けるよう誘導されたり騙されたりします。
アプリケーション ディレクトリにおける DLL の植え付けのカテゴリに該当する DLL の植え付けの問題は、多層防御の問題として扱われ、更新プログラムは将来のバージョンについてのみ検討されます。 私たちは、この攻撃に必要とされるソーシャル エンジニアリングの量およびこの問題が本質的には仕様に基づく動作である点から、MSRC で受けたこのカテゴリに属する報告を vNext (次期製品バージョン) で検討する問題として扱います。被害者は悪意のある DLL (マルウェア) をそれが起動されうる場所に保存するよう誘導され、 かつ 望ましくない操作 (たとえば、マルウェアと同じディレクトリ内でインストーラーを実行する) を実行する必要があります。インストールされていないアプリケーションには、自身がディレクトリを作成しない限り、“信頼できる安全なディレクトリ / バイナリ” の参照点がありません。理想的には、インストーラーが (それ以上の DLL の植え付けを防止するために) ランダム化された名前を持つ一時ディレクトリを作成し、そこにバイナリを展開してアプリケーションをインストールするべきです。攻撃者が被害者のシステム (たとえば “ダウンロード” フォルダー) にマルウェアを配置する際に、ドライブバイ ダウンロードを利用する可能性はありますが、その攻撃の本質はソーシャル エンジニアリングです。
Windows 10 Creators Update では、アプリケーション ディレクトリにおける DLL の植え付けの脆弱性を緩和するために使用可能な新たなプロセス軽減策を追加しました。この PreferSystem32 という新たなプロセス軽減策は、適用されると、DLL 検索順序におけるアプリケーション ディレクトリと system32 の順序を切り換えます。これにより、アプリケーション ディレクトリに植え付けられたいかなる悪意のあるシステム バイナリもハイジャックされません。これは、プロセスの生成が制御できるシナリオにおいて有効にできます。
現在の作業ディレクトリ (CWD) における DLL の植え付け
一般的にアプリケーションが呼び起こされる元となるディレクトリをアプリケーションは CWD と位置付けます。これは、アプリケーションが既定のファイル関連付けに基づいて起動された場合にも当てはまります。たとえば、“D:\temp\file.abc”’ という共有フォルダーからファイルをクリックすることで、“D:\temp” が .abc というファイル形式に関連付けされたアプリケーションの CWD としてセットされます。
特に WebDAV 共有など、リモートの共有フォルダーでファイルをホストするシナリオは、CWD における DLL の植え付けの問題をより脆弱にします。このようにして攻撃者は悪意のある DLL をファイルと共に保存し、ソーシャル エンジニアリングにより被害者にファイルを開かせ/クリックさせ、悪意のある DLL がターゲットとするアプリケーションにより読み込まれるように仕向けます。
シナリオ 3: CWD における悪意のあるバイナリの植え付け
最初の 3 つの信頼できる場所から DLL を読み込むことができない場合、アプリケーションは、信頼できない CWD からその DLL を探します。被害者が \\server1\share2\ という場所から .doc ファイルを開こうとすると Microsoft Word が起動しますが、Microsoft Word が、依存する DLL の 1 つ oart.dll を信頼できる場所から見つけることができない場合、Word は CWD である \\server1\share2\ からそのファイルを読み込もうとします。その共有フォルダーは信頼できない場所であり、攻撃者は容易にアプリケーション oart.dll を植え付けることができます。
トリガー => \\server1\share2\openme.doc アプリケーション => C:\Program Files (x86)\Microsoft Office\root\Office16\Winword.exe アプリケーション ディレクトリ => _C:\Program Files (x86)\Microsoft Office\root\Office16\ CWD => _\\server1\share2\ 悪意のある DLL => \\server1\share2\OART.DLL
CWD における DLL の植え付けのカテゴリに該当する DLL の植え付けの問題は、緊急度が重要な問題として扱われ、Microsoft はこの問題に対してセキュリティ更新プログラムを公開します。 過去に私たちが修正した DLL の植え付けの問題のほとんどはこのカテゴリに該当し、セキュリティ アドバイザリ 2269637 でそのサブセットが確認できます。ここで、アプリケーション ディレクトリやシステム ディレクトリ、もしくは Windows ディレクトリに存在しない DLL をなぜマイクロソフトのアプリケーションが読み込むのかと疑問に思われるかもしれません。それが起きるのは、さまざまなオプション コンポーネント、異なる OS エディション、そして複数のアーキテクチャが異なるバイナリ セットを付帯しているためで、時としてアプリケーションが DLL を読み込む前に効果的に検討/検証できないことがあるのです。
PATH ディレクトリにおける DLL の植え付け
DLL 検索順序で DLL を探す最後の場所は PATH ディレクトリです。PATH ディレクトリは、アプリケーションや関連ファイルを探す際のユーザー エクスペリエンスを向上するためにさまざまなアプリケーションにより追加されたディレクトリのセットです。
PATH 環境変数にあるディレクトリは、常に管理者権限により制御されており、一般ユーザー権限ではこれらディレクトリのコンテンツを変更できません。もしだれでも書き込みができるディレクトリが PATH によりさらされていたら、DLL 読み込みという単なる 1 つのインスタンスではなく大きな問題であり、私たちは緊急度重要の問題として扱います。しかし、DLL の植え付けの問題だけであれば、この植え付けの脆弱性でセキュリティの境界を越えることは想定されないため、低度のセキュリティの問題とみなします。よって、 PATH ディレクトリにおける DLL の植え付けに該当する DLL の植え付けの問題は修正予定なしとして対応されます。
結論
上記の説明により、報告された DLL の植え付けの問題を私たちがどのようにトリアージし、どのような状況をセキュリティ更新プログラムを公開するほどの重要性があると判断するかについての疑問が解消されると期待しています。以下に、セキュリティ リリース (ダウン レベル修正) を通じて修正するもの、しないものに関する簡単なガイドを示します。
マイクロソフトがセキュリティ修正として対処するもの
CWD のシナリオ – 関連付けられたアプリケーションが信頼できない CWD から DLL を読み込んでしまうもの
マイクロソフトが次に製品がリリースされるタイミングで対処することを検討するもの
アプリケーション ディレクトリのシナリオ – 明示的な読み込みか暗黙的な読み込みかに基づく製品開発グループの判断に依存します。明示的な読み込みでは手を加えられますが、暗黙的な読み込み (依存した DLL) はパスを制御できないため完全に仕様となります。
マイクロソフトが対処しないもの (脆弱性ではないもの)
PATH ディレクトリのシナリオ – PATH では管理者権限を必要としないディレクトリはないため、悪用はできません。
—–
Antonio Galvan, MSRC
Swamy Shivaganga Nagaraju, MSRC Vulnerabilities and Mitigations Team