Becky! Internet Mail のVersion 2.12 が11月17日にリリースされた。
このバージョンでは、フィッシング対策の変更点があったのだが、 窓の杜の記事には書かれていないので、書き留めておく。
Becky!の更新履歴には次のように書かれている。
Ver2.11.02 -> Ver2.12
・HTMLメール中のリンクをクリックした際、標準のブラウザで開くようにした。
・HTMLメール中の、リンクの上でマウスを動かした時のリンク先の情報などをステータスバーに表示するようにした。
さてこれはどういう意味だろうか。
じつは、Becky! 2.11.02まででは、HTMLメールを表示したとき、HTMLメール中 のリンクをクリックすると、そのままBecky!のウィンドウの中でリンク先の ページにジャンプする仕様だった。また、リンクのアンカーにマウスポインタ を乗せても、リンク先のURLがステータスバーなどに表示されない仕様だった。
たとえば、以下の図のように、フィッシングメールを受信したとする。これは HTMLメールで、リンク先が本当はどこなのか、マウスポインタで探っても、 見ただけではわからない。
ここで「Register」と書かれたリンクをクリックすると、次のようにリンク先 のページが表示される。
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。
NTTコミュニケーションズの「ネットお役立ちマガジン コム☆ナビ」というメールマガジンを購読しているのだが、 これがひどい。
下の図のように、HTMLメールで配信されてくるのだが、HTMLメール上に入力フォー ムがあり、送信ボタンがある。
送信ボタンを押したときに情報がどこに送信されるのか、わからないようになっ ている*5。
昨年6月14日の日記「HTMLメールマガジンのもうひとつの危険性」で書いたように、 HTMLメール中に入力フォームを設けるなどというのは、フィッシングに騙され やすい消費者を育成しているようなものだ。
しかもこのメールマガジンのタイトルが「え!? そんなこともあるの? 最新セキュリティ知識度チェック」というのだから、臍で茶が沸いてしまう。
他にも、「ネットのセキュリティは大丈夫?チェックテストで確認しよう! 安全対策・ファイアウォール、準備はOK?」だの、「ネットライフの安全管理、 万全度チェック」だのいう号もあった。これらの内容は、購読者以外でも、 以下のページで閲覧することができる。
これらのマガジン中にはいろいろと注意書きがある。たとえば、
※メールソフトの種類や設定により各チェックボタン、「結果発表!!」ボタン が働かない場合があります。その際にはここをクリックしてください。別ペー ジよりチェック5がお楽しみいただけます。
と書かれている。最初からそうすればよいのだ。昨年6月6日の日記 にも書いていたように、ブロードバンド常時接続時代のいまどき、メールで コンテンツを届ける必要はもはやない。Webサイト上にマガジンを置けばよい。 メールは新しい号の公開を通知するだけに使えばよい。メールソフトによって ボタンが働かないものがあるというのは、それが危険な行為だから、メールソ フトの方で対策されている可能性だってある。
他にもこのような注意書きがある。
リンク先に書かれていることが、これまた危険な行為をさせようとするものだ。
coden.ntt.com メールマガジンをより快適にご覧いただくために、 「HTMLメールの表示」を「テキストに変換して表示」にし、添付ファイルを閲 覧するかたちでお楽しみいただくことをおすすめいたします。設定の方法は下 記の通りです。
「Becky! Internet Mail」をご使用の方へ設定のお願い, NTTコミュニケーションズ
一般に、添付ファイルを開くときは、そのファイルタイプや拡張子に注意が必 要である。得体の知れないメールの「.exe」ファイルを開くことは当然危険で あるし、「.bat」や「.vbs」、「.pif」、「.scr」なども危険であり、実際、 添付ファイルを開かせようとするウイルスメールで悪用されている手口だ。
そして、「.htm」や「.html」もそれらと同様に、不用意に開いてはならない 拡張子である。なぜなら、これらを開くと、マイコンピュータゾーンでHTMLが 開かれる*6ため、 安全でないコンテンツが確認なしに起動してしまうからだ。
「最新セキュリティ知識度チェック」と言いながら、「HTML添付ファイルを開け」 と指示するなんてのは、ウイルスに感染しやすい消費者を育成しているような ものだ。
なぜわざわざこういうことをさせるのだろうか。 「より快適にご覧いただくため」という表現は、本当の理由を説明することを サボったものであり、ろくな理由でないことが多い*7。
次に、10月ごろからは次の注意書きも入るようになった。
リンク先には次のように書かれている。
「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コミュニケーションズオフィシャルサ イトに再度訪問された際、より便利に当サイトを閲覧していただくた めのものであり、お客さまのプライバシーを侵害するものではなく、 またお客さまのコンピューターへ悪影響を及ぼすことはありません。
ある行為が、ある個人のプライバシーを侵害するものになるかどうかは、その 個人が判断することである。事業者が「これはお客様のプライバシーを侵害す るものではない」といくら勝手に考えていても、それが見当違いであることが 少なくない。だからこそプライバシーポリシーの開示が必要なのであって、 「侵害するものではない」と宣言するだけで済むんだったら、プライバシーポ リシーなぞいらない。
「クッキー(Cookies)は……ありません」と、cookie一般がそういう性質の ものでないかのように言っているのも大間違いだ。何もわかっていない人が、 意味もわからずこれを書かされている様子が窺える。
書くべきことは、どのページでどのようにcookieを使っていて、それはこれこ れの結果をもたらすが、当社はこれこれの形でしか使わないようにしている ――といったことだ。
「より便利に」とか「より快適に」だの「より良いお客様サービス」だのいう 表現は、裏側に説明されていない何かがあるとみてよいだろう。
本来ならば、この種の啓蒙系メールマガジンは、 次のようなチェック項目を入れておくべきところだろう。
だが、これが載ることはあり得ない。自己否定せねばならないのだから。
ようするに、HTMLメールマガジンがセキュリティを語っていたら、偽善 とみなしてよい*8 ということだ。
*1 右クリッ クでプロパティを選べば確認することができる。
*2 右クリックでプロパティを選べば確認することができる。
*3 誰もこれまで話題にしなかったのは、Becky!ユーザのほとんどが HTMLメール なぞ使っていないということなのだろうか。
*4 したがって、今後、このステータ スバーを偽装する方法が見つかると、それは「脆弱性」と言えることになる。
*5 HTMLソースを見ればわかるが。
*6 11月にリリースされた Becky! 2.12では、このとき、 インターネットゾーンで開かれるように改善されている。
*7 このケースでは、 Becky! 2.11.02以前だと、リンクをクリックすると戻れなくなる (ジャンプ先がBecky!のウィンドウ内で表示されるため、右クリックで「戻る」 を押さないと戻れない)ためではないかと推察されるが、他にも理由があるの かもしれない。
*8 S/MIME署名されるようになったとかなら別だが。
先月の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 - 有料コンテンツご利用停止に関するお知らせ
ここで、矢印部分にあるリンク「Yahoo!ウォレット登録情報の確認・変更」を クリックしたところ、図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は、あらゆる手段を用いて電子メールのなかにあるスクリプトの実行を阻止しており、両サービスでは受信メッセージに含まれるHTMLコンテンツにフィルタをかけている。我々は、スクリプトを実行させるためにフィルタを回避する方法を発見した」(Dagon)
この脆弱性は、技術的にはクロスサイトスクリプトの欠陥に分類される問題だ。(略)
...(略)...
今回のヤフーをターゲットにしたフィッシングメールで使われていた、 JavaScriptを実行させる方法は、次のものだった。
<style onload="スクリプト文"></style>
スクリプト実行の防止において、「onload」に対策をするのは基本中の基本と 思われるのだが、これがフィルタリングされない穴が残っていたというのは 意外だった。
調べてみたところ、米 yahoo.com のWebメールにおいても同じ脆弱性が存在 していた。
これはまずいと思ったので、急ぎ、15日の深夜から16日にかけて、ヤフージャ パンと米Yahoo!の一般向け質問窓口に対して、この脆弱性の存在を伝えるメッ セージを送った。ヤフージャパンでは16日のうちに修正され、米Yahoo!では 数日後には修正されていた。
このフィッシング事例が巧妙だったのは、それだけではなかった。図2の画面 で、わざと間違ったパスワードを入力してみたところ、図3の画面が現れた。
10回ほど、自分のIDに対して間違ったパスワードを入れてみたところ、 10回とも「パスワードが正しくありません」というエラーになった。 そして11回目に、正しいパスワードを入れてみたところ、 図4の画面に進んだ。
こうした挙動を示したのは、偽サイトが、入力されたパスワードを本物サイト に中継送信して、パスワードが本物かどうかを確認する仕掛けになっていたと しか考えられない。
何気なくパスワードを間違えたりして、このような挙動を見た人は、正しいパ スワードを入れたとき、本物サイトにログインしている錯覚に陥るだろう。
暗証番号(セキュリティキー)には何を入れても通過するようだったが、 この後現れる画面は、図5のようになっており、 すっかり本物サイトにログインしていると錯覚した人は、疑いもなく、 これらの情報を入力してしまうのだろう。
図2〜4の画面は、本物のヤフーのサイトに実在する画面とそっくりだが、図5 のように、カードの暗証番号(ATMでのキャッシングに使用するもの)を求め る画面は存在しないようだ。冷静に考えれば、そんな情報をWebに登録するの は変なのだが、ログインしていると錯覚していれば入れてしまうのだろう。
ちなみに、図4の画面をサブフレームだけ表示させたのが図6である。偽サイト のURLで動いていることがわかる。URLのパラメータ部分には、ユーザIDと、 入力したパスワード*2が渡されているのが見える。
この事例は、その後以下のように報道された。
日本語で書かれたフィッシングメールとしては、先週、VISAをかたるものが登場 したばかりだ。これに続いて、 別のテクニックを用いた手法が登場したことになる。しかも、 Webメールのユーザーに対しHTML形式のメールを送り付けるという点で、さら に巧妙だ。
なお、Yahoo! JAPANと同様、JavaScriptを悪用され、 「それらしき」Webサイトを偽造されるという脆弱性を残したWebサイトは、 他にも存在すると考えられる。自衛手段としては、
今回のフィッシングでは、手口が悪質化している。JavaScriptを悪用し、アド レスバーには正規のYahoo! JAPANのURLを表示したままで、Webページ部分だけ を偽のページに置き換えているという。
このフィッシングの特徴は,メールで誘導した偽サイトのアドレス・バーを “偽装”すること。JavaScriptやフレームを使って,アドレス・バーにはヤフー のURLを表示させ,ページの中身にだけ偽サイトのページ(フレーム)を表示 させる。同社では詳細は明らかにしていないものの,Yahoo! Japan (Yahoo!メール)サイトの不具合を悪用しているようだ。
(略)
ヤフーによると,11月15日に上記の不具合を修正したという。このため, 現在では全く同じ手口は使えなくなっている。
(略)
ユーザーばかりではなく,サイトの開発者/運用者も注意が必要だ。 フィッシングに悪用される不具合――例えば,クロスサイト・スクリプティング の脆弱性など――がないことを改めて確認したい。
マスメディアは、今回の原因が、ヤフーのXSS脆弱性にあったということを、 ズバリ書いてはくれなかった*3。 日経IT Proの記事も、ITmediaの記事も、わかっていながらぼかして書かれて いる様子が見て取れる。とくにITmediaの記事は、本当のことを書きたくてた まらないが、クロスサイトスクリプティングという言葉だけは避けて書かれて いるように見える。
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の事例のように、サイトの脆弱性が突かれたことが原因 で、騙されやすい偽サイトを作られてしまう可能性があるのだから、 「防ぎようがない」で思考を止めてしまってはならない。
マスメディアは、高度な手口に対して防ぎようがないかのような印象を抱かせ る報道を避けるべきである。過去にも、ウイルスが自力で防げないものである かのような報道をして、ウイルス対策ソフトの売り上げに貢献したことが あったが、まずやるべきことは脆弱性の修正であるということを、常に基本と しておさえておくべきだ。
2000年2月にCERT/CCからCA-2000-02 として発表されたXSS脆弱性。SecurIT-Advisory 2001-001で注意を呼びかけたときは、 cookieの漏洩によるセッションハイジャックの危険性に焦点を当てて、軽微な 問題ではないことを訴えた。
その後、多くの人たちによって、この脆弱性があちこちのサイトで発見される こととなったが、cookieを使っていないサイトでは、「たいした問題ではない」 とされることが多かった。 そうしたとき、「偽の情報を本物ドメインの画面に表示させられる」という 危険性があると訴えられていたが、「そんな罠をしかける人、本当にいるの?」 とか、「そんな罠に騙される人いるの?」という反応が少なくなかった。
しかし、図らずも、「フィッシング詐欺」という名前まで付く攻撃手法が 蔓延してしまい、そのときの危惧が現実のものとなってしまった。
クロスサイトスクリプティングは、フィッシング詐欺に悪用される脆弱性であり、 顧客をフィッシング詐欺から守りたい事業者が自社のサイトから排除せねば ならない脆弱性である。このことを広く周知するべきであろう。
今回の件があきらかになる少し前に、次の報道が出ていた。
記事中には「検索スクリプトの欠陥を悪用」「検索スクリプトの脆弱性を悪用」 「検索サーバの脆弱性」とあるが、これは、検索のキーワード入力欄に存在す るクロスサイトスクリプティング脆弱性のことを言っているのだと思われる。
イーバンク銀行がフィッシング詐欺対策と銘打って導入したキーワード確認 機能が、対策になっていないことは、10月11日の日記「素人がやってはいけないセキュリティの「大発明」」で書いた。
つまり、イーバンク銀行のこのシステムは、パスワードの前半分だけを入力し たときに、自分だけが知っているはずのキーワードが画面に現れれば、「本物 サイトだと信じてよい」という趣旨なのだが、偽サイトが、入力されたパスワー ドを本物サイトに中継するようになっていたら、偽サイト上にキーワードが 表示されてしまうだろうというものだった。
今回の、Yahoo! Mailで起きたフィッシングの事例では、まさに、入力した パスワードを本物サイトに中継することによって、本物のログイン画面である かのような信憑性を作り出していた。間違ったパスワードで入れず、正しい パスワードで入れたからといって、本物サイトとは限らないのである。
このような事実があるのだから、イーバンク銀行のキーワード確認機能を普段 から使わせることは、騙されやすい消費者を育成することになりかねない。
今回の事例の原因がはっきりするより前の段階で、ヤフーは「Yahoo! JAPAN IDとパ スワードを不正に盗み取る悪質なメールに関するご注意」という文書を 出していたのだが、この文書があまりにも拙すぎた。
■「有料コンテンツご利用停止に関するお知らせ」
このメールには個人情報と取得する悪質なウェブページが記載されております。
悪質なウェブページのURL:
http://edit.payment.yahoo.co.jp/config/wallet_confirm
と書かれているのだが、そのURLは、本物のヤフーサイトに実在するアドレス じゃないか。
そのアドレスにジャンプするかのように装って、違うところへアクセスさせて いるのに、「悪質なウェブページのURL」としてそれを書いてどうするのだ?
ようするに、過去の別の注意文の
Yahoo! JAPANのページを騙り、お客様のYahoo! JAPAN IDとパスワードを不正に盗み取る悪質なウェブページが報告されました。
該当の悪質なウェブページのURLは次のとおりです。
Yahoo! JAPANとは無関係の悪質なウェブページ
http://free.frss1.net/ ̄auction/yahoo/
をテンプレートにして、URLのところだけ書き換えたわけだ。
惰性で仕事をしているか、そうでなければ、本当に何もわからない素人さんが 書いたとしか思えない。
また、ヤフーは、これまでにフィッシングに対する注意文を多数掲載してき ているが、いずれにも日付が書かれていないので、今起きている話なのか、 既に終わった話になっているのかが判別できない。 日付を書かない理由がわからないのだが、何か意味があるのだろうか。
一方、イーバンク銀行では、別のフィッシング事例が発生していた。
今回のメールは、件名が「イーバンク銀行からのお知らせ[入金がありました]」となっており、テキスト形式で送信される。同銀行では、メールアドレスを登録している利用者に対し、入金時や出金時などに通知メールを送信しているが、今回のフィッシング詐欺メールは実際に入金時に送られるメールと同じ件名が使われていた。
メール内にはURLが記載されており、そこにアクセスするとログイン画面が表示され、支店番号・口座番号・ログインパスワードの入力が促され、さらに「システム上の確認」と称して暗証番号を入力させようとする。メールアドレスやメール記載のURLがイーバンク銀行のものではなかったほか、同銀行はメールからログインパスワード・暗証番号を入力させるようなことはしていないという。
イーバンク銀行では、「そもそも、利用者のログインパスワードや暗証番号 をメールで尋ねることはしていない」。その上で、フィッシング詐欺メールに 騙されないようにするには、「不審なメールに記載された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署名するよ うにするしかないだろう。
前回の日記では、「原因の究明が遅れていた可能性」として、
このことからして、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のパスワード要求画面みたいなんですが、(略)
つまり、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."
日本ではどうだろうか。
このところマスメディアから、フィッシングメールの実物を持っていないかと の問い合わせを何件か受けた。実際にどういう画面が現れるのか、報道しよう にも実物が手に入らないのだという。先月、ビザ ・インターナショナル東京事務所がターゲットにされた事例があったが、 小耳にはさんだところによると、ビザ・インターナショナルに実物の提供を 求めても、「ない」との返事が来るのだそうだ。
あれだけ多く出回ったのに、本当に入手できていないのならそれも問題だし、 あるけど出さないというのだとしたら、それはどうなのか。
英語圏では、業界の集まりが自ら実例を公表することによって防止を図っている。 日本の企業風土が「とりあえず隠しておく」なのかどうかは知らないが、 日本でAPWGと同じようにできるのかどうか……。
経済産業省が、「フィッシング・メール対策連絡会議」を設置して、 第一回の会合を開いたと報道されている。
官民で関連情報の共有を図るのが目的。 第1回では国内外でのフィッシング詐欺事例を把握し、対応策を検討した。
「情報の共有」とは、業界内だけの秘密事項としての共有ということなのか、 それとも、APWGのように消費者とも共有していくということなのか。
ロゴを盗用するなどして実物サイトそっくりの画面になっているということ こそが、フィッシングの特徴であるところで、 社名を隠した架空の偽サイト画面を消費者に見せても、啓発にならない。
今週火曜日、昼の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
原因が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」となるところだった。
久しぶりにソニー銀行を利用しようと したところ、 ログイン画面でアドレスバーとステータスバーが現れるようになっているのに 気づいた。
いつからだろう? と調べてみると、 お知らせが11月15日に出ていた。そこにこう書かれている。
お客さまがアクセスしているページが正当な当社のウェブサイトであることをご確認いただくために、ログイン時やログイン後のサービスサイトの一部において、ブラウザーウィンドウ上部のアドレスバー、下部のステータスバーを表示するようにウィンド ウ表示方法の変更を行ないました。
なにはともあれよかった。 他の金融機関がどうなっているか、今一度全部調べてみるとよいかもしれない。
関連記事等:
3.2 なりすましに無警戒な銀行のログイン画面
ネット専業銀行として最近開業したある銀行のサービスサイトでは,ログインボタンを押すと図4のようなウィンドウが現れるようになっている.ユーザはここに口座番号とパスワードを入力するわけであるが,このウィンドウは図のように,メニューや制御ボタン,そして「アドレスバー」と「ステータスバー」がウィンドウから削られている.これは, JavaScript を用いて意図的に現れないように作り込まれている.
ほとんどのウェブブラウザは,通常,「アドレスバー」に,現在表示中のページのURL を示すように作られている.これは,「今見ているところはどこか?」ということをユーザが常に確認できるようにと用意された重要な機能である.また,「ステータスバー」には, SSL 通信をしているかどうかを示す鍵のアイコンがあるはずである.本来ならば,ユーザはこのアイコンを確認することで,現在アクセス中のページが保護されていることを確認できるし,このアイコンをクリックすることで証明書の内容を表示させてそのサーバが偽物でないことを確認できるはずなのに,それがわざわざ非表示になっている.
もしこの銀行を装った偽のウィンドウを出現させる悪意のあるサイトが存在していたらどうだろうか.「こちらは○○銀行です.只今キャンペーン実施中です.今ログインして頂いた方には粗品を差し上げます.」といった電子メールやバナー広告に誘われて,指定のサイトにアクセスしたときに,同じデザインのウィンドウが現れるといったことはあり得るだろう.このとき,日頃から図4のウィンドウに慣らされているユーザは,「右クリック+プロパティ」によってそのウィンドウのURL のドメインを確かめようとするだろうか.これを確かめることなく,偽のウィンドウに口座番号とパスワードを入力してしまえば,それは悪意ある者によって収集されてしまう.偽のウィンドウが,口座番号とパスワードを収集した後,本物の銀行のページにリダイレクトするような仕掛けになっていれば,ユーザは罠にはまったことに気付きもしないだろう.
このことについて,当該銀行のカスタマーセンターに問い合わせてみた.「この問い合わせは情報処理学会の論文を書く際の資料とするためのものである」旨を伝えて問い合わせ,最初の電話から最終回答までに5 日間かかって得られた回答が図5である.
こうしたシステム面の問題以外にも、現在のインターネット・バンキングには、 セキュリティを損ないかねない、いくつかの問題が存在する。例えば、一部の金融 機関が提供するインターネット・バンキングでは、ログイン時に、強制的にブラウ ザーの表示設定が「アドレス・バーを表示しない」に変更され、現在接続している サイトのアドレスが隠されてしまう。ブラウザーを用いてウエブ・サイトに接続す る場合、利用者は、自分が確かに意図したサイトに接続しているかどうかをアドレ ス・バーで確認することができるが、これらの金融機関のサイトに接続した場合、 その確認ができないため、「偽ウィンドウによる攻撃」に対して脆弱になってしま う。この攻撃は、攻撃者が利用者を罠にかけて、利用者のパソコンの画面上に当該 金融機関のウエブ・ページに似せた偽ウィンドウを開かせ、そこから入力させたパ スワード等を攻撃者のサイトに転送させて情報を奪取するものである。普段からア ドレス・バーが表示される設定となっていれば、利用者は表示されたアドレスを確 認することでウィンドウが本物か偽者かを判断することができる。しかし、これら の金融機関は、常にアドレス・バーを隠すことによって、利用者がアドレスを確認 しないように習慣付けてしまっていることになる。さらに、一部の金融機関のイン ターネット・バンキングにおいては、利用者がアドレス・バー以外の方法(マウ ス・ボタンを右クリックし、ページの属性情報を表示させる等)によりアドレスを 確認しようとしても、そのための操作がシステム的に禁止されてしまっている。
このように、現在のインターネット・バンキングのシステムを、ウエブ・アプリ ケーションの安全性という観点から評価すると、十分な対策が講じられているとは 言い難い面がある。
サイトなりすましの死角
今回の調査でもう一つ目立ったのが,身元を隠すサイトの多さである。確認で きただけでも,144行中32行がログイン画面のアドレス・バーを非表示にして おり,うち18行が右クリックを禁止している(表1-C)。こうしたサイトは, サイト自体をなりすまされるリスクがある。銀行のサイトに似た偽サイトを立 ち上げられると,ID/パスワードを盗まれてしまう。
例えば「キャンペーン実施中!」などの偽メールを配信し,そこから偽サイト に顧客を導く。そうとは知らず顧客は偽サイトにID/パスワードを送信してし まう。送信後は「ただいまサービス停止中です」といった画面を表示したり, 正規のサイトへ中継したりすれば,すぐに気付きにくい。アクセスを中継すれ ば,不正な資金移動までされてしまう可能性もある。
Webでサービスを提供する企業も考える必要がある。その最たるものが,前述 の「アドレス・バー」を隠すページである。「アウトソーシングしているので, その企業のドメインではない。アドレス・バーを表示させると,ユーザーが 不安がるだろうから非表示にしている」といった理由から隠していると筆者に は思われる。
しかし,そのような余計な配慮が,アドレス・バーを非表示にしていても怪し く感じさせない土壌を作っているように思えてならない。アウトソーシングし ている場合には,その旨をきちんとユーザーに分かりやすく説明した上で, 堂々とアドレス・バーを表示すべきだろう。
全国の主要銀行百二十行について、フィッシング対策に重要と思われる項目を 調べた。調査内容は専門家が指摘する(1)公式サイトに接続しているか確認 できる「アドレスバー」を隠していないか(2)証明書や暗号化の有無が確認 できる「ステータスバー」を隠していないか(3)公式サイトと偽サイトを混 同する原因になりやすい「複数ドメイン名」を使っていないか――の三点だ。
その結果、満点だったのはみずほ銀行、UFJ銀行、三井住友銀行、シティバ ンク銀行、ジャパンネット銀行、中央三井信託銀行、住友信託銀行、北陸銀行 の八行だけだった。
アドレスバーを隠していたのは東京三菱銀行や新生銀行など。ステータスバー を隠していたのはソニー銀行やイーバンク銀行など。これらを隠す理由はデザ イン上の理由や顧客の誤操作を防ぐためとみられる。しかし、安全性の面では 疑問がある。
(略)
米シティバンクの顧客を狙ったフィッシングに使われた電子メールを解析した。 (略) ポップアップ・ウィンドウにはアドレスバーやステータスバーがないので、操 作してアドレスなどを調べ、公式ページのものと比べないと本物かどうかは分 からない。しかし、銀行の公式ページがアドレスバーなどを隠していると確認 できないし、隠しているページに利用者が慣れてしまうと、だまされやすくな る。利用者の自衛策は不審なメールを無視することだが、見分けるのも難しい。
(略)
【表】銀行のフィッシング対策
アドレスバー ステータスバー 単一ドメイン
(略)
もう3年経っていた……。懐かしい。
先日、セ キュリティアンテナを見に行ったところ、 「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電子署名の検証に脆弱性があるという話がありました。具体的には、電子 署名に疲れた証明書の有効性が検証されてないということと、証明書パスの検証 もされてないという話でした。
それに対して対処したつもりが、実はまったくテストしてないのがばれてしま いました。証明書パスが間違っていても、「×」と出なくて、「○ 有効」みた いに出てしまいます。
これを修正したのが、改版履歴に
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日に以下のように報道していた。
JP Vendor Status Notesは10月28日、 メールソフト「鶴亀メール」v3.69以前に、S/MIMEの電子署名に関する脆弱性 が2件あると発表した。脆弱性の内容は、電子署名の証明書を偽装さ れたメールを正式な証明書として受信してしまう恐れがあるというもの。本脆 弱性は最新版のv3.71で修正されており、窓の杜や作者ホームページからダウ ンロードできる。まだ古いバージョンを使用しているユーザーはこれを機に最 新版へ更新しておこう。
こうした報道のための確かな情報源となるのが、JVNに求められる役割のはず だ。
だが、窓の杜は、鶴亀メール v4.00の発表に際して、以下のように報道してお り、S/MIME署名検証の脆弱性が修正されていることに触れていない。
(有)サイトー企画は16日、メールソフト「鶴亀メール」v4.00を公開した。今回のバージョンアップでは、新たに迷惑メールフィルター機能を搭載したほか、メール一覧を2段表示できるレイアウトなどが追加された。(略)
そのほかの変更点では、既存の“ウイルス対策”機能が強化されている。添付されたZIP形式の圧縮ファイル内を調べて、指定した拡張子のファイルが存在する場合に自動削除する機能が追加された。
また表示関連の変更として、メール一覧でSubjectとFromを2行で表示する新レイアウトや、一行おきに背景を色分けする“ストライプ表示”が追加されている。
16日に更新された JVNの情報が役立っていないことがわかる。
「影響を受けるシステム」のバージョン番号の部分を改定し忘れたのは、 JVNの単純ミスだったとしよう。 しかし、改定履歴を書かないのはまったく理解しかねる。
改定履歴さえ書いていれば、「影響を受けるシステム」のバージョン番号がお かしいことに気づくだろう。
率直に言って、JVNは、一般的に「文書を公表する」という仕事をするにあたっ て求められている基本的な能力に問題がある、そう言わざるを得ない。
*1 こうしたメールは、IPAの脆弱性情報届出窓口に 製品の脆弱性を届け出ていた人に対して、その件がJVNで公表された際に送ら れてくる。
JVN#B4BE09A4 が発表された。
影響を受けるシステム
- Shuriken Pro3
- Shuriken Pro3 /R.2
- Shuriken Pro3 /R.2 [ベリサイン セキュリティメールセット]
- Shuriken Pro3 Corporate Edition
としか書かれていないので、 どのバージョン以前にその脆弱性があるのか不明だ。
JVN#B4BE09A4に 対するベンダーの発表文には誤りがあるので、届出者として知っている事実を 書き留めておく。
今回のベンダー発表文には次のように書かれている。
現象2:
(略)
Shuriken Pro3(*) では、署名メール開封時には、メールの内容が改ざんされ ていないことだけを確認し、署名に使われた証明書が信頼できるかどうかは、 [表示 - 暗号・署名情報の表示] によって、証明書に関する情報を表示して、利用者ご自身にご判断頂く仕様となっておりました。
つまり、「証明書の信頼確認はメール開封時にはやらない仕様だった」と いうことが書かれているように読めるが、それは事実と異なる。 11月27日の日記「Shuriken Pro3 のS/MIME機能に何があったか」の図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はさすがだ。
Firefoxはどのくらい普及しているのだろうかと、この日記のアクセスログから、 訪問者が使用していたブラウザの種類を調べてみた。
図1のグラフは、/diary/ および /diary/*.html への GETアクセスについて、 日別に、ブラウザの種類を棒グラフ(目盛は左)に、アクセス数を折れ線グラ フ(目盛は右)に示している。 「others」にはランク外のブラウザの他に検索ロボットなども含まれている。
集計に使用したプログラムは以下の通り*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 ご利用はご自由に。