■

■ACCSとoffice氏が和解 〜 掲示板の監視義務を課す仮処分申請で

当日記の5/28付けは編集中で悩み気味なのですが、気になるニュースがあったので反応してみました。

INTERNET Watch - ACCSとoffice氏が和解〜掲示板の監視義務を課す仮処分申請でより引用いたします。

ACCSの久保田裕専務理事は、話し合いの中で実際にoffice氏と面会した際の印象などから、同氏がACCSの求めに応じたことについて、「不正アクセスのほうはいざ知らず、個人情報（を流出させた責任）については、反省の色が見られたのではないか」と述べている。

久保田裕専務理事は和解の内容に書いていないことをご自身の感想で述べています。個人情報（を流出させた責任）については、反省の色が見られたのではないかという久保田氏のご発言は和解についての発表の場においては不適切ではないでしょうか。民事における損害賠償案件についてはまだまだ係争中であり、その係争に有利と思われる発言を個人の感想レベルで別な案件の和解の場において話すのは余り宜しくないですね。和解の内容にのみ発表なさるべきでしょう。また、仮に久保田氏の感想を記事にするのならば、INTERNET Watch編集部は公平を期す為、office氏からも取材するべきです。この時期ですと編集部はoffice氏からの取材および記事化を断念するであろうと思われますが、そうであるならば久保田氏によるこのような余談は省略すべきだと思われます。

和解に至った過程は今のところ公表されていませんし、はっきりとしませんが、結果として裁判所による裁定ではなく取り下げによる和解であること、およびに、和解内容そのもの、両者を注意深く見る限りにおいて、今回の個人情報漏洩周辺についてきちんと考えれば当然ながらわかってくることとして次のようなことが言えると思われます。

ACCSもoffice氏も、それぞれ被害者に対する責任があり、協力して対応するためにこの和解に至った。

上の観点でなかったとするとこの和解の意味がありません。そうなればそもそも和解は不可能ですしそうなれば裁判所の裁定になることでしょう。本当の被害者は情報が出てしまった個人なのだから、ACCSもoffice氏も(AD200Xも)＜協力して＞被害者の為に漏れ出る情報がこれ以上発生しないようにするのだと、そうでなければなりませんね。当たり前のことです。この当たり前のことがわからないようではACCSはいつまでたっても信頼されません。

和解の真の意味を捉えるのであるならば、「ACCSが」office氏に義務を課したものではなく、双方が自発的に行うことについて、協力・連携することにしたということになります。

なお、上の記事の引用元ではACCSの要求に同意し、それらを自主的に行なう旨を宣言したという。という文章がありますがこのことはとても大事です。

office氏にしてみればネット上での個人情報拡散防止の為の調査は言われるまでもなく既に個人的に自発的に行っているところであり今回の和解によってACCSとの公的、正式な協力体制が組める事はとても良い事であろうと思われます。今までそれがなかったのだから。また、AD200XサイドとACCSとのあいだの協力体制もこの際ですのでACCSは充分に考えていただければと思います。AD200Xサイドの過去の公式発表をみる限りACCSからの協力など論外という雰囲気がしたもので。

■次世代WindowsOSとIEの素敵なところ

windowsXPのSP2でしたっけ？では根本的なところで非常にセキュアになりつつある兆候があるようです。私は、とあるServerOSの付随品であるところのCGIWRAPが市場占有率の極めて高いWindowsIEと無茶苦茶相性が悪いことがきっかけでクロスサイトスクリプティング脆弱性にあえて特化して全知力を傾注してきました。簡単なのかどうかわかりませんが説明を試みますと、サーバが「これってピュアなテキストなんですよぉ、適切に処理して下さいねぇ」と言ってもWindowsIEはわざわざそのテキストを読みこんで解析し「おう、これはタグがはいっているからテキストじゃぁねぇべ、HTMLだやなぁ。よっしゃ、せっかくだからついでだ、スクリプトも実行してやるべさ。便宜性を保証すべくオイラが設計されてるべさ」という仕組みを是としてIEは調教されて出荷されていたんですよね。それゆえ、例えばアプリがデバッグ用に出力する純粋なテキスト情報も時には悪意あるスクリプトが作動してしまう余地があったわけでして。これは本当に困った事です。ま、テキスト以外でもいろいろなファイル種別が本来の動作をしなくてさまざまなセキュリティー上の問題を出現していたわけで。

大英断だったと思いますし、なかなか既存のWindowsOSに乗っからない理由もなんとなくわかりますので率直に拍手いたします。少なくとも、サーバが「これはテキストだよーん」と言うことを信用しないこと、そして、「これはHTMLのような気がする」と高々ブラウザの分際で決め付けずに、「とりあえず、サーバの言う事とオイラの判断が異なるんですけどぉ」と言うだけの能力を、次世代のWindowsOSとIEは持ち始めているようです。

ようやく私にかけられた呪縛は溶けそうです。皆が幸せでありますように。

■不正なドットなしURLアドレスによりWebページがイントラネットゾーンで処理されてしまう。

IE6では、アクセス対象のWebサイトを５種類のゾーンに分類し、ゾーンごとに適用されるセキュリティ設定を切り替えることができます。これにより、信頼性の高いサイトでは低いセキュリティ設定を（緩い制限を）、信頼性が不明なサイトに対しては高いセキュリティ設定を（強い制限を）自動的に適用できるようになっています。５種類は次の通りです。インターネットゾーン、イントラネットゾーン、信頼済みサイトゾーン、制限付きサイトゾーン、マイコンピュータゾーン、です。なお、通常、マイコンピュータゾーンはコントロールパネルなどでは意識されていませんが確かに存在します。私達は通常、インターネットゾーンを利用して多くのWebページを閲覧しています。一方、社内システムなどの特定システムにおいては外側のインターネット世界（＝インターネットゾーン）よりも安全であるとみなされますので、これをイントラネットゾーンとし、セキュリティー面においては低いセキュリティ設定、緩やかな甘い制限の元で稼動出来るようになっています。各ゾーンごとのセキュリティー設定はユーザが自由に設定出来る為、例えばインターネットゾーンではjavascriptが作動しないように設定しているユーザも少なくないことでしょう。しかしながらイントラネットゾーンのセキュリティー設定については通常の場合では既定の設定のままで緩やかな制限において使用している人が多いはずです。

セキュリティー系のメーリングリストにおいて6/11に発表されていましたが、悪意を持つサーバ保持者が（攻撃されて【密かに？】権限を奪われてしまったケースを含む）工夫されたDNS設定を行うことを通じて、不正なドットなしURLアドレスによりWebページがセキュリティー上の制限が甘いイントラネットゾーンで処理されるように工夫が出来る事がわかりました。インターネットゾーン対策で設定をキツメにして用心している利用者もイントラネットゾーンに誘導されて悪意ある攻撃を受ける可能性がありますので要注意です。

ドットなしURLアドレスと言うと奇異に感じますが、ドットなしIPアドレスならば思い当たるセキュリティー研究者、サーバ管理者も多いかと思います。MS01-051の事例です。URLに不正なドットなしIPアドレスを指定すると、本来インターネットゾーンで処理すべきWebサイトを、通常はそれよりもセキュリティ制限の弱いイントラネットゾーンとして処理してしまうという脆弱性でした。これについては既にパッチ済みですしとりたてて心配があるわけではありません。しかしながらある種のごく簡単なDNS設定によりIPアドレス以外の表現にてドットなしのURLでイントラネットゾーンで処理される悪意あるサイトに誘導可能であることがわかってしまったのです。現在のところパッチはまだありません。

対策は２通り考えられます。ひとつめは、イントラネットゾーンのセキュリティー設定をキツめにすることです。個人が自宅でWebを利用する際にはお勧めです。企業内ユースにてどうしてもイントラネットゾーンの設定をキツめに出来ない場合には次のようなことを試して見てください。イントラネットゾーンのセキュリティー設定においてサイト設定の画面を開き、「ほかのゾーンにないローカル（イントラネット）のサイトをすべて含める（Ｚ）」のチェックボックスをオフにします。これによりインターネットのドメイン名ではなく、ドット（「．」）を含まないURL（例「http://whatever?」）がイントラネットとして参照ではなくなります。もっとも、社内システムの構成いかんではこの方法は使えません。その場合には、イントラネットゾーンをガチガチに固めて、社内システムを信頼済みサイトゾーンに登録したほうが良いかもしれません。

参考URLを以下に掲げます。

ちなみにCOELACANTHとはシーラカンス（生ける化石魚）のようです。いまどきこんな脆弱性がまだ生き残っているのかという意味合いなのでしょう。

6/20追記：ネットワークログオンのNTLM認証について、イントラネットゾーンにおいて自動ログオンを使用していると、悪意ある外部のサーバにイントラネットゾーンであると詐称されるとWindowsアカウントとパスワードを自動的に盗まれるというデモが発表されていました。怖いですね。とりあえず本当の社外との間のプロキシかなにかでNTCR 認証をブロックしておけば大丈夫なのかさえ私にはわかりません。

■不正なURLアドレスによりWebページが信頼済みサイトゾーンで処理されてしまう。

見出しを間違えていました。

不正なドットなしURLアドレスによりWebページが信頼済みサイトゾーンで処理されてしまう、のでした。

メーリングリストの関連スレをよく読んだら、イントラネットゾーンばかりではなく、信頼済みサイトゾーンにも誘導されかねないことが書いてありました。悪意ある者が被害者のユーザが信頼済みにしたサイトを推測できれば攻撃は可能のようです。

このシーラカンスネタの本質はURLアドレスバーの偽装です。例えばWindowsUPDATEのサイトを信頼済みサイトに設定している人がいたとして、あたかもWindowsUPDATEのサイトであるようなURLアドレスバーの偽装をすると（ついでに）誘導先の悪意あるサイトも信頼済みサイトゾーンで処理されるというタチの悪いものです。

上であげたイントラネットゾーンへの偽装ネタも、アドレスバー偽装の副作用として捉えたほうがわかりやすいですね。ドットなしURLはイントラネットで処理されますのでそのような偽装をしたと。

信頼済みサイトゾーンをどのように登録しているのかについては悪意ある攻撃者に容易に知られない自信がない限り、信頼済みサイトゾーンですらActiveX等を許可しないほうが良いかも知れません。

詳細は省きますが悪意ある者がこのような罠を作るのは技術的には極めて簡単なようです。

ActiveXオフ等の防衛策をほどこしてあったとしもなお有効なステータスバー偽装方法が知られていますので組み合わされるとかなりやっかいですね。信頼できるサイト以外からの『あやしいところへのリンクはクリックしない』という運用指導はかなり難しいかもしれません。そのような罠が見破れるのはかなりのチカラを持つ人だけでしょうから。

なにゆえシーラカンスネタなのかもはっきりわかりました。フィッシング詐欺（魚釣り）にひっかけてあるのですね。この脆弱性の一番の使い道はフィッシング詐欺でしょうから。でっかくてまるまるとしたシーラカンスがいたよ、ということでしょう。

■HTMLとjavascriptとの競合（racecondistion）

ブラウザの設計者ならば、HTMLとjavascriptとの競合（race condistion）には一度は頭を悩ますはずです。HTMLの記述とjavascriptの記述が相反するページに出会った時にブラウザはどのように振舞うべきなのでしょう。ブラウザ設計者にとっては腕の振るいどころです。無論、HTML記述が優先されなくてはいけません。

一例をあげましょう。4/30にBUGTRAQに投稿された、IE Certificate Stealing (Phising) bugから肝心な部分を引用いたします。

We point with REFRESH Meta Tag that website.


<meta http-equiv="REFRESH" 
  content="0;url=https://www.example.com/" 
>

Then inside our BODY tag we use onUnload to inform the webbrowser what to do when it will unload that webpage (using the window.location method).


<BODY onUnload='window.location=""'>

HTML記述ではmeta要素にて、example.comに遷移しようとしてます。その一方、javascriptでは、onUnloadイベントにて、遷移先locationが空白であるような指定をしています。これは矛盾です。

この矛盾を上手に処理できないIEは、HTML記述に従って遷移先のSSL認証の確認をユーザに求める一方で、javascript記述に従って遷移先は元のWEBページの一階層上のディレクトリを選ぼうとします。HTMLとjavascriptの処理機構が並行してなおかつタイミングが競合し、race condistion が発生し、奇妙な結果になってしまいます。

SSL認証をさせた上で実は悪意あるサイトにてユーザ入力を促すトリックなのですが、もっとも、この脆弱性の悪用は難しいとも思われます。日本国内では確かニュースにはならなかったと思います。

さて、secuniaは、このexploitをOpera7.23で試しみた節があります。Operaでは、より凄いことになっていました。URLアドレスバーの偽装が可能だったのです。以下のポインタを参照願います。2004-05-13に公表され、opera7.50でFIXされたとあります。Secunia - Advisories - Opera Browser Address Bar Spoofing Vulnerability

注意：これは最近発表されたopera7.51のURLアドレスバー偽装とは別物です。

Operaには他のブラウザには見られない実装があります。Webページ内にURLを含む要素があるとその一部に関して、レンダリングの為にアクセスする都度、アドレスバーにそのURLを表示するのです。例えばIEではステータスバーに表示されるのですがねぇ。Operaのこの性質はある場合においては危険です、Webページ内のとある要素のアクセス先をアドレスバーに表示したはいいけれども、本来表示すべき自分のWebページのアドレスを表示しなおすことを忘れてしまうことがあるのです。先に示したポインタ(secunia)において説明された脆弱性もその性質が反映されたものでした。HTMLにてmeta要素でリダイレクトの要請があり、その瞬間にアドレスバーはリダイレクト先のURLを表示してしまう（これは早とちり）にもかかわらず、onunloadイベントで、リダイレクト先を自分自身とすることによりリダイレクトをキャンセルしてしまう、その時にアドレスバーの表示として本来のアドレスに差し替えるのを忘れているのですね。

アドレスバーはセキュリティーの最重要項目ですから、本当の意味でページが遷移した時にのみ書きかえられるべきなのですが、ページ内の各要素ごと（meta要素含む、もろもろ）にアクセスするたびに書き換わってしまう、そんなOperaなのです。いえ、そうしていただいても構いませんが、最後に自分のページのアドレスに書き戻すべきなのですね。ところが、HTMLとjavascriptの処理機構が並行してなおかつタイミングが競合し、race condistion が発生し、奇妙な結果になってしまいます。

Opera7.50でFIXしたのは、meta要素でリダイレクトする際に、onunloadでのjavascriptを無視するように試みた、その一点につきます。(海外のサイトを巡回していたらこの処置が充分ではないことがわかりましたが。)Opera.7.50と7.51では、あいかわらず、アドレスバー表示におけるHTMLとjavascriptとのあいだの競合問題の本質（ささいなアクセスを全部アドレスバーで表示すること、HTML優先ではなく、タイミングによってはjavascriptによるアドレスバー表示支配が有効なこと)は是正されていません。それゆえ、opera7.51にいたっても、タイミング（マシンの処理能力や回線速度の問題など物理的な要件が加味されますが）によっては、あいかわらず、アドレスバー偽装が可能なようになっています。

ユーザとしての対策としては、当面、Operaではjavascriptオフ推奨ですね。