高木浩光＠自宅の日記(2004-12)

2004年12月04日

■ Becky! 2.12で何が改善されたか

Becky! Internet Mail のVersion 2.12 が11月17日にリリースされた。 ●新レイアウト追加などを施した﹁Becky! Internet Mail﹂v2.12が公開, 窓の杜, 2004年11月17日このバージョンでは、フィッシング対策の変更点があったのだが、窓の杜の記事には書かれていないので、書き留めておく。 Becky!の更新履歴には次のように書かれている。 Ver2.11.02 -> Ver2.12 ・HTMLメール中のリンクをクリックした際、標準のブラウザで開くようにした。・HTMLメール中の、リンクの上でマウスを動かした時のリンク先の情報などをステータスバーに表示するようにした。 Becky! Internet Mail Version 2, Readme さてこれはどういう意味だろうか。じつは、Becky! 2.11.02まででは、HTMLメールを表示したとき、HTMLメール中のリンクをクリックすると、そのままBecky!のウィンドウの中でリンク先のページにジャンプする仕様だった。また、リンクのアンカーにマウスポインタを乗せても、リンク先のURLがステータスバーなどに表示されない仕様だった。たとえば、以下の図のように、フィッシングメールを受信したとする。これは HTMLメールで、リンク先が本当はどこなのか、マウスポインタで探っても、見ただけではわからない。

図1: フィッシングメールをBecky! 2.11.02で表示した様子

ここで「Register」と書かれたリンクをクリックすると、次のようにリンク先のページが表示される。

図2: Becky! 2.11.02でHTMLメールのリンク先にジャンプした様子

Becky!の画面にはもとよりアドレスバーがないので、今見ているこのページが、どこのドメインにあるものなのか見ただけでは区別がつかない*1。じつは、この例では、この画面は本物サイトの画面になっていて、https:// が使われて暗号化されているのだが、錠前アイコンも現れないのでそのことがわからないし、クリックしてサーバ証明書を確認することもできない*2。 Outlook Expressでは、メール中のリンクをクリックするとInternet Explorer で開くようになっている。これまで、IEのアドレスバーが偽装されることや、 Outlook Expressのステータスバー︵に表示されるリンク先URL︶が偽装されることが、セキュリティ脆弱性のひとつとしてたびたび指摘され、また、実際にフィッシングの手口としてそうした偽装手段が使われてきたが、 Becky! 2.11.02までのこの仕様は、そうした議論以前のものだった*3。このことは、﹁脆弱性﹂には該当しないのではないか︵明示的あるいは暗黙的な仕様に反すると言えるだけの基となる仕様が存在しない︶と考え、 IPAの脆弱性窓口に届けるのではなしに、Becky!作者の乗松氏に直接メールで、9月下旬ごろ意見として伝えていた。 Becky! 2.12では、リンク先はWebブラウザで開かれるようになり、リンクのアンカーにマウスポインタを乗せると、以下の図のようにステータスバーにリンク先のURLが表示されるようになった*4。

図3: Becky! 2.12でリンクのアンカーにマウスポインタを乗せたときの様子

■ 消費者にセキュリティを説くHTMLメールマガジンの偽善

NTTコミュニケーションズの﹁ネットお役立ちマガジンコム☆ナビ﹂というメールマガジンを購読しているのだが、これがひどい。下の図のように、HTMLメールで配信されてくるのだが、HTMLメール上に入力フォームがあり、送信ボタンがある。

図4: 直接入力情報を送信させるHTMLメールマガジン

送信ボタンを押したときに情報がどこに送信されるのか、わからないようになっている*5。昨年6月14日の日記﹁HTMLメールマガジンのもうひとつの危険性﹂で書いたように、 HTMLメール中に入力フォームを設けるなどというのは、フィッシングに騙されやすい消費者を育成しているようなものだ。しかもこのメールマガジンのタイトルが﹁え!?そんなこともあるの？最新セキュリティ知識度チェック﹂というのだから、臍で茶が沸いてしまう。他にも、﹁ネットのセキュリティは大丈夫？チェックテストで確認しよう！安全対策・ファイアウォール、準備はOK？﹂だの、﹁ネットライフの安全管理、万全度チェック﹂だのいう号もあった。これらの内容は、購読者以外でも、以下のページで閲覧することができる。 ●あなたのネットライフは大丈夫?！ネットライフの安全管理、万全度チェック, NTTコミュニケーションズ, 2004年5月27日 ●え!?そんなこともあるの？最新セキュリティ知識度チェック, NTTコミュニケーションズ, 2004年8月10日 ●ネットのセキュリティは大丈夫？チェックテストで確認しよう！安全対策・ファイアウォール、準備はOK？, NTTコミュニケーションズ, 2004年10月28日これらのマガジン中にはいろいろと注意書きがある。たとえば、 ※メールソフトの種類や設定により各チェックボタン、﹁結果発表!!﹂ボタンが働かない場合があります。その際にはここをクリックしてください。別ページよりチェック5がお楽しみいただけます。と書かれている。最初からそうすればよいのだ。昨年6月6日の日記にも書いていたように、ブロードバンド常時接続時代のいまどき、メールでコンテンツを届ける必要はもはやない。Webサイト上にマガジンを置けばよい。メールは新しい号の公開を通知するだけに使えばよい。メールソフトによってボタンが働かないものがあるというのは、それが危険な行為だから、メールソフトの方で対策されている可能性だってある。他にもこのような注意書きがある。 Becky! Internet Mail﹂をご使用の皆様へ設定のお願いリンク先に書かれていることが、これまた危険な行為をさせようとするものだ。 coden.ntt.com メールマガジンをより快適にご覧いただくために、﹁HTMLメールの表示﹂を﹁テキストに変換して表示﹂にし、添付ファイルを閲覧するかたちでお楽しみいただくことをおすすめいたします。設定の方法は下記の通りです。﹁Becky! Internet Mail﹂をご使用の方へ設定のお願い, NTTコミュニケーションズ

図5: HTMLの添付ファイルをマイコンピュータゾーンで開けと指示している様子
「Becky! Internet Mail」をご使用の方へ設定のお願い」より

一般に、添付ファイルを開くときは、そのファイルタイプや拡張子に注意が必要である。得体の知れないメールの﹁.exe﹂ファイルを開くことは当然危険であるし、﹁.bat﹂や﹁.vbs﹂、﹁.pif﹂、﹁.scr﹂なども危険であり、実際、添付ファイルを開かせようとするウイルスメールで悪用されている手口だ。そして、﹁.htm﹂や﹁.html﹂もそれらと同様に、不用意に開いてはならない拡張子である。なぜなら、これらを開くと、マイコンピュータゾーンでHTMLが開かれる*6ため、安全でないコンテンツが確認なしに起動してしまうからだ。﹁最新セキュリティ知識度チェック﹂と言いながら、﹁HTML添付ファイルを開け﹂と指示するなんてのは、ウイルスに感染しやすい消費者を育成しているようなものだ。なぜわざわざこういうことをさせるのだろうか。﹁より快適にご覧いただくため﹂という表現は、本当の理由を説明することをサボったものであり、ろくな理由でないことが多い*7。次に、10月ごろからは次の注意書きも入るようになった。 ※画像が表示されない場合はここをクリックしてください︵Windows XP SP2をご導入のみなさまへ︶リンク先には次のように書かれている。 ﹁Microsoft Windows XP Service Pack 2︵Windows XP SP2︶﹂をインストール済みのみなさまへ ﹁Microsoft Windows XP Service Pack 2︵Windows XP SP2︶﹂にてOutlook Expressをご利用の場合、ネットお役立ちマガジン﹃コム☆ナビ﹄の画像が正しく表示されないことがあります。その場合には下記の手順で画像を表示させることにより、﹃コム☆ナビ﹄をお楽しみいただけます。﹁Microsoft Windows XP Service Pack 2︵Windows XP SP2︶﹂をインストール済みのみなさまへ, NTTコミュニケーションズここに書くべきことは、なぜこのような操作が必要になっているのか、そして、このメールマガジンの場合はどういう理由で、﹁情報バー﹂をクリックしてかまわないのかの説明だ。つまり、たとえば次のいずれかを書くことになる。

当社のメールマガジンではWebビーコンを使用しておらず、お客様のコンピュータを識別することは行っていません。このことをご理解頂いた上で、﹁情報バー﹂をクリックして画像を表示してください。

もしくは

当社のメールマガジンではWebビーコンを使用しています。お客様のコンピュータを識別するための画像を埋め込んでいます。お客様が画像をダウンロードされた際に、お客様がこのマガジンを閲覧されたものとして、記録する仕組みになっています。そうして集められたお客様の行動履歴は、以下の統計情報を得る目的でのみ使用し、個別のお客様ごとにお客様の行動を分析するといったことは行っていません。 ●何パーセントのお客様がこのメールマガジンを閲覧してくださったか ●メールを発信してからお客様がそれを閲覧されるまでの平均時間このことをご理解頂いた上で、﹁情報バー﹂をクリックして画像を表示してください。

ちなみに、このメールマガジンの場合やはり、Webバグ︵Webビーコン︶が埋め込まれている。ページの末尾に次のように見えない画像が埋め込まれており、なにやら個体識別IDらしきものがURLに埋め込まれている。

<img src='http://go.ab0.jp/go.php?aid=0L5Ry-0pSQP'></body></html>

Webビーコンに関するプライバシーポリシーはどうなっているだろうか。NTTコミュニケーションズのプライバシーポリシーには、﹁セキュリティ宣言﹂と大そうなことが書かれている一方で、Webビーコンに関する記述は存在しない。メールマガジンの登録ページにも記述がない。ついでに書いておくと、プライバシーポリシーにおけるcookieの説明も不適切だ。 クッキー︵Cookies︶について クッキー︵Cookies︶は、お客さまがNTTコミュニケーションズオフィシャルサイトに再度訪問された際、より便利に当サイトを閲覧していただくためのものであり、お客さまのプライバシーを侵害するものではなく、またお客さまのコンピューターへ悪影響を及ぼすことはありません。 NTTコミュニケーションズプライバシーポリシーある行為が、ある個人のプライバシーを侵害するものになるかどうかは、その個人が判断することである。事業者が﹁これはお客様のプライバシーを侵害するものではない﹂といくら勝手に考えていても、それが見当違いであることが少なくない。だからこそプライバシーポリシーの開示が必要なのであって、﹁侵害するものではない﹂と宣言するだけで済むんだったら、プライバシーポリシーなぞいらない。﹁クッキー︵Cookies︶は……ありません﹂と、cookie一般がそういう性質のものでないかのように言っているのも大間違いだ。何もわかっていない人が、意味もわからずこれを書かされている様子が窺える。書くべきことは、どのページでどのようにcookieを使っていて、それはこれこれの結果をもたらすが、当社はこれこれの形でしか使わないようにしている ――といったことだ。﹁より便利に﹂とか﹁より快適に﹂だの﹁より良いお客様サービス﹂だのいう表現は、裏側に説明されていない何かがあるとみてよいだろう。

本日のリンク元 TrackBack(1)

2004年12月05日

■ ヤフーからの通知を装った日本語フィッシングで何が起きていたか

先月の15日、ヤフージャパンのWebメールユーザをターゲットにした、日本語フィッシング事件が起きているのが確認された。そこでは、Yahoo! Mailのクロスサイトスクリプティング脆弱性︵XSS脆弱性︶を突いて、偽メールと見破られにくくする手口が使われていた。さらに驚くべき仕掛けも潜んでいた。フィッシング詐欺を防止するには、どんな事例が発生しているのかを、具体的に包み隠さず公開して、消費者や事業者に周知していくことが必要だと考える。丸山さんからもリクエストがあったので、何があったのかを以下に詳細に示すことにする。

クロスサイトスクリプティングによる偽装

図1は、あるYahoo! Mailのユーザ宛に送られてきたフィッシングメールである。実物を受信した方から転送して頂いたものを、自分で自分のYahoo! Mail アカウントに送信したもので、Subject:が﹁TEST﹂になっているのは、転送のときに付け替えたものだ。オリジナルのSubject:とFrom:は以下のようになっていた。

From: "Yahoo! JAPAN " <wallet-help@yahoo.co.jp>
Subject: Yahoo! JAPAN - 有料コンテンツご利用停止に関するお知らせ

図1: ヤフーのWebメールに送られていたフィッシングメールのコピー

ここで、矢印部分にあるリンク「Yahoo!ウォレット登録情報の確認・変更」をクリックしたところ、図2の画面が現れた。

図2: クリックすると現れた偽のログイン画面

さて、これは偽サイトに設置された偽のログイン画面なのだが、これが偽だと見抜けるだろうか？まず、アドレスバーのURLのホスト名が、﹁jp.f25.mail.yahoo.co.jp﹂となっている。そして、パスワード入力欄の上には既に自分のIDが示されている。右の方には﹁もし takagi_hiromistu さんではない場合は﹂などとも書かれていて、もっともらしい。偽だということは、画面の中央部分で右クリックしてプロパティを調べるとすぐに判明する。プロパティで確認したこの画面の中央部分のURLは、

http://yahoo-com-jp.mine.nu:1649/jp/...

というものだった。 Windows XP SP2のInternet Explorerを使用しているので、アドレスバーが偽装されているわけではないはずだ︵未知の脆弱性が悪用されているのでない限り︶。なぜこのようなこと、つまり、yahoo.co.jpドメインの画面上に偽サイトの画面を表示させることができたのか。この画面全体のHTMLソースを見てみた︵表示メニューから﹁ソース﹂︶ところ、次のようになっていた。

<frameset row="*">
<frame src="http://yahoo-com-jp.mine.nu:1649/（略）&user=takagi_hiromitsu">
</frameset>

つまり、画面全域が1つのフレームになっていて、フレームとして偽サイトが表示されているということだ。ファイルメニューからプロパティを確認すると、﹁jp.f25.mail.yahoo.co.jp﹂となっており、アドレスバーが偽装されているわけではないことがわかる。答えはというと、これは、メール中に書かれていたJavaScriptの実行によって実現されていたのである。 JavaScriptを実行させられるならば、そのページのHTMLを自由に差し替えることができる。たとえば、

document.write('<frameset row="*"> ...');

といった文を実行させることができれば、そのページは、フレームセットに差し替えられることになる*1。本来ならば、HTMLメール中に書かれたJavaScriptが実行されるようなことがあってはならない。なぜなら、Webメールのほとんどは、cookieによりセッション追跡︵同じ人からのアクセスであることを判別︶しているため、もし、メールに書かれたJavaScriptが実行されるなら、cookieを盗み出すことができてしまうため、セッションハイジャック攻撃により、メールを盗み読まれる危険があることになる。したがって、Webメールサービスのほとんどは、 JavaScript︵や VBScript︶が動かないように対策をしているはずである。その対策に漏れがあって、何らかの方法でスクリプトが動いてしまうならば、それは﹁クロスサイトスクリプティング脆弱性﹂と呼ばれる。HotmailやYahoo! Mailに、1999年ごろからたびたびセキュリティホールが発見されては修正が繰り返されてきたのは、そのほとんどがこのXSS脆弱性が原因であった。 ●HotmailとYahoo Mailを悩ますフィルタの欠陥, CNET Japan, 2004年3月24日﹁HotmailとYahooは、あらゆる手段を用いて電子メールのなかにあるスクリプトの実行を阻止しており、両サービスでは受信メッセージに含まれるHTMLコンテンツにフィルタをかけている。我々は、スクリプトを実行させるためにフィルタを回避する方法を発見した﹂︵Dagon︶この脆弱性は、技術的にはクロスサイトスクリプトの欠陥に分類される問題だ。︵略︶ ●HotmailとYahoo! Mailにクロスサイトスクリプティングの脆弱性 , セキュリティホールmemo, 2004年3月24日 ●Vulnerability Note VU#707100: Multiple web-based email services fail to filter malicious characters when the message contains cascading style sheet character escaping, セキュリティホールmemo, 2003年12月12日 ●MS、Hotmailの脆弱性修正, セキュリティホールmemo, 2003年10月16日 ...︵略︶... ●Yet another Hotmail security hole - injecting JavaScript using "jAvascript:", セキュリティホールmemo, 2000年1月18日 ●Hotmail もの3題, セキュリティホールmemo, 2000年1月7日 ●HotmailにJavaScript関連の新たなセキュリティホール, セキュリティホールmemo, 1999年9月16日今回のヤフーをターゲットにしたフィッシングメールで使われていた、 JavaScriptを実行させる方法は、次のものだった。

<style onload="スクリプト文"></style>

スクリプト実行の防止において、﹁onload﹂に対策をするのは基本中の基本と思われるのだが、これがフィルタリングされない穴が残っていたというのは意外だった。調べてみたところ、米 yahoo.com のWebメールにおいても同じ脆弱性が存在していた。これはまずいと思ったので、急ぎ、15日の深夜から16日にかけて、ヤフージャパンと米Yahoo!の一般向け質問窓口に対して、この脆弱性の存在を伝えるメッセージを送った。ヤフージャパンでは16日のうちに修正され、米Yahoo!では数日後には修正されていた。

入力したパスワードが本物サイトに中継される

このフィッシング事例が巧妙だったのは、それだけではなかった。図2の画面で、わざと間違ったパスワードを入力してみたところ、図3の画面が現れた。

図3: 間違ったパスワードを入力するとエラーとなる様子

10回ほど、自分のIDに対して間違ったパスワードを入れてみたところ、10回とも﹁パスワードが正しくありません﹂というエラーになった。そして11回目に、正しいパスワードを入れてみたところ、図4の画面に進んだ。

図4: 正しいパスワードを入れることで「ログイン」できた様子

こうした挙動を示したのは、偽サイトが、入力されたパスワードを本物サイトに中継送信して、パスワードが本物かどうかを確認する仕掛けになっていたとしか考えられない。

何気なくパスワードを間違えたりして、このような挙動を見た人は、正しいパスワードを入れたとき、本物サイトにログインしている錯覚に陥るだろう。

暗証番号（セキュリティキー）には何を入れても通過するようだったが、この後現れる画面は、図5のようになっており、すっかり本物サイトにログインしていると錯覚した人は、疑いもなく、これらの情報を入力してしまうのだろう。

図5: カード番号などの情報を入力させようとしている画面

図2〜4の画面は、本物のヤフーのサイトに実在する画面とそっくりだが、図5 のように、カードの暗証番号（ATMでのキャッシングに使用するもの）を求める画面は存在しないようだ。冷静に考えれば、そんな情報をWebに登録するのは変なのだが、ログインしていると錯覚していれば入れてしまうのだろう。

ちなみに、図4の画面をサブフレームだけ表示させたのが図6である。偽サイトのURLで動いていることがわかる。URLのパラメータ部分には、ユーザIDと、入力したパスワード*2が渡されているのが見える。

図6: サブフレームの偽サイトだけを表示させた様子

この事例は、その後以下のように報道された。 ●Yahoo! JAPANをかたる日本語フィッシングメールが登場、手口はさらに巧妙に, ITmedia ニュース, 2004年11月16日日本語で書かれたフィッシングメールとしては、先週、VISAをかたるものが登場したばかりだ。これに続いて、 別のテクニックを用いた手法が登場したことになる。しかも、 Webメールのユーザーに対しHTML形式のメールを送り付けるという点で、さらに巧妙だ。なお、Yahoo! JAPANと同様、JavaScriptを悪用され、﹁それらしき﹂Webサイトを偽造されるという脆弱性を残したWebサイトは、他にも存在すると考えられる。自衛手段としては、 ●一見すると本物のサイト、Yahoo! JAPANを騙るフィッシングが悪質化, INTERNET Watch, 2004年11月17日今回のフィッシングでは、手口が悪質化している。JavaScriptを悪用し、アドレスバーには正規のYahoo! JAPANのURLを表示したままで、Webページ部分だけを偽のページに置き換えているという。 ●国内ユーザーを狙ったフィッシングが続出，アドレス・バーを偽装する場合も VISAやヤフーをかたる“日本語フィッシング”，サイト運用者も注意が必要, 日経IT Pro, 2004年11月18日このフィッシングの特徴は，メールで誘導した偽サイトのアドレス・バーを “偽装”すること。JavaScriptやフレームを使って，アドレス・バーにはヤフーのURLを表示させ，ページの中身にだけ偽サイトのページ︵フレーム︶を表示させる。同社では詳細は明らかにしていないものの，Yahoo! Japan ︵Yahoo!メール︶サイトの不具合を悪用しているようだ。︵略︶ヤフーによると，11月15日に上記の不具合を修正したという。このため，現在では全く同じ手口は使えなくなっている。︵略︶ユーザーばかりではなく，サイトの開発者／運用者も注意が必要だ。フィッシングに悪用される不具合――例えば，クロスサイト・スクリプティングの脆弱性など――がないことを改めて確認したい。マスメディアは、今回の原因が、ヤフーのXSS脆弱性にあったということを、ズバリ書いてはくれなかった*3。日経IT Proの記事も、ITmediaの記事も、わかっていながらぼかして書かれている様子が見て取れる。とくにITmediaの記事は、本当のことを書きたくてたまらないが、クロスサイトスクリプティングという言葉だけは避けて書かれているように見える。

■ Yahoo! Mailのフィッシング事例から得られる教訓

原因の究明が遅れていた可能性

11月15日に、セキュリティホールmemo メーリングリストに、このフィッシングにひっかかってしまったという報告が流れたことをきっかけとして、ある方が私に、フィッシングメールの実物を提供してくださったことから、原因がXSS脆弱性にあることがわかり、 memoメーリングリストでその事実を広く伝えると同時に、ヤフーに対して脆弱性の存在を通知した。タイミング的には、それによってヤフーが対策をとったように見える。一方、﹁有料コンテンツのご利用を停止﹂でGoogle検索してみたところ、2ちゃんねるの﹁Yahoo!オークションをかたるメールにご注意﹂というスレッドで、同じ文面のフィッシングメールが9月29日の時点で既に出回っていたことが記録されているのが見つかった。

8：名無しさん（新規） ：04/09/29 22:10:43 ID:fA+H10Jx
きたきた！！
題名：Yahoo! JAPAN -- 有料コンテ ンツご利用停止に関するお 知らせ
発信先：wallet-support@yahoo-inc.co.jp←これ自体おかしい
いつもYahoo! JAPANをご利用いただきありがとうございます。

このたび、お客様がご利用のYahoo! JAPAN 有料コンテンツのご利用
を停止させていただきましたことをご連絡いたします。
現在お客様がYahoo!ウォレットでYahoo!プレミアム会員費などのお支
払いにご利用中のクレジットカードにつきまして、カード発行会社よ
り、弊社へご登録のクレジットカード情報では請求が行えないとの連
絡をいただきました。
そのため、ご利用になられていたYahoo!プレミアム会員費など、お支
払いが必要なサービスについてご利用停止処理を行わせていただきま
した次第です。
なお、お客様にはご利用になられていた有料コンテンツを、再度ぜひ
ご利用いただきたいと存じます。その際にはお手数ではございますが、
お客様のYahoo!ウォレット登録お支払い方法のご変更手続きをお願い
いたします。
お客様のYahoo!ウォレットご登録内容の変更については、以下の確認
画面右側に表示されます「お支払い情報の変更」をクリックして表示
される画面よりお手続きいただけます。

とび先アドレスはここです。
http://yah-jp.ath.cx:1666/yahoo.co.jp/step1.php

他にも、ここのブログの9月30日のエントリに、同じ文面のフィッシングメールの引用とともに、次のように書かれている。ほんと一見Yahoo!そのまんま。でさらにすごいことに、ここで間違ったパスワードを入れても認証されない！どうもパスワードが入力された際に、偽サイトのプログラムで本物のYahoo!にログインできるかチェックしているようだ。このことからして、9月30日の時点で既に、パスワードの本物サイトへの中継が行われていたように読める。このときからXSS脆弱性が突かれていた確証はないが、その可能性は高いのではなかろうか。もしそうなのならば、ヤフーは、このフィッシングメールの実物を見ることによって、原因を突き止め、11月16日にとったのと同じ対策をとることで、早い段階でこの詐欺をやめさせることができたのではないだろうか。INTERNET Watchの記事によれば、﹁千数百件の報告がヤフーに寄せられている﹂といい、被害をもっと小さくできた可能性があるのではないか。 XSS脆弱性を修正せずにいると、詐欺師にナメられて、いつまでも格好の餌食にされてしまうことになる。

﹁フィッシングは防ぎようがない﹂という考えが対策を怠らせる

最近、フィッシング詐欺に注意を呼びかける事業者が増えてきているが、お客さまの個人情報をEメールでお伺いすることはありません。といったフレーズがテンプレート化して、考えなしにただ同じ文章を掲載するだけで満足してしまう事業者が現れてきているように思える。フィッシングで詐称された事業者の広報担当者からすれば、﹁こんなの防ぎようがない﹂と思うのかもしれない。しかし、Yahoo! Mailの事例のように、サイトの脆弱性が突かれたことが原因で、騙されやすい偽サイトを作られてしまう可能性があるのだから、﹁防ぎようがない﹂で思考を止めてしまってはならない。マスメディアは、高度な手口に対して防ぎようがないかのような印象を抱かせる報道を避けるべきである。過去にも、ウイルスが自力で防げないものであるかのような報道をして、ウイルス対策ソフトの売り上げに貢献したことがあったが、まずやるべきことは脆弱性の修正であるということを、常に基本としておさえておくべきだ。

XSS脆弱性のもうひとつの脅威が実証されてしまった

2000年2月にCERT/CCからCA-2000-02 として発表されたXSS脆弱性。SecurIT-Advisory 2001-001で注意を呼びかけたときは、 cookieの漏洩によるセッションハイジャックの危険性に焦点を当てて、軽微な問題ではないことを訴えた。その後、多くの人たちによって、この脆弱性があちこちのサイトで発見されることとなったが、cookieを使っていないサイトでは、﹁たいした問題ではない﹂とされることが多かった。そうしたとき、﹁偽の情報を本物ドメインの画面に表示させられる﹂という危険性があると訴えられていたが、﹁そんな罠をしかける人、本当にいるの？﹂とか、﹁そんな罠に騙される人いるの？﹂という反応が少なくなかった。しかし、図らずも、﹁フィッシング詐欺﹂という名前まで付く攻撃手法が蔓延してしまい、そのときの危惧が現実のものとなってしまった。クロスサイトスクリプティングは、フィッシング詐欺に悪用される脆弱性であり、顧客をフィッシング詐欺から守りたい事業者が自社のサイトから排除せねばならない脆弱性である。このことを広く周知するべきであろう。今回の件があきらかになる少し前に、次の報道が出ていた。 ●﹁金融機関サイトのコンテンツを偽物にすりかえる﹂，新たなフィッシング手口を英企業が警告, 日経IT Pro, 2004年11月9日 ●上級者でも見破れない悪質なフィッシングの手口を英SurfControlが警告, INTERNET Watch, 2004年11月9日 ●“本物のサイト”を使う新手のフィッシング詐欺, ITmedia ニュース, 2004年11月11日記事中には﹁検索スクリプトの欠陥を悪用﹂﹁検索スクリプトの脆弱性を悪用﹂﹁検索サーバの脆弱性﹂とあるが、これは、検索のキーワード入力欄に存在するクロスサイトスクリプティング脆弱性のことを言っているのだと思われる。

イーバンク銀行のキーワード確認機能はやっぱりフィッシング対策にならない

イーバンク銀行がフィッシング詐欺対策と銘打って導入したキーワード確認機能が、対策になっていないことは、10月11日の日記﹁素人がやってはいけないセキュリティの﹁大発明﹂﹂で書いた。つまり、イーバンク銀行のこのシステムは、パスワードの前半分だけを入力したときに、自分だけが知っているはずのキーワードが画面に現れれば、﹁本物サイトだと信じてよい﹂という趣旨なのだが、偽サイトが、入力されたパスワードを本物サイトに中継するようになっていたら、偽サイト上にキーワードが表示されてしまうだろうというものだった。今回の、Yahoo! Mailで起きたフィッシングの事例では、まさに、入力したパスワードを本物サイトに中継することによって、本物のログイン画面であるかのような信憑性を作り出していた。間違ったパスワードで入れず、正しいパスワードで入れたからといって、本物サイトとは限らないのである。このような事実があるのだから、イーバンク銀行のキーワード確認機能を普段から使わせることは、騙されやすい消費者を育成することになりかねない。

ユーザへの注意文は専門家に書かせた方がよい

今回の事例の原因がはっきりするより前の段階で、ヤフーは﹁Yahoo! JAPAN IDとパスワードを不正に盗み取る悪質なメールに関するご注意﹂という文書を出していたのだが、この文書があまりにも拙すぎた。 ■﹁有料コンテンツご利用停止に関するお知らせ﹂このメールには個人情報と取得する悪質なウェブページが記載されております。悪質なウェブページのURL‥ ｈｔｔｐ‥／／ｅｄｉｔ．ｐａｙｍｅｎｔ．ｙａｈｏｏ．ｃｏ．ｊｐ／ｃｏｎｆｉｇ／ｗａｌｌｅｔ＿ｃｏｎｆｉｒｍ Yahoo! JAPAN IDとパスワードを不正に盗み取る悪質なメールに関するご注意, ヤフーと書かれているのだが、そのURLは、本物のヤフーサイトに実在するアドレスじゃないか。そのアドレスにジャンプするかのように装って、違うところへアクセスさせているのに、﹁悪質なウェブページのURL﹂としてそれを書いてどうするのだ？

図7: ヤフーの頓珍漢な注意文

ようするに、過去の別の注意文の Yahoo! JAPANのページを騙り、お客様のYahoo! JAPAN IDとパスワードを不正に盗み取る悪質なウェブページが報告されました。該当の悪質なウェブページのURLは次のとおりです。 Yahoo! JAPANとは無関係の悪質なウェブページｈｔｔｐ‥／／ｆｒｅｅ．ｆｒｓｓ1．ｎｅｔ／￣ａｕｃｔｉｏｎ／ｙａｈｏｏ／ Yahoo! JAPANを騙るページにご注意ください, ヤフーをテンプレートにして、URLのところだけ書き換えたわけだ。惰性で仕事をしているか、そうでなければ、本当に何もわからない素人さんが書いたとしか思えない。また、ヤフーは、これまでにフィッシングに対する注意文を多数掲載してきているが、いずれにも日付が書かれていないので、今起きている話なのか、既に終わった話になっているのかが判別できない。日付を書かない理由がわからないのだが、何か意味があるのだろうか。

■ 「メールで尋ねることはしていない」という一つ覚え

一方、イーバンク銀行では、別のフィッシング事例が発生していた。 ●﹁入金お知らせ﹂メールに注意 - イーバンク銀行を騙るフィッシング詐欺, MYCOM PCWeb, 2004年11月1日今回のメールは、件名が﹁イーバンク銀行からのお知らせ[入金がありました]﹂となっており、テキスト形式で送信される。同銀行では、メールアドレスを登録している利用者に対し、入金時や出金時などに通知メールを送信しているが、今回のフィッシング詐欺メールは実際に入金時に送られるメールと同じ件名が使われていた。メール内にはURLが記載されており、そこにアクセスするとログイン画面が表示され、支店番号・口座番号・ログインパスワードの入力が促され、さらに﹁システム上の確認﹂と称して暗証番号を入力させようとする。メールアドレスやメール記載のURLがイーバンク銀行のものではなかったほか、同銀行はメールからログインパスワード・暗証番号を入力させるようなことはしていないという。 ●イーバンク銀行の入金通知メールを偽装するフィッシング詐欺メール発生, INTERNET Watch, 2004年11月1日イーバンク銀行では、﹁そもそも、利用者のログインパスワードや暗証番号をメールで尋ねることはしていない﹂。その上で、フィッシング詐欺メールに騙されないようにするには、﹁不審なメールに記載されたURLを直接クリックするのではなく、あらかじめお気に入りなどに登録したイーバンク銀行のWeb サイトからアクセスすること﹂などを利用者側の対策として挙げた。しかし、イーバンク銀行から﹁メルマネ﹂で送金があると、次のようなメールが来る仕組みになっている。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
タカギ　ヒロミツ様  (takagi@mail1.accsnet.ne.jp)  から
送金がありました。
(No.20040921XXXXXXXXXXXX-XXX)

送金内容：送金のテスト
送金日時： 2004/09/21 XX:XX:XX
※送金の受取手続きは45日以内に行ってください。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
（略）
▼▼　タカギ　ヒロミツ様からの送金の受取手続きは
　　　　　　　　　　　　　　　　　　　　 下記URLを押してください　▼▼
http://merumane.ebank.co.jp/ebk/ebs?RECV=OK&ESCROW_NUM=20040921XXXXXXXXXXXX
（以下略）

これでも、﹁メールからログインパスワード・暗証番号を入力させるようなことはしていない﹂というのだろうか。やはり、こういうサービスを提供するのなら、通知メールにS/MIME署名するようにするしかないだろう。

*1 ユーザID「takagi_hiromitsu」が、偽サイトのCGIへのパラメータとして渡されていたのも、JavaScriptを使って、メール画面のHTMLから切り出して渡すようになっていた。もっとも、これは、フィッシングメールをあて先ごとに内容を変えて送信すれば、あて先のユーザIDをメール中に埋め込めるので、 XSS脆弱性がなかったとしても、ユーザIDが自動で現れることは起き得る。

*2 「flower」とあるのは、このとき臨時に付けたパスワード。

*3 証拠を得られなかったのかもしれない。ヤフーが認めなければ書けないということなのだろう。

本日のリンク元 TrackBacks(100)

2004年12月10日

■ 日本版Anti-Phishing Working Groupは誕生し得るのか？

前回の日記では、﹁原因の究明が遅れていた可能性﹂として、このことからして、9月30日の時点で既に、パスワードの本物サイトへの中継が行われていたように読める。このときからXSS脆弱性が突かれていた確証はないが、その可能性は高いのではなかろうか。と書いたが、リンク元をたどってあちこちを見てみたところ、﹁悪徳商法・サイドビジネス会議室﹂の記事番号124311に以下の記述があった。 124311 Re:いやそーでなくてにょ☆ 9/30-19:55 ︵略︶こないだそこをクリックしたらリンク切れだったんですが、いまやってみたら、 http://jp.f16.mail.yahoo.co.jp/ym/ShowLetter? box=Inbox&MsgId=3539_134227_10325_794_︵略︶と表示されて、Yahoo!WALLETのパスワード要求画面みたいなんですが、︵略︶悪徳商法？マニアックス, 悪徳商法・サイドビジネス会議室, 記事番号124311 つまり、9月30日の時点でも、偽のパスワード要求画面が﹁ http://jp.f16.mail.yahoo.co.jp/ym/ShowLetter?……﹂のURLのページ上に表示されていたということで、11月15日の状況と︵少なくとも見た目の上では︶同じだったようだ。 1か月半もの間これに気づけなかったのは悔やまれる。ここの掲示板を見ていれば……。やはり、フィッシングに対抗するには、こうした事例情報がどこかに集約される仕組みが必要であろう。英語圏では、Anti-Phishing Working Group (APWG)という団体が昨年からできている。この団体は、ターゲットにされる事業者たちと、ITベンダーなどから構成されているようだ。 ATWGでは、﹁Recent Phishing Attacks﹂として、フィッシングの偽メールと偽サイトの実物のキャプチャ画像を展示している。つまり、実例を広く周知することによって、消費者の警戒を促し、事業者が対策をとるためのヒントを提供しているのだろう。クロスサイトスクリプティングについても、今年3月の同グループのプレスリリースで、既に言及されていた。 "Phishing attacks continue to increase both in number and in sophistication," said Dave Jevans, Chairman of the Anti-Phishing Working Group and a Senior Vice President at Tumbleweed Communications. "We are seeing more use of Java-script, pop-ups and cross-site scripting techniques to fool even sophisticated users of the Internet. The Anti-Phishing Working Group, with over 200 members, was founded as an industry resource to address this critical challenge to individuals and companies on the Internet. At stake is our very trust that the Internet can be relied upon for safe and secure commerce and communications." Anti-Phishing Working Group PRESS RELEASE, 19-Mar-2004 日本ではどうだろうか。このところマスメディアから、フィッシングメールの実物を持っていないかとの問い合わせを何件か受けた。実際にどういう画面が現れるのか、報道しようにも実物が手に入らないのだという。先月、ビザ・インターナショナル東京事務所がターゲットにされた事例があったが、小耳にはさんだところによると、ビザ・インターナショナルに実物の提供を求めても、﹁ない﹂との返事が来るのだそうだ。あれだけ多く出回ったのに、本当に入手できていないのならそれも問題だし、あるけど出さないというのだとしたら、それはどうなのか。英語圏では、業界の集まりが自ら実例を公表することによって防止を図っている。日本の企業風土が﹁とりあえず隠しておく﹂なのかどうかは知らないが、日本でAPWGと同じようにできるのかどうか……。経済産業省が、﹁フィッシング・メール対策連絡会議﹂を設置して、第一回の会合を開いたと報道されている。 ●経産省がフィッシング対策会議、Yahoo！や楽天も参加, ITmedia 速報, 2004年12月10日 官民で関連情報の共有を図るのが目的。第1回では国内外でのフィッシング詐欺事例を把握し、対応策を検討した。﹁情報の共有﹂とは、業界内だけの秘密事項としての共有ということなのか、それとも、APWGのように消費者とも共有していくということなのか。ロゴを盗用するなどして実物サイトそっくりの画面になっているということこそが、フィッシングの特徴であるところで、社名を隠した架空の偽サイト画面を消費者に見せても、啓発にならない。

■ mod_rubyなしではcounter.rbが3万回/日程度のアクセスに耐えられない

今週火曜日、昼の12時台に、この日記が﹁503 Service Temporarily Unavailable﹂となってときどきアクセスできなくなっているとの通報があった。この日記のアクセスはいつも平日の昼休み時間がピークになっているのだが、この日は、12:00〜13:00に4,800件のページビュー*1があった。たしかに、これまでで最多のアクセスであるが、1秒あたり数件程度以内なので、これで止まってしまうのは正常でない。とりあえず、昼休み中はrubyプロセスをときどきkillして凌いだ。その後、どうにか正常になっていたようだが、夜22時ごろから再び﹁503 Service Temporarily Unavailable﹂が頻発し始め、こんどはkillしても、killしても、 rubyプロセスがすぐに数百個に達してしまい、これでは凌げなくなった。昼よりはアクセス数が少ないのにもかかわらずだ。

06:  349          18: 2616
07:  525          19: 2390
08: 1331          20: 2296
09: 2166          21: 2483
10: 2455          22: 3228
11: 2864          23: 3191
12: 4865          00: 2424
13: 3997          01: 1710
14: 2751          02:  901
15: 2615          03:  593
16: 2535          04:  320
17: 2752          05:  278

この日の1時間あたりのページビュー

原因がtDiaryの﹁counter.rb﹂プラグインにあるとわかった。counter.rbプラグインを外すと、rubyプロセスはどんどん減少し、通常状態にまで戻る。 counter.rbは、cache/counter/counter.dat というファイルに、counter.rbが記憶するデータ*2のオブジェクトを PStoreで保存するようになっている。このファイルのサイズが、23時ごろの時点で、2.7 MBにもなっていた。 mod_rubyを使っていない︵このサーバでは使えない︶ので、このファイルは、アクセスがあるたびに読み出され、再び書き戻されているのだろう。しかも、 counter.rbのコードを読んでみたところ、毎回バックアップファイルをコピーして作っているようだった。その間、ロックがかかっている。というわけで、counter.rbを改造して、IPアドレスを記憶しないようにし、 counter.datを一旦クリアして事態を回避した。そのため、次の日、﹁訪問者数昨日:﹂が﹁0﹂となってしまったが、ちなみにこの値は、本来は﹁32112﹂となるところだった。

*1 「訪問者数」とは数え方が異なる。「/diary/」と「/????????.html」へのアクセス数。

*2 cookieを受け入れない設定の閲覧者の場合に、同じIP アドレスからのアクセスを一定期間、重複カウントしない仕組みを実現するため、IPアドレスと時刻が一時的に記憶されている。

本日のリンク元 TrackBack(1)

2004年12月15日

■ ソニー銀行がアドレスバーとステータスバーを出すようになっていた

久しぶりにソニー銀行を利用しようとしたところ、ログイン画面でアドレスバーとステータスバーが現れるようになっているのに気づいた。いつからだろう？と調べてみると、お知らせが11月15日に出ていた。そこにこう書かれている。 ●﹁フィッシング詐欺﹂にご注意ください, ソニー銀行, 2004年11月15日お客さまがアクセスしているページが正当な当社のウェブサイトであることをご確認いただくために、ログイン時やログイン後のサービスサイトの一部において、ブラウザーウィンドウ上部のアドレスバー、下部のステータスバーを表示するようにウィンドウ表示方法の変更を行ないました。なにはともあれよかった。他の金融機関がどうなっているか、今一度全部調べてみるとよいかもしれない。関連記事等: ●ITコマースの脆弱な現実と危機回避に向けた展望, 情報処理学会第63回全国大会特別トラック, 2001年9月26日 3.2 なりすましに無警戒な銀行のログイン画面 ネット専業銀行として最近開業したある銀行のサービスサイトでは，ログインボタンを押すと図4のようなウィンドウが現れるようになっている．ユーザはここに口座番号とパスワードを入力するわけであるが，このウィンドウは図のように，メニューや制御ボタン，そして﹁アドレスバー﹂と﹁ステータスバー﹂がウィンドウから削られている．これは， JavaScript を用いて意図的に現れないように作り込まれている．ほとんどのウェブブラウザは，通常，﹁アドレスバー﹂に，現在表示中のページのURL を示すように作られている．これは，﹁今見ているところはどこか？﹂ということをユーザが常に確認できるようにと用意された重要な機能である．また，﹁ステータスバー﹂には， SSL 通信をしているかどうかを示す鍵のアイコンがあるはずである．本来ならば，ユーザはこのアイコンを確認することで，現在アクセス中のページが保護されていることを確認できるし，このアイコンをクリックすることで証明書の内容を表示させてそのサーバが偽物でないことを確認できるはずなのに，それがわざわざ非表示になっている．もしこの銀行を装った偽のウィンドウを出現させる悪意のあるサイトが存在していたらどうだろうか．﹁こちらは○○銀行です．只今キャンペーン実施中です．今ログインして頂いた方には粗品を差し上げます．﹂といった電子メールやバナー広告に誘われて，指定のサイトにアクセスしたときに，同じデザインのウィンドウが現れるといったことはあり得るだろう．このとき，日頃から図4のウィンドウに慣らされているユーザは，﹁右クリック＋プロパティ﹂によってそのウィンドウのURL のドメインを確かめようとするだろうか．これを確かめることなく，偽のウィンドウに口座番号とパスワードを入力してしまえば，それは悪意ある者によって収集されてしまう．偽のウィンドウが，口座番号とパスワードを収集した後，本物の銀行のページにリダイレクトするような仕掛けになっていれば，ユーザは罠にはまったことに気付きもしないだろう．このことについて，当該銀行のカスタマーセンターに問い合わせてみた．﹁この問い合わせは情報処理学会の論文を書く際の資料とするためのものである﹂旨を伝えて問い合わせ，最初の電話から最終回答までに5日間かかって得られた回答が図5である． ●第4回情報セキュリティ・シンポジウムの模様― インターネットを利用した金融サービスの情報セキュリティ対策―, 日本銀行金融研究所, 金融研究第21巻第2号, p.168, 2002年6月こうしたシステム面の問題以外にも、現在のインターネット・バンキングには、セキュリティを損ないかねない、いくつかの問題が存在する。例えば、一部の金融機関が提供するインターネット・バンキングでは、ログイン時に、強制的にブラウザーの表示設定が﹁アドレス・バーを表示しない﹂に変更され、現在接続しているサイトのアドレスが隠されてしまう。ブラウザーを用いてウエブ・サイトに接続する場合、利用者は、自分が確かに意図したサイトに接続しているかどうかをアドレス・バーで確認することができるが、これらの金融機関のサイトに接続した場合、その確認ができないため、﹁偽ウィンドウによる攻撃﹂に対して脆弱になってしまう。この攻撃は、攻撃者が利用者を罠にかけて、利用者のパソコンの画面上に当該金融機関のウエブ・ページに似せた偽ウィンドウを開かせ、そこから入力させたパスワード等を攻撃者のサイトに転送させて情報を奪取するものである。普段からアドレス・バーが表示される設定となっていれば、利用者は表示されたアドレスを確認することでウィンドウが本物か偽者かを判断することができる。しかし、これらの金融機関は、常にアドレス・バーを隠すことによって、利用者がアドレスを確認しないように習慣付けてしまっていることになる。さらに、一部の金融機関のインターネット・バンキングにおいては、利用者がアドレス・バー以外の方法︵マウス・ボタンを右クリックし、ページの属性情報を表示させる等︶によりアドレスを確認しようとしても、そのための操作がシステム的に禁止されてしまっている。このように、現在のインターネット・バンキングのシステムを、ウエブ・アプリケーションの安全性という観点から評価すると、十分な対策が講じられているとは言い難い面がある。 ●警鐘●危険なネット銀行を作るな, なりすまし対策に死角あり，144行の調査で判明, 日経システム構築, 2003年5月号 サイトなりすましの死角 今回の調査でもう一つ目立ったのが，身元を隠すサイトの多さである。確認できただけでも，144行中32行がログイン画面のアドレス・バーを非表示にしており，うち18行が右クリックを禁止している︵表1-C︶。こうしたサイトは，サイト自体をなりすまされるリスクがある。銀行のサイトに似た偽サイトを立ち上げられると，ID/パスワードを盗まれてしまう。例えば﹁キャンペーン実施中！﹂などの偽メールを配信し，そこから偽サイトに顧客を導く。そうとは知らず顧客は偽サイトにID/パスワードを送信してしまう。送信後は﹁ただいまサービス停止中です﹂といった画面を表示したり，正規のサイトへ中継したりすれば，すぐに気付きにくい。アクセスを中継すれば，不正な資金移動までされてしまう可能性もある。 ●phishing――だましのメールに釣られるな, 日経IT Pro 記者の眼, 2004年3月15日 Webでサービスを提供する企業も考える必要がある。その最たるものが，前述の﹁アドレス・バー﹂を隠すページである。﹁アウトソーシングしているので，その企業のドメインではない。アドレス・バーを表示させると，ユーザーが不安がるだろうから非表示にしている﹂といった理由から隠していると筆者には思われる。しかし，そのような余計な配慮が，アドレス・バーを非表示にしていても怪しく感じさせない土壌を作っているように思えてならない。アウトソーシングしている場合には，その旨をきちんとユーザーに分かりやすく説明した上で，堂々とアドレス・バーを表示すべきだろう。 ●情報技術の死角安全対策を問う(上) オンライン銀行――フィッシング詐欺に注意, 日経産業新聞 2004年8月23日先端技術面全国の主要銀行百二十行について、フィッシング対策に重要と思われる項目を調べた。調査内容は専門家が指摘する︵1︶公式サイトに接続しているか確認できる﹁アドレスバー﹂を隠していないか︵2︶証明書や暗号化の有無が確認できる﹁ステータスバー﹂を隠していないか︵3︶公式サイトと偽サイトを混同する原因になりやすい﹁複数ドメイン名﹂を使っていないか――の三点だ。その結果、満点だったのはみずほ銀行、ＵＦＪ銀行、三井住友銀行、シティバンク銀行、ジャパンネット銀行、中央三井信託銀行、住友信託銀行、北陸銀行の八行だけだった。アドレスバーを隠していたのは東京三菱銀行や新生銀行など。ステータスバーを隠していたのはソニー銀行やイーバンク銀行など。これらを隠す理由はデザイン上の理由や顧客の誤操作を防ぐためとみられる。しかし、安全性の面では疑問がある。︵略︶米シティバンクの顧客を狙ったフィッシングに使われた電子メールを解析した。︵略︶ポップアップ・ウィンドウにはアドレスバーやステータスバーがないので、操作してアドレスなどを調べ、公式ページのものと比べないと本物かどうかは分からない。しかし、銀行の公式ページがアドレスバーなどを隠していると確認できないし、隠しているページに利用者が慣れてしまうと、だまされやすくなる。利用者の自衛策は不審なメールを無視することだが、見分けるのも難しい。︵略︶︻表︼銀行のフィッシング対策アドレスバー　　ステータスバー　　単一ドメイン︵略︶もう3年経っていた……。懐かしい。

本日のリンク元 TrackBacks(5)

2004年12月19日

■ このままではJVNは役に立たない

先日、セキュリティアンテナを見に行ったところ、﹁JPCERT/CC Vendor Status Notes (JVN)﹂が上の方に躍り出ていた。何が更新されたのかと見に行ったところ、﹁Vender Status Notes - JP﹂の欄に、 JVN#E59B594B: 鶴亀メールにおけるS/MIMEの署名検証に脆弱性 [2004/12/16 19:00] と書かれていた。これが更新部分なのだろう。そう思えた。鶴亀メールのS/MIME署名検証に脆弱性といえば、10月にも一度発表されている。このことは、10月30日の日記でも次のように書いていた。さて、JVN#E59B594Bが発表された。これは、鶴亀メールのS/MIME機能*1が、署名メールの証明書パス︵証明書チェイン︶が検証されないものだったという欠陥である。このときと何が違うのだろうか。﹁JVN#E59B594B﹂という番号は、前回と今回で同じになっている。 JVN#E59B594Bのページを見に行ってみると、末尾にこう書かれていた。登録日 16:00 2004/10/28 更新日 19:00 2004/12/16 やはり10月のものと同じ件のようだが、12月16日に何か更新されたようだ。しかし、どこが改定されたのかさっぱりわからない。唯一ヒントとなるのは、﹁ベンダ情報﹂の欄に、

ベンダ	ステータス	更新日
サイトー企画	該当製品あり	2004/12/16

と書かれていたことだ。このリンク先を見に行ってみると、次のように書かれていた。サイトー企画の JVN#E59B594B への対応公表日 2004/10/28 最終更新日 2004/12/16 状態 : 該当製品あり JVN#E59B594B 製品開発者からの提供情報下記URLにて対処済み最新バージョンを公開しています。 http://hide.maruo.co.jp/software/tk.html 鶴亀メールの改版履歴 http://hide.maruo.co.jp/software/tkhist.html 脆弱性についての情報 http://hide.maruo.co.jp/software/tkparticular.html これだけである。やはりどこが改定されたのかわからない。﹁何か細かい記述の誤りとかが修正されただけなのだろうか？﹂﹁バージョンアップする必要があるとか、そういう緊急性はないのかな？﹂読者にそう思われても不思議でない。その後、IPAから、このメールは、取扱い番号 IPA#E59B594B に関する連絡です。 11/10 に頂いた情報をもとに、JVN の情報が、2004/12/16　19:00 に更新されましたことをご連絡いたします。という連絡メールが来た*1。どうやらこれは、私が届け出た件を受けて更新されたもののようだ。じつは、私は11月10日に次のことを届け出ていた。

10月28日に発表されたJVN#E59B594Bは、影響を受けるシステム - 鶴亀メール v3.70 およびそれ以前と伝えていた。セキュリティホールmemoの10月29日のエントリーには、鶴亀メール 3.71 以降で修正されている。鶴亀メールの改版履歴を見る限りでは 3.70 で直っているような気がしないでもないのだが、最新は 3.71 なので、まあいいか。セキュリティホールmemo - JVN#E59B594B 鶴亀メールにおけるS/MIMEの署名検証に脆弱性 (JVN, 2004.10.28) と書かれていた。このときの届出をしたのも私だが、私が届け出たときに検証したのは、バージョン 3.67beta3 だった。改版履歴によれば、 3.70で [重要]S/MIME電子署名されたメールの検証で、電子署名自体は検証しつつも、証明書の検証がなされてなかったバグ修正。証明書が失効されてるかどうかもチェックできるボタンも追加した。とあるように修正されたが、3.71で、 S/MIME電子署名の検証で、送り主のメールアドレスが一致してても﹁違ってる﹂と出てしまうことがあるバグ修正。という修正もされたようだ。そこで、JVNは、﹁v3.70 およびそれ以前﹂を﹁影響を受けるシステム﹂としたのだろう。ところが、その後、バージョン 3.71を入手して再度検証を行ってみたところ、証明書パスが検証されない現象は以前のまま再現することに気づいた。そこで11月10日に以下の内容の連絡をしたのだった。こちらで確認したところでは、信頼済みCAとして登録していない自己署名CAから発行したなりすまし証明書で署名したメールを表示したにもかかわらず、﹁鶴亀メール Version 3.71﹂は、署名検証時に以下の表示をしました。﹁証明書パスに問題はありません﹂という誤った表示が出ています。︵略︶

このことについて、ベンダーが主宰する掲示板にも次のように書かれていた。秀まるお2さん　04/11/16 23:16 S/MIMEにちょっとまずいバグが出てしまいました。実は、V3.68付近以下にて、 S/MIME電子署名の検証に脆弱性があるという話がありました。具体的には、電子署名に疲れた証明書の有効性が検証されてないということと、証明書パスの検証もされてないという話でした。それに対して対処したつもりが、実はまったくテストしてないのがばれてしまいました。証明書パスが間違っていても、﹁×﹂と出なくて、﹁○　有効﹂みたいに出てしまいます。秀シリーズサポートフォーラム／鶴亀メール情報交換 ― S/MIMEでのバグ︵ちょっとまずい︶これを修正したのが、改版履歴に 2004/12/16 V3.71 -> V4.00 * 主な変更点 o迷惑メールフィルターを作った。 o S/MIME電子署名の検証関係での脆弱性のバグ対応。と書かれていることからして、バージョン 4.00なのだと推察される。つまり、バージョン 3.71 以前を使っている人は、S/MIME機能を使うのなら、 4.00 へのバージョンアップが必要だということだ。にもかかわらず、JVN#E59B594B には、現時点においても、影響を受けるシステム - 鶴亀メール v3.70 およびそれ以前と書かれている。これはどういうことなのか？完全に間違ったことが書かれている。そもそも、11月10日に連絡した私の指摘は、バージョン 3.71に対する新たな脆弱性として、新規のJVN番号を割り当てて取り扱うべきだった。﹁同じ製品に対する同じ種類の脆弱性については同じJVN番号で取り扱う﹂ということなのだろうか？そういうことをすると、新たな欠陥が見つかっても、同じ文書の改定という形で発表することになる。そして、何が改定されたのか不明な文書が公開されている。この文書はいったい誰に向けて公表しているのか？誰に読ませて、何を知らせたい文書なのか？窓の杜は10月のJVN発表に対して、11月2日に以下のように報道していた。 ●﹁鶴亀メール﹂v3.69以前にS/MIMEの電子署名検証で証明書を検証しない脆弱性, 最新バージョンv3.71では修正済み, 窓の杜, 2004年11月2日 JP Vendor Status Notesは10月28日、メールソフト﹁鶴亀メール﹂v3.69以前に、S/MIMEの電子署名に関する脆弱性が2件あると発表した。脆弱性の内容は、電子署名の証明書を偽装されたメールを正式な証明書として受信してしまう恐れがあるというもの。本脆弱性は最新版のv3.71で修正されており、窓の杜や作者ホームページからダウンロードできる。まだ古いバージョンを使用しているユーザーはこれを機に最新版へ更新しておこう。こうした報道のための確かな情報源となるのが、JVNに求められる役割のはずだ。だが、窓の杜は、鶴亀メール v4.00の発表に際して、以下のように報道しており、S/MIME署名検証の脆弱性が修正されていることに触れていない。 ●﹁鶴亀メール﹂、迷惑メールフィルターを新規搭載してv4.00へバージョンアップ ― ユーザー自身で迷惑メールの抽出精度を上げることが可能 , 窓の杜, 2004年12月17日︵有︶サイトー企画は16日、メールソフト﹁鶴亀メール﹂v4.00を公開した。今回のバージョンアップでは、新たに迷惑メールフィルター機能を搭載したほか、メール一覧を2段表示できるレイアウトなどが追加された。︵略︶そのほかの変更点では、既存の“ウイルス対策”機能が強化されている。添付されたZIP形式の圧縮ファイル内を調べて、指定した拡張子のファイルが存在する場合に自動削除する機能が追加された。また表示関連の変更として、メール一覧でSubjectとFromを2行で表示する新レイアウトや、一行おきに背景を色分けする“ストライプ表示”が追加されている。 16日に更新された JVNの情報が役立っていないことがわかる。﹁影響を受けるシステム﹂のバージョン番号の部分を改定し忘れたのは、 JVNの単純ミスだったとしよう。しかし、改定履歴を書かないのはまったく理解しかねる。改定履歴さえ書いていれば、﹁影響を受けるシステム﹂のバージョン番号がおかしいことに気づくだろう。率直に言って、JVNは、一般的に﹁文書を公表する﹂という仕事をするにあたって求められている基本的な能力に問題がある、そう言わざるを得ない。

*1 こうしたメールは、IPAの脆弱性情報届出窓口に製品の脆弱性を届け出ていた人に対して、その件がJVNで公表された際に送られてくる。

本日のリンク元 TrackBacks(31)

2004年12月21日

■ バージョン番号くらい書こうよ

JVN#B4BE09A4 が発表された。影響を受けるシステム - Shuriken Pro3 - Shuriken Pro3 /R.2 - Shuriken Pro3 /R.2 [ベリサインセキュリティメールセット] - Shuriken Pro3 Corporate Edition JVN#B4BE09A4: Shuriken Pro3 のS/MIME機能で署名検証時に証明書の真正性が確認されないとしか書かれていないので、どのバージョン以前にその脆弱性があるのか不明だ。ベンダーの発表にも書かれていない。上のと同じことが書かれているだけだ*1。

■ ジャストシステムの発表文は事実と異なる

JVN#B4BE09A4に対するベンダーの発表文には誤りがあるので、届出者として知っている事実を書き留めておく。今回のベンダー発表文には次のように書かれている。現象2‥ ︵略︶ Shuriken Pro3(*) では、署名メール開封時には、メールの内容が改ざんされていないことだけを確認し、署名に使われた証明書が信頼できるかどうかは、 [表示 - 暗号・署名情報の表示] によって、証明書に関する情報を表示して、利用者ご自身にご判断頂く仕様となっておりました。 Shuriken Pro3の脆弱性として、S/MIME機能で署名検証時に証明書に関する確認が表示されない現象についてつまり、﹁証明書の信頼確認はメール開封時にはやらない仕様だった﹂ということが書かれているように読めるが、それは事実と異なる。11月27日の日記﹁Shuriken Pro3 のS/MIME機能に何があったか﹂の図3に書いていたように、古いバージョンでも、偽の認証局から発行した偽の証明書で署名したメールを開封しようとすると、きちんと﹁デジタル署名に使用された証明書が有効でありません。﹂と警告が出る仕様になっていた。

11月27日の日記の図3の再掲

では、JVN#B4BE09A4 の件は、どういう脆弱性として届けていたかというと、次のものだった。 Shuriken Pro3 5.0.1.6 では、証明書のサブジェクト識別名の﹁EmailAddress﹂欄を空にした証明書で署名したメールでは、その証明書が偽認証局発行のものであっても、警告が出ないというバグがあった。事実確認用の証拠としてその実例を以下に示す。

Date: Wed, 10 Nov 2004 12:10:40 +0900
From: foo@example.com
To: takagi@mail1.accsnet.ne.jp
Subject: S/MIME
 =?ISO-2022-JP?B?GyRCRkg8KxsoQkNBGyRCSC85VBsoQiAbJEIlYRsoQg==?=
 =?ISO-2022-JP?B?GyRCITwlayUiJUklbCU5JEokNz5aTEA9cRsoQiA=?=
 =?ISO-2022-JP?B?GyRCJE4lRiU5JUgbKEI=?=
X-SMIME-Plugin: Becky! S/MIME Plug-in v1.0.0rc2 build at Aug 13 2002 21:52:41
Message-Id: <20041110121031.B81D.FOO@example.com>
MIME-Version: 1.0
X-Mailer: Becky! ver. 2.11.02 [ja]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha1"; boundary="===[S/MIME_RFC2311]===419186A7.31E220==="
Content-Transfer-Encoding: 7bit

--===[S/MIME_RFC2311]===419186A7.31E220===
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit

S/MIME署名のテスト

--===[S/MIME_RFC2311]===419186A7.31E220===
Content-Type: application/x-pkcs7-signature;
 name="smime.p7s"
Content-Disposition: attachment;
 filename="smime.p7s"
Content-Transfer-Encoding: base64

MIIE1QYJKoZIhvcNAQcCoIIExjCCBMICAQExCzAJBgUrDgMCGgUAMAsGCSqG
SIb3DQEHAaCCA5IwggOOMIICdqADAgECAgEDMA0GCSqGSIb3DQEBBAUAMGAx
CzAJBgNVBAYTAkpQMRAwDgYDVQQIEwdJYmFyYWtpMRAwDgYDVQQHEwdUc3Vr
dWJhMRQwEgYDVQQKEwtOYW5kZW1vIEFyaTEXMBUGA1UEAxMOTmFuZGVtbyBB
cmkgQ0EwHhcNMDQxMTEwMDMwMzU4WhcNMDUxMTEwMDMwMzU4WjBPMQswCQYD
VQQGEwJKUDEQMA4GA1UECBMHSWJhcmFraTEUMBIGA1UEChMLTmFuZGVtbyBB
cmkxGDAWBgNVBAMUD2Zvb0BleGFtcGxlLmNvbTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAoaVR4FS2YAIDNfMQ/J1U4WITcjrojSH67buWoSTA7bcK
xz1k0NxoEHdtGMlNIsk1mC+hGGEOThfU28UEpL4abpH5L26at0LE01S3z8TD
Gc8kjWzY9YA5VGp2VWuqDAlXyvbMDvNWkEERYLsWa1Rtak7Yk48eRp+CSix4
depkacMCAwEAAaOB5zCB5DAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1P
cGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQU/kFAV7lM
5frHBHfy15bFSPIVDCEwgYkGA1UdIwSBgTB/gBQxFSn6qdO2VZp/NfBCNnCb
p4nVvKFkpGIwYDELMAkGA1UEBhMCSlAxEDAOBgNVBAgTB0liYXJha2kxEDAO
BgNVBAcTB1RzdWt1YmExFDASBgNVBAoTC05hbmRlbW8gQXJpMRcwFQYDVQQD
Ew5OYW5kZW1vIEFyaSBDQYIBADANBgkqhkiG9w0BAQQFAAOCAQEANd6s8HeB
vZwTV0TRY8rrImEKtJCXCImf4hKFVedDQ0Keil4z6EFtu3fky83HqPc6NAuO
eYUpyCf4ciJb9sA0SLrntT46o/zyhfPx41JX8rjDkKwos5G/cObCpLdv7Msr
fwZc9Pmf/ZxqMtYxS4dCxu/trC7XgpHKp3ETOYn160cdnV/Gws1dMetOAXSu
oKW8HS4qkUKE4bddhhBSazjlCYOIKduKGIb+gzN0nfrk+p2uEaPqtbS56nhC
/Ag4AIjLzAC99NjzxmuRaE6+CUTSeTf3N12mtqv+aFtY5otOPBzpApfIUsWv
ul02Yt0Nd6D49dMadMlGOcPDQj/kt4wV6zGCAQswggEHAgEBMGUwYDELMAkG
A1UEBhMCSlAxEDAOBgNVBAgTB0liYXJha2kxEDAOBgNVBAcTB1RzdWt1YmEx
FDASBgNVBAoTC05hbmRlbW8gQXJpMRcwFQYDVQQDEw5OYW5kZW1vIEFyaSBD
QQIBAzAJBgUrDgMCGgUAMA0GCSqGSIb3DQEBAQUABIGAhWx8yvkvWJSn0hVb
c7FNIUjiiZuFLx+QgOfpCn5Fld0EtU0kek5FEvGFmuEjvdPFrL2qdZPhL4o7
+aLkmTd2+x7N1x7Lu7uG11USWTMpmn6H5HfFtxFpKM0Y1CdIbtx4qVSNnOBp
VJCd/qoJTT4fRdJPDDa9HKrQZn2rRPZyPzg=
--===[S/MIME_RFC2311]===419186A7.31E220===--

この問題は、前回のJVN#B410A83Fよりもいささか深刻だった。なぜなら、前回の件では、11月27日の日記に書いたように、図5の説明には若干の補足が必要である。受信したメールの署名者の証明書を、証明書ストア*3に信頼済みのものとして登録していない場合︵たとえば、初めての相手からのメールである場合︶には、次の図のように、証明書ストアに登録するかと尋ねる確認ウィンドウが現れる。という挙動を示すものだったが、今回の件では、この確認ウィンドウが現れることなく、本文が表示されてしまうからだ。届出では、上のサンプルメールを添付して、以下のように説明した。 3) 脆弱性の種類 S/MIME署名されたメールの署名検証で不正な証明書が正当と誤判断される Shuriken Pro3/R.2は、電子署名されたメールを表示するとき、﹁このメールは暗号化、または、署名されています。﹂という表示とともに﹁復号・署名確認﹂ボタンを出し、このボタンが押されると、署名検証をした後に本文を表示するようになっている。本文が改ざんされたメールにおいては、この﹁復号・署名確認﹂ボタンを押した時点で、﹁デジタル署名と署名された文書が一致しません。改竄されている恐れがあります。﹂という警告メッセージが出るようになっており、また、不正な証明書で電子署名されたメールにおいては、﹁デジタル署名に使用された証明書が有効ではありません。﹂との警告が出るようになっている。これらのことから、このボタンを押して警告が出なければ、そのメールは真正のものである︵改ざんもなりすましもされていない︶と利用者は理解する。しかし、ある特殊な細工を施した不正な証明書を用いて電子署名したメールにおいて、﹁復号・署名確認﹂ボタンを押すと、何ら警告を出すことなく本文が表示されてしまう。 4) 再現手順︵略︶ 2. テスト用自己署名認証局証明書等を用いて、以下の特徴を持つ特殊な証明書を生成し、Windowsの証明書ストアにインストールする。・サブジェクト識別名︵DN︶の﹁E﹂フィールド︵EmailAddress︶を空とする。その実例を添付ファイル﹁smime2.crt﹂に示す。 3. その証明書を使ってS/MIME署名したメールを送信する。︵略︶ 6) 脆弱性により発生しうる脅威特殊な細工を施した偽の証明書で電子署名されたメールを受け取ったとき、﹁復号・署名確認﹂ボタンを押しただけでは真正のものと区別されないため、S/MIME が本来提供するはずの、なりすまし防止や、改ざん防止の機能が有効に働かない。これを受信者がShuriken Pro3/R.2で表示した場合、ボタンを押しただけでは証明書パスが検証されないため、詐称メールであることが検出されない。また、攻撃者は、通信路上で本文の改ざんと同時に証明書もすり替えることができ、その場合にも改ざんの事実は検出されない。ちなみに、実は、このバグそのものは現在の最新版︵バージョン 5.5.6.0︶でも﹁修正﹂されてはいないようだ。というのは、前回のJVN#B410A83Fが 5.5.6.0 で修正されたことによって、このメールを開こうとすると、署名者のメールアドレスと差出人のメールアドレスが一致しません。の警告が出るようになった︵署名者のメールアドレスが空なので︶ため、結果的に、これによって偽メールだと気づくことはできるようになっている*2。しかし、偽認証局発行のEmailAddressが空でない証明書で署名され、かつ、Fromが署名者アドレスと異なるメールで実験すると、5.5.6.0 は、デジタル署名に使用された証明書が有効ではありません。の方の警告を出す︵アドレスが一致しませんの警告は出ない︶ことから、このバグ自体は残っていると推察される。偽メールに対して何かしらの警告は出るようになったのだから、5.5.6.0 で脆弱とはいえなくなっているといえるにしても、いまひとつきちんとした警告が出ないままの状態といえるのではなかろうか。こういうのに比べて、Outlook Expressの警告表示はよくできている。 Microsoftはさすがだ。

*1 「アップデートモジュールのダウンロードはこちら」と書かれたリンク先にある、アップデートモジュールのページ（「公開日2003.04.18」のページ）には、「バージョンが記載バージョン以降であれば、導入いただく必要はありません。 5.5.6.0　(2004.11.18更新)」といちおう書かれてはいるが、ここは新しいアップデートモジュールが出るたびに書き換えられるところなので、今回の脆弱性がいつのバージョン未満までに影響があるのか、しばらくすると不明になってしまう。

*2 私が今回の脆弱性を届け出たのは、5.5.6.0のパッチリリースを知るより前だった。

本日のリンク元 TrackBacks(100)

2004年12月25日

■ Firefoxの普及状況は？

Firefoxはどのくらい普及しているのだろうかと、この日記のアクセスログから、訪問者が使用していたブラウザの種類を調べてみた。図1のグラフは、/diary/ および /diary/*.html への GETアクセスについて、日別に、ブラウザの種類を棒グラフ︵目盛は左︶に、アクセス数を折れ線グラフ︵目盛は右︶に示している。﹁others﹂にはランク外のブラウザの他に検索ロボットなども含まれている。

図1: この日記の閲覧時に使用されているブラウザの推移

12/8のところで突出した傾向が現れているのは、12月5日の日記に対してたくさんのサイトからリンクされたために、普段ここに訪れていなかった人たちが多数訪れた影響と思われる。集計に使用したプログラムは以下の通り*1。

#! /usr/local/bin/ruby
logformat = /^(\S*) (\S*) (\S*) \[(...........):(........) .....\]『(\S*) (\S*)
(\S*)』(\S*) (\S*) "([^"]*)" "([^"]*)"/
total = 0
msie = firefox = mozilla = netscape6 = opera = safari = w3m = netscape4 = antenn
a = others = 0
while line = gets()
    line.chomp!()
    (addr, user, auth, date, time, method, path, protocol, status, length, refer
rer, agent) = line.scan(logformat)[0]
    next if method != "GET"
    next if not path.match(/^\/diary\/$|^\/diary\/.*\.html$/)
    total += 1
    if agent.match(/Opera/)
        opera += 1
    elsif agent.match(/Firefox/)
        firefox += 1
    elsif agent.match(/Safari/)
        safari += 1
    elsif agent.match(/w3m/)
        w3m += 1
    elsif agent.match(/MSIE/)
        msie += 1
    elsif agent.match(/Netscape\/[67]/)
        netscape6 += 1
    elsif agent.match(/Mozilla\/4\.[6789]/)
        netscape4 += 1
    elsif agent.match(/Gecko\//)
        mozilla += 1
    elsif agent.downcase.match(/antenna|wdb|rss|samidare|livedoorcheckers|glucos
e|blogpeople/)
        antenna += 1
    else
        others += 1
    end
end
print "#{total} #{msie} #{firefox} #{mozilla} #{netscape6} #{opera} #{safari} #{
w3m} #{netscape4} #{antenna} #{others}\n"

*1 ご利用はご自由に。

本日のリンク元 TrackBacks(100)

高木浩光＠自宅の日記

2004年12月04日

■ Becky! 2.12で何が改善されたか

■ 消費者にセキュリティを説くHTMLメールマガジンの偽善

■ え!?そんなこともあるの？真・セキュリティ知識度チェック

2004年12月05日

■ ヤフーからの通知を装った日本語フィッシングで何が起きていたか

クロスサイトスクリプティングによる偽装

入力したパスワードが本物サイトに中継される

■ Yahoo! Mailのフィッシング事例から得られる教訓

原因の究明が遅れていた可能性

﹁フィッシングは防ぎようがない﹂という考えが対策を怠らせる

XSS脆弱性のもうひとつの脅威が実証されてしまった

イーバンク銀行のキーワード確認機能はやっぱりフィッシング対策にならない

ユーザへの注意文は専門家に書かせた方がよい

■ 「メールで尋ねることはしていない」という一つ覚え

2004年12月10日

■ 日本版Anti-Phishing Working Groupは誕生し得るのか？

■ mod_rubyなしではcounter.rbが3万回/日程度のアクセスに耐えられない

2004年12月15日

■ ソニー銀行がアドレスバーとステータスバーを出すようになっていた

2004年12月19日

■ このままではJVNは役に立たない

2004年12月21日

■ バージョン番号くらい書こうよ

■ ジャストシステムの発表文は事実と異なる

2004年12月25日

■ Firefoxの普及状況は？

最近のタイトル

高木浩光＠自宅の日記

2004年12月04日

■ Becky! 2.12で何が改善されたか

■ 消費者にセキュリティを説くHTMLメールマガジンの偽善

■ え!?そんなこともあるの？ 真・セキュリティ知識度チェック

2004年12月05日

■ ヤフーからの通知を装った日本語フィッシングで何が起きていたか

クロスサイトスクリプティングによる偽装

入力したパスワードが本物サイトに中継される

■ Yahoo! Mailのフィッシング事例から得られる教訓

原因の究明が遅れていた可能性

﹁フィッシングは防ぎようがない﹂という考えが対策を怠らせる

XSS脆弱性のもうひとつの脅威が実証されてしまった

イーバンク銀行のキーワード確認機能はやっぱりフィッシング対策にならない

ユーザへの注意文は専門家に書かせた方がよい

■ 「メールで尋ねることはしていない」という一つ覚え

2004年12月10日

■ 日本版Anti-Phishing Working Groupは誕生し得るのか？

■ mod_rubyなしではcounter.rbが3万回/日程度のアクセスに耐えられない

2004年12月15日

■ ソニー銀行がアドレスバーとステータスバーを出すようになっていた

2004年12月19日

■ このままではJVNは役に立たない

2004年12月21日

■ バージョン番号くらい書こうよ

■ ジャストシステムの発表文は事実と異なる

2004年12月25日

■ Firefoxの普及状況は？

最近のタイトル

■ え!?そんなこともあるの？真・セキュリティ知識度チェック