未知のぜい弱性を発見した。未知のぜい弱性を発見した。未知のぜい弱性を発見した。すんの!?オレ(その1)いきなり質問です。未知のぜい弱性を発見したら皆さんはどうしますか?自分が未知のぜい弱性を発見することは無いと思われているかもしれませんが,じつは身近に存在しているのに今は気付いていないだけかもしれません。皆さんがぜい弱性を発見して報告する日は近いかもしれませんので,今回は私の経験を基にぜい弱性を発見したらどうするかについて書きたいと思います。私は今までに何件かぜい弱性を発見して,ソフトウエアの開発元に報告したことがあります。最近では「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でエンコードされると,これらがエスケープ処理の対象から外れてしまうという問題です。Explorerの文字コードを「自動選択」するという機能がUTF-7でエンコードされた文字を自動的にデコードすることで,結果としてエスケープ処理の対象から外れた特殊文字などがUTF-7エンコードされる前の状態に戻ってしまい,そこに書かれたHTMLやJavaScriptを実行されてしまうのです。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のようにエスケープ処理されて「&lt;script&gt;alert(&quot;XSS&quot;);&lt;/script&gt;」という文字列が出力されます。■変更履歴1複数の特殊文字がエスケープ処理されておりませんでしたので,修正しました。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-」という文字列が出力されます。(UTF-7)」を選択したならば,「<」と「>」をUTF-7エンコードした「+ADw-」と「+AD4-」はデコードされて,もとの「<」と「>」になるはずです。(シフトJIS)」を選択するので,UTF-7エンコードされた文字が自動的にデコードされることはありませんでした。(UTF-7)」を選択します。結果として,UTF-7エンコードされた「+ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-」は自動的にデコードされて「<script>alert('XSS');</script>」となり図4のようにスクリプトが実行されました。日本語版のIISでは攻撃が成功しませんが,英語版なら攻撃が成功するわけです(注2)。(注2)UTF-7で書かれたページからiframeやframeを経由することで,攻撃が成功する可能性があります。2000英語版IIS/5.0にUTF-7エンコードされたスクリプトを送信したときの出力[画像のクリックで拡大表示]図4●UTF-7エンコードでエスケープ処理を回避してスクリプトが実行された結果[画像のクリックで拡大表示]この結果からMS00-084で追加されたエスケープ処理をUTF-7エンコードによって回避できることが分かりました。これが未知のぜい弱性を発見した瞬間です。■変更履歴2読者からの指摘があり,2カ所注釈を加えました。14:30]■変更履歴3図1,2のサムネール画像,図2の拡大画像が内容と違うものになっていましたので,差し替えました。Yoshida1999年から今までに数多くの企業や省庁のセキュリティ診断を担当。セキュリティ・ホールや侵入技術の研究を手掛け、その研究成果を基にセキュリティ診断や教育、執筆活動を行っている。「セキュリティ徒然草」では、セキュリティ診断やセキュリティ・ホールに関する話題の他にも、セキュリティに関するよしなしごとをおもいのままに書き綴る。Yoshidaの記録」でも情報提供中。農家が実感した自動飛行ドローンのすごさクラウド現場の負担軽減を!医療界でのAWS活用法SaaSを加速するソリューションとは?クラウドの新形態「aPaaS」のメリットDXを阻むコミュニケーションの壁とは?AWSとSAPの連携強化がもたらす利点は500万社が導入。価値創造型の社内コミュニケーションとは発想を豊かにする有機的な会議ツールとは働き方が変わる。Reserved.このページに掲載されている記事・写真・図表などの無断転載を禁じます。掲載している情報は、記事執筆時点のものです。