Index Serverのセキュリティ問題

Windows NT World 2000年5月号
月刊セキュリティレポート No.5

本文書は、Windows NT World誌に寄稿した記事の原稿を、IDGジャパン編集部殿の許可を得た上で掲載したものです。









Index Serverのセキュリティ問題


 今回は、今年の一月に報告されたIndex Serverのセキュリティ問題を取り上げる。Index Serverは、WebコンテンツやMS Officeドキュメントのインデックス付けを行ない、Webブラウザからの要求に応じて検索および結果表示を行なう機能を提供する。問題が指摘されたのは、Windows NT 4.0のOption Packに含まれるIndex Server 2.0および、Windows 2000に標準でインストールされるインデックス・サービスである。本稿では特に区別する必要のない限り、両方を単にIndex Serverと呼ぶこととする。

指摘された問題点は、

  1. Hit-Highlighting機能の不正利用によるファイルの読み出し
  2. 存在しないIDQ/IDAファイルのリクエストによるディレクトリパスの判明

 の二点で、マイクロソフトは両問題に対処するためセキュリティ情報および修正モジュールを公開している。日本語版のIndex Server 2.0に対する修正モジュールはまだ提供されていない(本原稿執筆時点)が、日本語版Windows 2000インデックス・サービスについてはWindows Updateサイト から「Windows 2000重要な更新」をダウンロードすることで対処できる。

Hit-Highlighting機能不正利用の問題


 これはDavid Litchfield氏によって報告されたセキュリティ問題で、Index ServerのHit-Highlighting機能を不正に利用することにより、仮想ルートディレクトリを含んでいる論理ディスクドライブ(D:ドライブ等)上の任意のテキストファイルやMS Officeドキュメント(テキスト部分のみ)をWebブラウザ経由で読み出すことができるというものである。
図1 David Litchfield氏のセキュリティ勧告Webページ
図1 David Litchfield氏のセキュリティ勧告Webページ


 Index Serverは検索結果を表示する際に、ヒットした文書中の該当検索文字列を「強調表示」することができるが、これは「Hit-Highlighting機能(あるいはWebHits機能)」と呼ばれている。この処理を行なうのは、IIS上で.htw拡張子にマッピングされているwebhits.dllである。

 本来、Web経由での検索対象となるドキュメントは、Webの仮想ディレクトリの下に位置しなければならず、よってIndex ServerのHit-Highlighting機能も仮想ディレクトリ以下のファイルに対してのみアクセス可となるべきである。しかし実際は相対的にファイルパスを指定することにより、仮想ディレクトリと同一ディスクドライブ上の任意のファイルにアクセスできてしまう。

 David Litchfield氏が例としてあげているのは、以下のURLによるIISのログファイルへのアクセスである。(改行されているが実際は一行)

http://192.168.113.9/iissamples/issamples/oop/qfullhit.htw? CiWebHitsFile=/../../winnt/system32/logfiles/w3svc1/ex000121.log& CiRestriction=none&CiHiliteType=Full

 このURLでアクセスすることにより、IISサーバ(この場合、IPアドレス192.168.113.9)上のログファイル(2000年1月21日分)を読み出すことが可能となる。この例ではIISに標準で含まれるqfullhit.htwというhtwファイルを利用している。
図2 IISサンプルのqfullhit.htwファイルを利用したIISログファイルへのアクセス結果。
図2 IISサンプルのqfullhit.htwファイルを
利用したIISログファイルへのアクセス結果。


 それでは、利用するhtwファイルがターゲットマシンに存在しなければどうだろう。残念ながらその場合でも安全とは言えない。次のようなURLで試してみていただきたい。

http://192.168.113.9/default.asp%20(240前後の%20の繰り返し)%20.htw? CiWebHitsFile=/../../winnt/system32/logfiles/w3svc1/ex000121.log& CiRestriction=none&CiHiliteType=Full

 必要な %20(スペース)の数はURLの長さに依存するようだが、240個前後を指定することにより、実際に存在するファイル(default.asp)があたかも拡張子htwを持っているような挙動を示し、それによって任意のファイルを読み出すことができてしまう。
図3 default.aspをhtwファイルに見せかけて、IISログファイルへアクセスした結果。ページの下の方にログファイルの内容が表示される。
図3 default.aspをhtwファイルに見せかけて、
IISログファイルへアクセスした結果。
ページの下の方にログファイルの内容が表示される。


この現象は、

  • IISはURL中のファイルの拡張子(.htw)を見てwebhits.dllに処理を渡す
  • webhits.dllは一定の長さまでしかファイル名を認識しない
  • そのため最後の.htwを除いた名称のファイル(すなわちdefault.asp)を htwファイルとして使用する

 といったことから発生する不具合であると考えられる。ちなみにNTではファイル名に後続するスペースやドット(".")は無視されるので、

"default.asp"
"default.asp "
"default.asp.........."
 はいずれもファイル名としては等価である。つまり上記URLの"%20"を"."に置き換えても同じ結果が得られる。

 Hit-Highlighting機能の不正利用問題は、NT4.0のIndex Server 2.0およびWindows 2000に付属するインデックス・サービスの両方で発生する。Index Serverの機能を使用しないのであれば、IIS上でhtw拡張子のアプリケーションマッピングを削除することにより、この問題を回避することができる。
図4 Microsoft管理コンソールより.htwのアプリケーションマッピングを削除する。
図4 Microsoft管理コンソールより
.htwのアプリケーションマッピングを削除する。


 Index Serverの機能を使用するのであれば、前述の通りマイクロソフトが提供している修正モジュールを適用する必要がある。ただし本原稿執筆時点ではIndex Server 2.0日本語版用の修正モジュールはまだ提供されていない。


IDQ/IDAによるディレクトリパス判明の問題


 これはかなり以前から指摘されてきた問題だが、存在しないIDQファイルやIDAファイルをWebブラウザから指定した場合に、ブラウザへ表示されるエラーメッセージにより該当仮想ディレクトリの実際のディレクトリパスが判明してしまうというものだ。

例えば、

http://192.168.113.9/aaa.idq

 というURLにアクセスするとしよう。ここでaaa.idqは実際にはWebサーバに存在しないファイルである。すると、ブラウザには以下のようなエラーメッセージが表示される。
図5 存在しないIDQファイルを指定した際のエラーメッセージ。仮想ディレクトリの実際のディレクトリパスが表示される。
図5 存在しないIDQファイルを指定した際のエラーメッセージ。
仮想ディレクトリの実際のディレクトリパスが表示される。


クエリー "" の処理中にエラー "IDQ ファイル D:\Inetpub\wwwroot\aaa.idq が見つかりませんでした。 " (0xc000203e) が発生しました。

 これにより、仮想ルートディレクトリは D:\Inetpub\wwwroot であることが分かる。存在しないIDAファイル(aaa.ida等)を指定しても結果は同じである。この問題は、IDQ/IDAファイルを処理するDLL(idq.dll)が、ファイルが存在しない場合に生成するエラーメッセージの中に実際のディレクトリパスを表示してしまうことにより発生する。

 マイクロソフトのセキュリティ情報には、この問題が影響するのはNT 4.0のIndex Server 2.0のみであり、Windows 2000のインデックス・サービスは問題ないと書かれているが、実際にはWindows 2000日本語版のインデックス・サービスでもこの問題が発生する。対策方法はHit-Highlighting機能の問題と同様である。特にIndex Serverを使用する必要がないのであれば、IIS上でidqやida拡張子のアプリケーションマッピングを削除すれば良い。Index Serverを使用する場合は、修正モジュールを適用する必要がある。

 この問題に対するもう一つの対策方法は、IISのアプリケーションマッピングの設定を変更して、ファイルの存在を常にIISにチェックさせるようにすることだ(図6)。これにより、IISはブラウザから要求されたIDQ/IDAファイルの処理を該当するDLL(この場合idq.dll)に渡す前に、ファイルの存在を確認し、存在しなければIIS自身がエラーメッセージをブラウザに返すようになる。このエラーメッセージにはディレクトリパスは表示されない(図7)。この対策方法はIDQ/IDA以外で発生する同様の問題(Perl CGIでのディレクトリパスの判明等)にも有効である。ただしIISのヘルプ情報によると、この設定を行なった場合は若干のパフォーマンス低下があるとのことなので、あくまでも一時的な対処と考えた方が良いだろう。

図6 Microsoft管理コンソールより.idqのアプリケーションマッピングの設定を変更し、常に「ファイルの存在を確認する」ようにする。
図6 Microsoft管理コンソールより
.idqのアプリケーションマッピングの設定を変更し、
常に「ファイルの存在を確認する」ようにする。


図7 IISの設定で「ファイルの存在を確認する」をチェックした場合。存在しないIDQファイルを指定してもディレクトリパスは表示されない。
図7 IISの設定で「ファイルの存在を確認する」をチェックした場合。
存在しないIDQファイルを指定してもディレクトリパスは表示されない。


 前述した通りWindows 2000ではWindows Update経由で「Windows 2000重要な更新 - 2000年2月」をインストールすることにより、今回解説した両方の問題に対処できる。「Windows 2000重要な更新 - 2000年2月」には今回の問題の修正以外に、

  • 西暦以外のカレンダーで年が誤って表示される
  • Office 2000製品からWebフォルダに保存したHTMLファイルが破損する

 という別の問題に関する修正も含まれるので、Windows 2000をお使いの場合はこの修正プログラムの適用をお勧めする。


2000年4月執筆
セントラル・コンピュータ・サービス株式会社
塩月 誠人