いきなり質問です。未知のぜい弱性を発見したら皆さんはどうしますか？
自分が未知のぜい弱性を発見することは無いと思われているかもしれませんが，じつは身近に存在しているのに今は気付いていないだけかもしれません。皆さんがぜい弱性を発見して報告する日は近いかもしれませんので，今回は私の経験を基にぜい弱性を発見したらどうするかについて書きたいと思います。
私は今までに何件かぜい弱性を発見して，ソフトウエアの開発元に報告したことがあります。最近では「MS06-053」（http://www.microsoft.com/japan/technet/security/bulletin/ms06-053.mspx）で修正されたぜい弱性を報告しました。まずは，このぜい弱性の発見から報告までの流れを説明しましょう。
2005年12月に「www.google.comにクロスサイト・スクリプティングのぜい弱性，米Watchfireが報告（http://itpro.nikkeibp.co.jp/article/USNEWS/20051222/226650/）」という記事を読んだときに，私は米マイクロソフトのWebサーバー，IISにも同じ問題があるのではないかと考えました。Watchfireが見つけたのはコンテンツの文字セット（charset）が明示的に指定されていない場合，「<」や「>」といったエスケープ処理の対象となる特殊文字などをUTF-7でエンコードされると，これらがエスケープ処理の対象から外れてしまうという問題です。Internet Explorerの文字コードを「自動選択」するという機能がUTF-7でエンコードされた文字を自動的にデコードすることで，結果としてエスケープ処理の対象から外れた特殊文字などがUTF-7エンコードされる前の状態に戻ってしまい，そこに書かれたHTMLやJavaScriptを実行されてしまうのです。
まとめると，コンテンツの文字セットが明示的に指定されていなければ，悪意のあるスクリプトをUTF-7エンコードすることでエスケープ処理を回避することができる上に，Internet Explorerが文字コードを「自動選択」してデコードしてくれるので，結果として悪意のあるスクリプトがエスケープ処理を回避して実行されてしまうということになります（注1）。私は過去に「MS00-084」（http://www.microsoft.com/japan/technet/security/bulletin/MS00-084.mspx）というインデックス・サービスに含まれるクロスサイト・スクリプティングのぜい弱性が修正されたことを覚えていたので，このぜい弱性の対策として追加されたエスケープ処理がUTF-7エンコードによって回避できるのでないかと考えました。
（注1）「ISO-2022-JPなどブラウザが正確に把握できる文字セット」で明示的に指定されていない場合も，エスケープ処理を回避されてしまう恐れがあります。実際にMS00-084で施された対策を調査したところ，このぜい弱性で利用されるエラーページにはコンテンツの文字セットが指定されていないことや，「<」「>」「"」はエスケープ処理されるが「+」「-」「'」「;」「/」などはエスケープ処理されないことが分かりました。このような結果から，UTF-7エンコードによるエスケープ処理の回避を行う上で最低限必要な条件は揃っていることになります。実際にWindows2000日本語版のIIS/5.0でMS00-084のセキュリティ更新プログラムをインストール後に，「<script>alert("XSS");</script>」という文字列がエラーページに表示されるように入力すると，図1のようにエスケープ処理されて「<script>alert("XSS");</script>」という文字列が出力されます。
|
 |
| 図1●Windows 2000日本語版IIS/5.0にUTF-7エンコードされていないスクリプトを送信したときの出力 [画像のクリックで拡大表示] |
次に「<script>alert("XSS");</script>」に含まれる「<」「>」をUTF-7エンコードして「"」を「'」に置き換えた「+ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-」という文字列がエラーページに表示されるように入力すると，図2のように何もエスケープ処理されずにそのままの「+ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-」という文字列が出力されます。この出力を受け取ったInternet Explorerが文字コードを「自動選択」機能で「Unicode (UTF-7)」を選択したならば，「<」と「>」をUTF-7エンコードした「+ADw-」と「+AD4-」はデコードされて，もとの「<」と「>」になるはずです。
 |
| 図2●Windows 2000日本語版IIS/5.0にUTF-7エンコードされたスクリプトを送信したときの出力 [画像のクリックで拡大表示] |
しかしながら，Windows2000日本語版のIIS/5.0ではエラーページにShift-JISエンコードされた文字が含まれていることから，Internet Explorerの文字コードを「自動選択」機能は「日本語 (シフトJIS)」を選択するので，UTF-7エンコードされた文字が自動的にデコードされることはありませんでした。
Windows2000英語版のIIS/5.0では図3のようにエラーページにShift-JISエンコードされた文字が含まれていないことから，Internet Explorerの文字コードを「自動選択」機能は「Unicode (UTF-7)」を選択します。結果として，UTF-7エンコードされた「+ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-」は自動的にデコードされて「<script>alert('XSS');</script>」となり図4のようにスクリプトが実行されました。つまり，日本語版のIISでは攻撃が成功しませんが，英語版なら攻撃が成功するわけです（注2）。
（注2）UTF-7で書かれたページからiframeやframeを経由することで，攻撃が成功する可能性があります。
 |
| 図3●Windows 2000英語版IIS/5.0にUTF-7エンコードされたスクリプトを送信したときの出力 [画像のクリックで拡大表示] |
 |
| 図4●UTF-7エンコードでエスケープ処理を回避してスクリプトが実行された結果 [画像のクリックで拡大表示] |
この結果からMS00-084で追加されたエスケープ処理をUTF-7エンコードによって回避できることが分かりました。これが未知のぜい弱性を発見した瞬間です。
|
|
■著者 プロフィール Eiji James Yoshida
|
