Index Serverのセキュリティ問題

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

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

これはDavid Litchfield氏によって報告されたセキュリティ問題で、Index ServerのHit-Highlighting機能を不正に利用することにより、仮想ルートディレクトリを含んでいる論理ディスクドライブ（D:ドライブ等）上の任意のテキストファイルやMS Officeドキュメント（テキスト部分のみ）を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ログファイルへのアクセス結果。 　それでは、利用する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ログファイルへアクセスした結果。 ページの下の方にログファイルの内容が表示される。 この現象は、 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のアプリケーションマッピングを削除する。 　Index Serverの機能を使用するのであれば、前述の通りマイクロソフトが提供している修正モジュールを適用する必要がある。ただし本原稿執筆時点ではIndex Server 2.0日本語版用の修正モジュールはまだ提供されていない。

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

これはかなり以前から指摘されてきた問題だが、存在しないIDQファイルやIDAファイルをWebブラウザから指定した場合に、ブラウザへ表示されるエラーメッセージにより該当仮想ディレクトリの実際のディレクトリパスが判明してしまうというものだ。 例えば、 http://192.168.113.9/aaa.idq 　というURLにアクセスするとしよう。ここでaaa.idqは実際にはWebサーバに存在しないファイルである。すると、ブラウザには以下のようなエラーメッセージが表示される。 図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のアプリケーションマッピングの設定を変更し、 常に「ファイルの存在を確認する」ようにする。 図7 IISの設定で「ファイルの存在を確認する」をチェックした場合。 存在しないIDQファイルを指定してもディレクトリパスは表示されない。 　前述した通りWindows 2000ではWindows Update経由で「Windows 2000重要な更新 - 2000年2月」をインストールすることにより、今回解説した両方の問題に対処できる。「Windows 2000重要な更新 - 2000年2月」には今回の問題の修正以外に、 西暦以外のカレンダーで年が誤って表示される Office 2000製品からWebフォルダに保存したHTMLファイルが破損する 　という別の問題に関する修正も含まれるので、Windows 2000をお使いの場合はこの修正プログラムの適用をお勧めする。

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