■ PayPalフィッシングにひっかかりそうになった

木曜の夕方から風邪をひいて療養中。昼間寝すぎて寝付けないので日記でも書く。

フィッシングといえばPayPalが発祥の地。実際にどんな状況なのか知るために使ってみるべきだったが、実はこれまで一度もPayPalを使ったことがなかった。2月からWindowsマシンを捨ててMacに乗り換えて以来、シェアウェア料金を支払う場面に出くわすようになった。十年ぶりにKagi.comのシェアウェア支払いサービスを利用したとき、PayPalによる支払いの選択肢があったので、試しに使ってみることにした。

PatPalにアカウントを作成すると何通かのメールがやってくるのだが、これがHTMLメールになっている。このとき、「こんなことやってるからフィッシングにひっかかりやすくするんだよ」と思った。

図1: PayPalでアカウントを作成する際に送られてくるメール

アカウント作成時に、カードの有効性確認のためだろうか、200円が引き落とされ、後でカード明細の載っている番号を入力すると返金されるという仕組みになっていた。このとき、「こういうややこしい手続きが正規サイトにあるとフィッシングに騙されやすくなるんだよな」と思った。

そしてその翌日、こんなメールが来た。

図2: PayPalを騙った偽メール

典型的なPayPalフィッシングだが、これにひっかかりそうになった。いや、もちろんひっかかりはしないのだが、一瞬とはいえ「げげ、なんかトラブルが起きたのかな」と思ってしまった。

PayPalフィッシングのメールなんぞ飽きるほど見てきたはずだが、ここでそう思ってしまったのは、実際にPayPalにアカウントを作成した翌日だったからだ。しかも、そのタイミングで、spamフィルタをすり抜けてきたことが大きい。

Macに乗り換えて以来、Mac OS X 10.5標準のメールソフト「Mail.app」を使用していて、標準搭載されているspamフィルタ機能を利用していた。フィッシングのメールもspam扱いで自動的にspamフォルダに振り分けられていたため、PalPalフィッシングのメールを目にすることはない状態になっていた。

ところが、PayPalにアカウントを作成した途端、spamフィルタをすり抜けて、PayPalフィッシングのメールを目にしたわけだ。この原因として、本物のPayPalからの連絡メールを受信したことが、spamフィルタのspam判定閾値を上げたためではないかと考えられる。

よく見てみれば、PayPalに連絡先として登録したメールアドレスと、spamが大量にやってくる公開アドレス（この日記の連絡先アドレス）とは別にしているわけで、今回も、フィッシングメールは公開アドレスの方に来ていた。どうやら、Mail.appのspamフィルタの学習は、メールアカウントをまたがって影響してしまうようだ。

私がPayPalにアカウントを作成したことが察知されてspamが送られてくるようになったわけではないのだから、公開アドレスの方には過去にもPayPalフィッシングのメールを受信しているはずだ。spamフォルダの中身を確認してみたところ、やはり、以前から毎日のようにPayPalフィッシングのメールを受信していた。

「なるほど、これは騙されてしまう人が出るのもうなづける」と思った。

試しに偽サイトを訪れてみると、本物と同一の画面が、「paypal.user-updates.com」というサイトで表示された（図3）。あり得ないIDとパスワードを入れてみたところ、認証が成功したふりをして（図4）、カード番号やらを入力させる画面が現れた（図5）。

図3: PayPalの偽サイトの画面

図4: PayPal偽サイトが認証が成功したふりをしている様子

図5: PayPal偽サイトがカード番号等を入力させようとしている様子

ちょうどこの日、勤務先の本業で「パスワード相互認証プロトコルの技術評価用ソフトウェアを公開」というプレスリリースを出した。フィッシングを防止しようとするものなのだが、これを提案すると必ず出てくるのが「そんなので全てのフィッシングが防げるわけがない」という声だ。

たしかに、何の心得もない人を救うことはできないが、それはいかなる技術をもってしてもそうだろう。

基本はドメイン名を確認することだが、どんなにネットに慣れている人でも、焦っているときや偶然のタイミングでは確認をミスしてしまうこともあるだろう。実際、Ruby開発者のまつもとゆきひろ氏や、アルファブロガーの池田信夫氏でさえ、フィッシングにひっかかったことを告白している。

• フィッシング (phishing), Matzにっき, 2005年10月20日

  PayPalからHTMLメールが届いていて、うっとうしいので今後テキストメールに変更しようと操作したら、まんまとフィッシングに引っかかってしまった。

  慌ててパスワードを変更して亊無きを得たが、危なかった。慌ててる私を見て妻が「専門家でも引っかかるのね」。（以下略）

• フィッシングにご注意, 池田信夫 blog, 2007年1月28日

  間抜けなことに、フィッシングに引っかかってパスワードを盗まれてしまった。amazon@teamservice.comというアドレスから（略）というメールが来て、ちょっと変だなと思いつつ、そのURLをクリックすると、図のようにAmazon.comそっくりの画面が出てくる。ここでアドレスとパスワードを入れると、クレジットカードの番号を入力する画面が出てくる。（以下略）

最近では、大規模なspamで誘うフィッシングは、ブラウザのフィッシングサイト検出機能で防がれるようになった。図3のサイトも、私がメールに気づいた時点では、Internet Explorer 7でアクセスすると図6のようになったし、Firefoxでアクセスすると図7のようになった。

図6: IE 7で既知のフィッシングサイトがブロックされた様子

図7: Firefox 2で既知のフィッシングサイトに警告が出た様子

しかし、これらは誰かが先に「ここはフィッシングサイトだ」と報告してくれたからこのようにブロックできたわけで、報告される前にひっかかる何人かには被害が出ているだろうし、「スピアフィッシング」などと呼ばれる、ごくわずかの人を狙って誘うケースでは、これらの仕組みではブロックされないだろう。

実際、日本国内のフィッシング発生状況を見ると、国家公安委員会らの発表「不正アクセス行為の発生状況及びアクセス制御機能に関する技術の研究開発の状況について」によれば、平成19年度の不正アクセス犯罪の検挙数1,438件のうち「フィッシングサイトを開設して識別符号を入手したもの」が1,157件もあるというのだが、そのわりには、日本向けのフィッシングサイトが登場したという話をめったに聞かない。表沙汰にならないのは、ごく少数の相手を狙って偽サイトに誘う行為が横行しているためだろう。

以前にも書いたように、自分が知っているサイトであることを確認する方法は、ドメイン名を目視確認する方法の他にも、「信頼済みサイトゾーン」を活用する方法や、「petname tool」を使う方法などがあるが、それらのように準備として別途ローカルに確認済みサイトを登録する作業を必要とせずに、パスワードの入力によって確認されるというのが、「HTTP Mutualアクセス認証」という新たに提案しているプロトコルだ。

これが普及すれば、Webアプリケーションのログイン機構を自前で設計・実装しなくて済むようになり、それに起因する脆弱性も排除されるという意義もある。（CSRFは従来通り対策が必要だが。）Basic認証やDigest認証に並ぶ第3のHTTP標準の認証方式となるよう、ブラウザベンダに働きかけていきたい。

本業のことはあまりここには書かないポリシーなのでこのくらいにして、寝るとしよう。ゲホゲホ。