鳩丸よもやま話

bakera.jp > 鳩丸よもやま話 > @nifty パレットのセキュリティホール まとめ

@nifty パレットのセキュリティホール まとめ

この Web ページの内容について

このページには @nifty の「パレット」というサービスにおいて他人の ID とパスワードを盗むことができるというセキュリティホールについての情報が記載されていました。

その内容は 2003年7月7日から 2004年7月7日までのちょうど一年間公開されていましたが、2004年7月8日にIPA の 情報セキュリティ早期警戒パートナーシップガイドライン (www.ipa.go.jp) が公開されたことを受け、同ガイドライン 2 の 3) の規定に従い、内容を非公開としていました。

が、いつのまにか「パレット」も終了しており、特に問題なかろうと判断して再公開するものです。古い話ですし、おそらくあまり価値はありません。

問題の概要

かつて@niftyには「パレット」というサービスがありました。簡単に言うとタグが使用でき、添付ファイルがつけられる会員専用の掲示板です。このパレットに、ID やパスワードが漏洩する可能性のあるセキュリティホールが存在します。

このサービスは @nifty 会員専用ですので、@nifty の会員でない方は特に心配する必要はないでしょう。その意味では Web フォーラムの問題よりも対象は狭いのですが、この問題では @nifty の ID・パスワードが漏洩する可能性があり、悪用された場合の影響は深刻です。

※2003-07-09 追記 : パレットは「Webフォーラム」とは異なるサービスです。日経 BP の記事で報じられたセキュリティホールは Webフォーラムに存在していたもので、XSS大王Q&Aにまとめがあります。ここで論じているものは、それとはまた別のセキュリティホールですのでご注意ください。

パレットの仕様

パレットについての詳細は http://forum.nifty.com/help/02how/conts07.htm などを参照してください。パレットの仕様について重要なポイントがいくつかありますので、あらかじめ説明を加えておきます。

認証方法

パレットの認証は Basic 認証です。そのため、Cookie 漏洩によるセッションハイジャックの危険はありません。

しかしながら、Basic 認証の ID とパスワードは、サーバに TRACE メソッドのリクエストを発行してその応答を得ることによって簡単に読み取られてしまいます。スクリプトや ActiveX コントロールを使用すると、サーバに TRACE メソッドを送り、その応答を任意のサーバに転送するようなことが可能です。そのため、Basic 認証が使用されているサーバが TRACE を受け付け、かつそのサーバ上で自由にスクリプトや ActiveX コントロールが使用できると、Basic 認証の ID とパスワードを盗むことができてしまいます。

※この詳細については、「[memo:5237] XSS脆弱性によりBasic認証のパスワード情報が漏えいする (memo.st.ryukoku.ac.jp)」を参照してください。

パレットの置かれているサーバは、TRACE メソッドに対応しています。そのため、ここで任意のスクリプトを書くことができれば、あるいは任意の Active X コントロールを実行できれば、ID とパスワードを盗むことができてしまいます。また、ここで盗まれるのがセッション Cookie ではなく、ID とパスワードそのものであることに注意してください。これはセッション Cookie 漏洩よりもずっと危険です。

添付ファイル

パレットには添付ファイルを投稿する機能があります。添付ファイルの扱いはファイルの Content-Type によって異なり、以下のようになります。

  • text/plain や text/html の場合 (おそらくは text/* の場合全て) …… 発言の中に、ファイル内容のテキストが直接追記されます。添付ファイル扱いになりません。テキストに HTML のタグ類が含まれている場合、HTML 発言と同じルールで削除されます。たとえば、<script> という文字列があれば削除されます。
  • text 以外の場合 …… ファイルの内容がサーバに格納され、発言にはそのファイルへのリンクが設けられます。

なお、 添付ファイルとなったときのファイル名は、POST データ中の filename パラメータの値に従います (ほとんどのブラウザでは、これはローカルマシン内のファイル名そのものになります)。

ただし、ファイル名に拡張子に相当する部分が存在しない場合は、Content-Type の後半が使用されます。たとえば、foo というファイル名で Content-Type が application/octet-stream ならば、foo.octet-stream というファイル名になります。また、逆にファイル名のベース部分がない場合は、添付ファイルの番号がベース名として使用されます。.htaccess という名前のファイルが 3つめの添付ファイルであるような場合は、3.htaccess という名前になります。

また、ファイル名に "|" "<" などの危険な文字が含まれている場合は、全て "_" に変換されます。

発言しないで添付ファイルを置く

パレットでは、どういうわけか実際の発言をせずに添付ファイルだけをサーバに置くこともできてしまいます。方法は単純で、発言の添付ファイルをサーバに送った後、発言をキャンセルするだけです (キャンセルというアクションがあるわけではありません。何もせずにブラウザを閉じて構いません)。この方法は「パレット裏マニュアル (forum.nifty.com)」で紹介されています。

パレットの発言には発言者の @nifty ID が併記されますが、この方法で残した添付ファイルには ID の情報はつかないので、匿名性を維持したままファイルを置くことができます。

ただし、このようにして置いたファイルはいつの間にか消えていることがあります。後述する 7月4日の添付ファイルはこの方法で置いたのですが、7月5日の昼頃までは存在していて、7月6日に確認したら消えていました。24時間で消えるのかも知れません。

きっかけ : 6月30日のアナウンス

6月30日に、以下のようなアナウンスが出されました。

パレットでのタグの利用について

パレットでのタグの制限につきましてご案内が遅れましたこと、お詫び申し上げます。今回パレットを安全にご利用いただけるよう対応をおこない、一部のHTMLタグの記述を制限させていただきました。

この制限はブラウザでの発言の表示となります。ニュースリーダーでのアクセスでは、オリジナルのデータを取得することとなります。

詳細は「パレットの基本仕様」または「よく使うＨＴＭＬタグ」をご参照ください。

引き続き、みなさまに安心してご利用頂けるよう努力いたしますので、今後ともどうぞよろしくお願いいたします。

以上、@nifty：forum：forum@nifty <http://com.nifty.com/forum/index.html> より

※現在、このアナウンスはインフォメーション一覧 (http://bbs1.nifty.com/mes/cf_wrent/FINFO_B001/) の方に移っています。

文中に「ご案内が遅れました」とあるように、この修正について事前のアナウンスはありませんでした。おそらくは緊急の対処だったものと思われます。

文中で触れられている「よく使う HTML タグ」の内容は http://forum.nifty.com/help/02how/conts07_13.htm で見られますが、末尾に以下のような記述があります。

自由にHTMLを記載できますが、セキュリティ上の理由により、HTML部分からは一定のタグが自動的に除去されます(注)。

除去されるタグの例

<APPLET>、<BASE>、<BASEFONT>、<EMBED>、<FRAME>、<FRAMESET>、<HEAD>、<HTML>、<LINK>、<META>、<OBJECT>、<SCRIPT>、など

　※style、onclick、onstartなどのアトリビュートも利用できません。

(注) ブラウザーで発言を読む場合の制限になります。

以上、@nifty：forum：ヘルプ：フォーラムの使い方 <http://forum.nifty.com/help/02how/conts07_13.htm> より

例の末尾に、さりげなく「など」と書いてあるのが困ります。たとえば、ここには出ていない <style> も削除の対象になっていますが、それは書いてみて初めて判明します。※ある程度の予想はできますが……。

また、この記述からすると、悪影響のある記述をリストアップしておき、それだけを削除するというブラックリスト方式をとっているように思えます。これは、問題ない記述をリストアップして他を削除するホワイトリスト方式に比べ、処理が漏れる危険性が高いと考えられます。

7月2日に発見したセキュリティホール

6/30 のアナウンスを踏まえて、7/2 にその制限について実際にテストしてみました。その結果、タグ削除のルーチンに穴があることが発見されました。

ここで確認したのは、以下のセキュリティホールです。

<script> などは削除されるようになっているのですが、その処理を迂回する方法が存在しました。以下のように書くと、これはそのまま発言内容として投稿されました。

<<script>
……
//<</script>

タグの前に STAGO が余計についています。これだけで回避できました。タグの前に余計な文字列が入ってしまいますが、ブラウザはこれを単なる #PCDATA の文字列として処理し、後ろに <script> タグがあるとみなします。終了タグ前にも余計な文字列が入りますが、これはスクリプトのコメントとなるように処理すれば問題ありません。上記の例では JavaScript のコメントとなるように // を入れてあります。VBScript ならば ' を入れれば問題ありません。

このように、< を前置すればあらゆるタグを書き込むことが可能でした。前述のように、パレットには任意のファイルを添付ファイルとして投稿することができます。そのため、この方法で object を書き、任意の ActiveX コントロールを実行することも可能でした。実際に Macromedia Flash のコンテンツが実行されることを確認しています。

……ここで過去形を使っているのは何故かと言いますと、この欠陥が既に修正されているためです。少なくとも 7月4日以降は、この書き方では突破できなくなっています。

7月4日に発見したセキュリティホール

その後、添付ファイルの悪用によるスクリプト実行が可能という可能性に思い至ったため、7月4日に検証しました。以下の二点が確認できました。

添付ファイルによるスクリプト実行

  • ある方法によって、HTML ファイルを添付ファイルにすることができる。これによってスクリプトなどの実行が可能。
  • 任意の内容のファイルをサーバに置くことができる。Content-Type の内容を無視するブラウザではスクリプトなどの実行が可能。

これはきわめて単純な話です。添付ファイルの内容は全く処理されず、そのまま公開されるのです。これは当然で、パレットではバイナリファイルや画像なども添付できますから、不用意にサニタイズしたりするとファイルを破壊してしまいます。

通常であれば HTML ファイルは添付ファイルとはならないのですが、Content-Type を application/octet-stream などにすれば添付ファイルにすることができます。この HTML ファイルの内容は添付したときのままであり、タグの無効化などは行われませんので、任意のスクリプトが実行可能です。

また、MSIE などでは拡張子が .html である必要もありません。MSIE などはファイルの内容を読んで、それが HTML っぽければ HTML と判断します。Content-Type の値なども無視されます。従って、スクリプトを含む HTML に zip なり jpg なり好きな拡張子をつけて添付してしまえば、それをダウンロード、あるいは表示しようとしたときにスクリプトが実行されます。

7月4日の問題

7月4日の時点において、念のため 7月2日の問題をテストしてみました。

するとどういう訳か、7月2日には通り抜けたはずの記述が無効になっていました。そのかわり、以下のような問題が発見されました。

  • ルーチンの欠陥により、<script> などが書けてしまう (7月4日問題)

……別の書き方を試したら、あっさり通り抜けました。実はこの書き方は 7月2日時点でかなり最初の方に試みた方法なのですが、7月2日の時点では通り抜けませんでした。

何が起きたのかは良く分かりません。ニフティからは何かを修正した旨のアナウンスは出ていませんが、処理が変わったことは間違いないでしょう。

おそらくは 7月 3日のメンテナンスのタイミングでパレットについても何か修正されたものと思われます。その結果、7月2日問題は修正され、その代わりに7月4日問題のバグが埋め込まれたのではないかと思われます。7月4日問題の方が簡単に分かるものなので、事態はむしろ悪化しています。

※具体的な書き方は念のために伏せておきますが、7月2日問題よりもずっと易しい方法で突破します。少し試せばすぐに分かると思います。

まとめと対処法

結局のところ、パレットのセキュリティホールは以下の通りです。

いずれも ID とパスワードを盗まれる危険なものです。

このうち、7月2日の問題のみ修正済みです。その代わり 7月4日問題が発生しましたので、状況は変わっていません。他の二点も修正されていません。

システム側の対処策はそれぞれ以下のようになるでしょう。

削除処理の欠陥

タグを削除する処理の見直しが必要です。

また、そもそも特定タグのみを削除しようという発想に無理があります。この発想には以下のような問題があります。

  • 特定タグだけを識別しようとすると、ルーチンが複雑になります。複雑になれば穴ができる可能性が増えます。まさに現状がそれですね。
  • 未知の記述に対応できません。スクリプトを実行するための記述は無数にあり、その全てを削除しなくてはなりません。プログラマにとって未知の方法で記述されると通り抜けてしまいます。
  • ブラウザの機能拡張に対応できません。ブラウザの機能拡張により、スクリプトを実行できる方法は増えるかも知れません。たとえば、ブラウザが XML namespace に対応した場合、<namespace:script> などというタグも危険になり得ます。

特定タグだけの削除などは考えずに、全てのマークアップを一律無効にしてしまえば、このような問題は起きにくくなります。

HTML ファイルをサーバに置くことができる

この場合は、添付ファイルのファイル名が拡張子 .html であることが問題となります。

実はパレットにはもう一つ、.cgi という拡張子の添付ファイルがエラーになるという問題があります。.cgi という拡張子のファイルを添付すると、ファイルは置けるのですが、アクセスしようとするとエラーとなってしまいます。おそらく、拡張子が .cgi であるものは CGI として実行しようとするのでしょう。しかしながら、ファイルにパーミッションが付加されていないためか、はたまたパスが通っていないためか、実行することができずにエラーとなります。当然、本来の内容を閲覧したりダウンロードしたりすることはできません。

※あるいはニフティのサーバに合わせてコンパイルしたバイナリを置くと動いてしまうのかも知れませんが、さすがにそれはテストしていません。そのようなことがないことを祈ります。

このような問題は、ファイルの拡張子をユーザが自由に設定できるところに起因します。システム側の対処としては、添付ファイルのファイル名や拡張子を決め打ちにしてしまうことが考えられます。ただし、画像などは見られなくなるかも知れません。

任意の内容のファイルをサーバに置くことができる

これは処置無しです。そもそも MSIE が Content-Type を無視するのが悪いのですが、対処方法がありません。ファイル名が何であれスクリプトは実行できますし、ファイルの内容に対してタグ無効化などの処理をしようとすれば、ファイルが壊れてしまいます。

考えられる対処は、添付ファイルの禁止しかないでしょう。ファイル内容をチェックすることも考えられますが、あまり現実的ではないかも知れません。

ユーザにできる対処としては、スクリプト実行、Active X やプラグインの実行を全て無効にするという方法があります。ただ、これで絶対に安全かと言われると難しいところです。なにしろあらゆるものが書けますので……。「パレットの発言にアクセスしない」「パレットの添付ファイルにアクセスしない」という対処のほうが、より安全なような気はします。

パレットにログインせずとも被害を受ける

実はちょっと前まで「パレットを利用しない」という対処法を掲げていましたが、実はパレットを全く利用していなくても被害を受ける危険性があることが分かりました。

@nifty には「インターウェイ」というサービスがあります。これは何かと言いますと、要はパソコン通信のサービスが全て Web 上で利用できるというサービスです。会議室の発言を読んだり、自分宛のメールを読んだりといったことが可能です。なお、発言などの中に URL が書かれている場合、それは自動的にアンカーとなります。これは意外に重要ですのでおさえておいてください。

さて当然ですが、このインターウェイを利用するにはログインが必要です。問題なのは、このログインがパレットのログインをも兼ねているということです。インターウェイにログインしようとするとき、そのドメインは enter.nifty.com で realm は Service となっています。この値はパレットのログイン時のものと全く同じです。そのため以下のような現象が起きます。

この時、ブラウザはインターウェイにログインしたときの ID とパスワードをパレットに対しても送っています。インターウェイにログインすると、同時にパレットにもログインしたことになり、以降、パレットへのアクセス時には自動的に ID とパスワードが送られることになるのです。

そのため、以下のようなことが起こりえます。

※実際に、会議室にパレットの URL を含む発言を行い、インターウェイで閲覧して URL をクリックしてみました。その結果、ID もパスワードも尋ねられずに遷移し、画面には Base64 エンコードされた ID とパスワードが表示されました。

このとき、ユーザには「パレットにログインした」という意識が全くありません。にもかかわらず、パレットのセキュリティホールによって ID とパスワードを盗まれてしまいます。

なお、この URL が直接パレットの罠発言になっている必要はないことに注意してください。全く外部のリソースであっても、フレーム内にパレットの罠発言を含ませておけばやはりパスワードを盗むことができます。従って、URL がパレットのものかどうかによって危険かどうかを判断することはできません。

従って、「パレットを利用しない」という対策に加え、最低限、以下のような対策が必要となります。

なお、enter.nifty.com で @nifty の ID とパスワードを入力するサービスは、インターウェイ以外にもいくつかあるようです。そのようなサービスに関しても警戒する必要があります。

いずれにしても、パレットを利用していないからと言って安心することはできないのです。こうなってくると、もう Web 上で @nifty の ID とパスワードを入力すること自体が危険だと考えておいた方が良いかも知れません。

最近の日記

関わった本など