前回の日記では、「原因の究明が遅れていた可能性」として、
このことからして、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」となるところだった。
高木浩光@自宅の日記より 1か月半もの間これに気づけなかったのは悔やまれる。ここ