IISのフォルダ侵入およびファイル要求解析の脆弱性
Windows 2000 World 2001年2月号
月刊セキュリティレポート No.12
|
本文書は、Windows 2000 World誌に寄稿した記事の原稿を、IDGジャパン編集部殿の許可を得た上で掲載したものです。
|
今回はIIS4.0および5.0に関する「Webサーバフォルダへの侵入」と「Webサーバによるファイル要求の解析」の二つの脆弱性を取り上げる。いずれもWebサーバ上で任意のコマンドを起動させることができてしまう、非常に危険性の高い脆弱性である。
Webサーバフォルダへの侵入の脆弱性
この脆弱性は、IIS4.0および5.0において特定のURLを指定することにより、特定の条件下でOSのコマンドをリモートから実行することができるものである。匿名の投稿者によりpacket storm（セキュリティ情報を提供するWebサイト）のフォーラムに投稿され、rain forest puppy氏[1]（図1）によってマイクロソフトへ報告された。またNSFOCUSも同時期にこの脆弱性に関する情報を公開した[2]。マイクロソフトはこの問題に対し、セキュリティ情報および修正モジュールを提供している[3][4]。
|
図1 IISの「Webサーバフォルダへの侵入の脆弱性」を報告するrain forest puppy氏のWebページ。
|
この問題は、IISにおけるURLの正規化（canonicalization）エラーに起因する。通常Webクライアントは、Webサーバの仮想ルートディレクトリ（\Inetpub\wwwroot等）をまたいでファイルシステムのディレクトリ構造にアクセスすることはできない。Webサーバはこの制約により、Webクライアントが不正にファイルシステムへアクセスすることを防御している。しかしIISのURL正規化エラーにより、UTF-8でエンコードした特定のURLを指定することでこの制約を回避し、仮想ルートディレクトリを越えてファイルシステムにアクセスすることができてしまう。
例えばWebブラウザからIISに対し次のようなURLを指定してみる（図2）。
http://192.168.0.13/scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir+e:\
すると図に示した通り、cmd.exeがWebサーバ上で起動し、コマンド「dir e:\」の結果がWebブラウザ上に表示される。（注：「scripts」仮想ディレクトリには「スクリプトおよび実行可能ファイル」の実行アクセス権が必要）
|
図2 IIS5.0に対して%c0%afを含む不正なURLでアクセスし、サーバ上で「dir e:\」を実行させた例。
|
「%c0%af」を二進数で表すと「11000000 10101111」となり、これはUTF-8エンコードされた「/」らしきことがわかる（表1および表2）。ただし「/(U+002F)」はUS-ASCII領域の文字（U+0000〜U+007F）であるため、正しいUTF-8エンコーディングは「00101111」すなわち「%2f」となる。つまり、正しくないUTF-8エンコード形式でURL中に「/」を挿入した場合、IISはURL正規化の過程で誤った判断を行ない、本来制限されているはずの仮想ルートディレクトリを超えたファイルシステムアクセスが可能になり、結果としてシステムディレクトリにあるcmd.exeを起動することができてしまうのである。
表1 UTF-8エンコーディングの仕組み（RFC2279より）
-------------------------------------------------------------------------
UCS-2(Unicode)範囲(16進) UTF-8エンコードされたビット列(2進)
---------------------------------------------------------------------
0000 〜 007F → 0xxxxxxx
0080 〜 07FF → 110xxxxx 10xxxxxx
0800 〜 FFFF → 1110xxxx 10xxxxxx 10xxxxxx
(注：xには元のビット列が、後方オクテットの下位ビットより順に入れられる）
-------------------------------------------------------------------------
表2 「/」のUTF-8エンコーディングのバリエーション（1番目のみが正規）
-------------------------------------------------------------------------
「/(0x2F)」のUnicode表現(2進) UTF-8エンコードされたビット列(2進)
---------------------------------------------------------------------
00000000 0101111 → 00101111 正
→ 11000000 10101111 誤
→ 11100000 10000000 10101111 誤
-------------------------------------------------------------------------
ちなみに以下のエンコードパターンでも同様に、仮想ディレクトリを越えたアクセス（マイクロソフトの言うところの「フォルダへの侵入」）が可能である。
%e0%80%af → 「/」の誤ったUTF-8 3バイトエンコード
%c1%9c → 「\」の誤ったUTF-8 2バイトエンコード
%e0%81%9c → 「\」の誤ったUTF-8 3バイトエンコード
この脆弱性には、以下の特徴がある。
1. 侵入できるフォルダは仮想ディレクトリと同一論理ドライブに限定
この脆弱性を利用してアクセスできる（侵入できる）フォルダやファイルは、仮想ディレクトリと同一の論理ドライブ（C:等）に限定される。上の例で言うと、「scripts」仮想ディレクトリが存在する論理ドライブと「/winnt/system32/cmd.exe」が存在する論理ドライブとが異なる場合、このプログラムファイルにアクセスすることはできないため「cmd.exe」は起動されない。つまり、すべての仮想ディレクトリがシステムドライブとは異なる論理ドライブ上にある場合、少なくともシステムディレクトリ中のプログラムを実行させられる危険性はなくなる。
2. 「IUSR_マシン名」アカウントのセキュリティコンテキストで実行
この脆弱性でWebサーバ上のプログラムを起動する、あるいはファイルを読み書きする場合、デフォルトではIISの匿名ユーザである「IUSR_マシン名」アカウントのセキュリティコンテキストが使用される。このアカウントはデフォルトでGuestsグループに属し、さほど強力な権限は持たない。しかしWebサーバ自体に適切なセキュリティ設定が施されていない場合、管理者権限を奪われる可能性もあるため非常に危険性が高い。
Webサーバによるファイル要求解析の脆弱性
この脆弱性も前述の脆弱性同様、IIS4.0および5.0に対して不正なURLを送信することによりWebサーバ上の任意のプログラムを起動することができるというもので、NSFOCUSによって報告された[5]（図3）。マイクロソフトはこの問題に対し、セキュリティ情報および修正モジュールを提供している[6][7]（本原稿執筆時点では、日本語版修正モジュールは未提供）。
|
図3 IISの「Webサーバによるファイル要求解析の脆弱性」を報告するNSFOCUSのWebページ。
|
この問題はIISがURLで指定されたスクリプトファイル（バッチファイル等）を処理する際に、不適切なURL解析を行なっているため、システムに対してバッチファイルのファイル名のみならず後続の不正なコマンドまでも渡してしまい、結果として不正なコマンドを実行してしまうというものである。
図4に、IIS5.0に対して以下のURLでアクセスした際の結果を示す。
http://192.168.0.13/scripts/test.bat"+".exe?+&+dir+e:\
ここで「test.bat」はテスト用に作成したバッチファイルで、ファイルの中身は一文字以上含まれていれば何でも良い。このURLによりWebサーバ上でcmd.exeが起動し、「dir e:\」が実行、Webブラウザに結果が表示される。（注：「scripts」仮想ディレクトリには「スクリプトおよび実行可能ファイル」の実行アクセス権が必要）
|
図4 IIS5.0に対してバッチファイルを含む不正なURLでアクセスし、サーバ上で「dir e:\」を実行させた例。
|
上記のURL記述はこの問題の攻撃手法の一例であり、この他にも様々なURL記述がNSFOCUSによって解説されている。マイクロソフトは当初、公開したセキュリティ情報の中でこの問題はIIS4.0には影響しないと明記していたが、NSFOCUSのその後の調査によりIIS4.0にも脆弱性が存在することが判明し、セキュリティ情報も更新された。
この脆弱性を利用した攻撃が成功するためには、以下の条件が満たされなければならない。
1. 要求するファイル（上の例では「test.bat」）が実在する
2. そのファイルの拡張子が.batまたは.cmdである
3. そのファイルに対する実行アクセス権限がある
バッチファイル（.bat等）をWeb仮想ディレクトリ中に入れているケースは少ないと思われるかも知れないが、マイクロソフトによると多くのIIS向けサードパーティ製品がデフォルトでバッチファイルをインストールするらしい。そのような環境下では上記の条件が満たされるため、脆弱性を利用することが可能となる。
この脆弱性も不正なコマンド実行はデフォルトでは「IUSR_マシン名」アカウントのセキュリティコンテキストで行なわれる。そのため前述したWebサーバフォルダへの侵入の脆弱性の場合と同様、直接的にWebサーバのすべての制御を奪われることはない。しかし基本的にローカルログオンしたユーザと同等の権限でプログラムの実行やファイルアクセスが可能なため、他の脆弱性を利用した管理者権限の奪取やトロイの木馬の設置などを実行される危険性は高いと言えよう。
対策方法
今回の「Webサーバフォルダへの侵入」と「Webサーバによるファイル要求の解析」の二つの脆弱性に関する対策方法は、基本的にはマイクロソフトが提供する修正モジュールを適用することになる。「Webサーバによるファイル要求の解析」問題に対する修正モジュールは「Webサーバフォルダへの侵入」問題の修正も含んでいるため、修正モジュールを適用する際は「Webサーバによるファイル要求の解析」のモジュールのみを使用すればよい。
ただし本原稿執筆時点では、最新の修正モジュールの日本語版は提供されていない。また英語版修正モジュールについても、提供した後に脆弱性がなお報告される[8]ケースがあるため、この一連の脆弱性を正しく「修正」するモジュールをマイクロソフトが提供するには、もう少し時間がかかるかも知れない。
Webサーバのセキュリティを確保するためには、ベンダーが提供するセキュリティ修正モジュールを適用することはもちろんであるが、たとえOSやWebサービスあるいはWebアプリケーションの脆弱性が発覚しても容易にセキュリティ侵害に発展しないよう、適切なセキュリティ設定を施すことが重要である。マイクロソフトはIISのセキュリティチェックリストおよびその他さまざまなセキュリティ設定に関連する情報をWebサイトで提供している[9]ので、ぜひ参考にされたい。
最後に、よりセキュアなIIS環境を構築するために留意すべき点について、マイクロソフトのDavid LeBlanc氏がNTBugtraqのメーリングリストに投稿したメッセージ[10]を参考にまとめてみた。
1. ファイルシステムおよびレジストリのアクセス制御
一番良いのは読み込みや書き込みの必要のないユーザの権限はすべて削除することである。最低限、「IUSR_マシン名」や「IWAM_マシン名」のユーザがWebコンテンツに対して書き込めないように設定する。またHKLM\Software、特にHKLM\Software\Classesレジストリツリーに対する書き込みも同様に削除する。ただしWebアプリケーションによっては書き込みが必要な場合もあるため、設定変更によって通常の動作に支障が発生しないことを十分に検証する必要がある。
2. コマンドラインツールの実行権限
攻撃者はセキュリティホールを利用してプログラム実行の手段を得た後、OSのコマンドを実行してさまざまな悪行を働くのが通常である。そのためOSのコマンドの実行権限を制限することは、攻撃者の実行可能範囲を限定し、たとえセキュリティホールが発覚したとしても被る損害をある程度抑えることにつながる。
攻撃者にとって有用なコマンドとしては、cmd.exe、net.exe、tftp.exe、ftp.exe、rcp.exe、cacls.exe、debug.exeなどがあげられる。これらのコマンドのACLを、例えば「Administrator:フルコントロール」のみとする。あるいは「ConsoleAdmins」のような管理者用グループを追加してそれのみにフルコントロールを与える方法もある。ビルトインの「Administrators」グループにフルコントロールを与えるべきではない。なぜならIISの実行ユーザであるLocalSystemは「Administrators」グループのメンバーであるため、LocalSystemが乗っ取られた場合にこれらのコマンドを実行させられる危険性がある。
3. 修正モジュールの適用
関連する製品の修正モジュールが提供されたら、たとえそれがさほど重要ではないと思われたとしても適用する。今回の「Webサーバフォルダへの侵入」脆弱性は、今年の8月に報告された「正規化エラーによるファイルへの誤ったアクセス権の適用」の脆弱性[11]の修正モジュールを適用していれば回避できるものであった。このように、過去の修正モジュールが将来発生する脆弱性をも修正しているケースは今後もありうるため、特に必要ないと思われるような修正モジュールであっても適用しておくことは将来的なリスクを低減させることにつながる。
ただし修正モジュール適用時は、テスト環境で互換性およびパフォーマンステストを行ない、運用環境で問題が発生しないことを確認する必要がある。
4. システムパーティションとデータパーティション
Webサーバ上でシステムのエリア（システムディレクトリやプログラムディレクトリ等）とデータのエリア（Webコンテンツ等）を別々のパーティションに設置することは重要である。「Webサーバフォルダへの侵入」脆弱性はWeb仮想ディレクトリの存在する論理ドライブ以外に対するアクセスはできないため、このようにシステムパーティションとデータパーティションを明確に分離した環境ではシステムのコマンドを実行することができない。このようなケース、すなわち脆弱性を利用する際の制約として同一パーティションでなければ不正にアクセスできないというものは過去にも存在するし、将来的に発生する可能性も決して小さくない。
デフォルトで設定される仮想ディレクトリ（IISHELP、Msadc等）にはシステムドライブ上に物理ディレクトリが存在するものもあるため注意が必要だ。デフォルトの仮想ディレクトリは、必要としない限りマッピングから削除することが基本である。
5. 外向けネットワークアクセスの制限
攻撃者がWebサーバに侵入した場合、通常そのマシンへ何らかのファイルを転送しようとする。転送するファイルはWeb改竄用のHTMLファイル、攻撃のためのツール、スクリプトファイル、トロイの木馬等、さまざまである。一般的にWebサーバに対して直接外側から転送することは、ファイアウォール等のアクセス制限により禁止されているため、攻撃者は侵入したWebサーバから外側（インターネット側）に向けてコネクションを開設しファイル転送を試みる。つまりWebサーバから外側に対するネットワーク接続ができないように、ファイアウォールや外縁ルータで外向けのネットワークアクセスを制限する設定を行なうことで、このような不正なファイル転送を阻止する。
Webサーバへのネットワークアクセス制御（HTTPのみを通す等）は多くのサイトで実施しているだろうが、Webサーバから外向けのアクセス制御はおろそかになっている場合が多い。外縁のルータでフィルタリングするだけでも効果的なので、ぜひ設定していただきたい。
David LeBlanc氏は一連のメッセージの締めくくりに、次のような一言を書いている。
「ここにあげたテクニックはすべて周知のもので、さまざまな公の場で議論されてきた。攻撃者にとって目新しいことは一つもない。」
そう、「敵はすべて知っている」のである。
[1] IIS %c1%1c bug
http://www.wiretrip.net/rfp/p/doc.asp?id=57&iface=2
[2] Microsoft IIS 4.0/5.0 Web Directory Traversal Vulnerability
http://www.nsfocus.com/english/homepage/sa_06.htm
[3] MS00-078: Patch Available for "Web Server Folder Traversal"
Vulnerability
http://www.microsoft.com/technet/security/bulletin/ms00-078.asp
[4] 「Webサーバーフォルダへの侵入」の脆弱性に対する対策
http://www.microsoft.com/japan/security/prekb.asp?sec_cd=MS00-078
[5] Microsoft IIS 4.0/5.0 CGI File Name Inspection Vulnerability
http://www.nsfocus.com/english/homepage/sa_07.htm
[6] MS00-086: Patch Available for "Web Server File Request Parsing"
Vulnerability
http://www.microsoft.com/technet/security/bulletin/ms00-086.asp
[7] 「Web サーバーによるファイル要求の解析」の脆弱性に対する対策
http://www.microsoft.com/japan/security/prekb.asp?sec_cd=MS00-086
[8] IIS 5.0 with patch Q277873 allows executing arbitrary commands
on the web server
http://www.guninski.com/iisasp.html
[9] マイクロソフトTechNet「セキュリティ」
http://www.microsoft.com/japan/technet/security/
[10] David LeBlanc氏がNTBugtraqに投稿したメッセージ
http://www.ntbugtraq.com/default.asp?
pid=36&sid=1&A2=ind0010&L=NTBUGTRAQ&P=R3509
http://www.ntbugtraq.com/default.asp?
pid=36&sid=1&A2=ind0010&L=NTBUGTRAQ&P=R3743
http://www.ntbugtraq.com/default.asp?
pid=36&sid=1&A2=ind0010&L=NTBUGTRAQ&P=R4743
[11] 「正規化エラーによる、ファイルへの誤ったアクセス権の適用」の
脆弱性に対する対策
http://www.microsoft.com/japan/security/prekb.asp?sec_cd=MS00-057
2000年11月執筆
塩月 誠人
インターナショナル・ネットワーク・セキュリティ株式会社
| 