cyber BONMEE

■ スパム対策プラグインのAkismet

WordPressにはスパムを検知して隔離するAkismetというプラグインがあります。

1年ほど前に書いたエントリーと重複しますが、このAkismetも単にスパムを隔離するだけで、実は根本的な解決にはなりません。何故ならば、「隔離する」ことと「ブロックする」ことは別だからです。

ほとんどのスパマーは同じコメントをスクリプトで大量に送信しますので、書き込めたかどうかを人が目で見て確認することはありません。あくまでサーバーが返すステータスコードだけを見ており、そこで301や302、あるいは403や404が返れば「失敗」、200が返れば「成功」となります。

Akismetはブロックではなく隔離ですから、サーバーはステータスコード200を返しています。

彼らにとっては通ったコメントが表示されていようがいるまいが関係ないので、これはスパム送信成功を意味し、その該当記事は「今後も送り続ける」対象のリストに残ってしまいます。根本的な解決にならないというのはこの部分です。

じゃあ、どうすればいいか。

■ 根本的な解決策を探る

スパマーは各記事に配置されているコメントフォームから送信しているのではなく、コメントフォームに書き込んだ時と同じクエリをwp-comments-post.phpに直接送って来ます。ですから「それを止めてしまえ」というのもひとつの考え方ですね。

一口に「止める」と言っても、考えられる方法はいくつかあります。

とりあえず効果がありそうに思えるのは「HTTP_REFERERにブログ本体のドメインを含む場合にポストを許可する」ようphpコードを書き換えること。スパマーが自動送信して来るコメントは大抵referrerを持ちませんから、この方法はかなり有効かと思われます。

ただ、これには大きな問題点がひとつあります。それは「非常に面倒くさい」ことです。

phpコードを書き換える訳ですから、いくつものファイルに分かれているプログラムのすべてに目を通し、矛盾が生じないよう書き換えなければなりません。これだけ考えても余裕で眠くなります。

加えて、WordPressのアップデートを行うたびにその作業が待っています。

自分が書いたプログラムならば全体のブロックダイアグラムはおおむね把握していますが、それでもかなりの面倒な作業になるでしょう。ましてWordPressは他人様が書いたプログラムです。改造したものを売る気ならともかく、ただの日記趣味にそこまでの労力は費やせません。

■ 古典的な手法

昔からある古典的な方法としては「wp-comments-post.phpをリネームする」というものがありますね。スパマーはそこへ直接actionしてクエリを送って来るのですから、確かにこれも有効だと思われます。

ただ、この方法にも大きな問題点があります。それは「人の目でソースコードを見られたら一瞬でバレてしまう」ことです。

昔、Perlで書いたCGIにスパムがよく来ていた頃、投稿フォーム部分のコードを外部の.jsファイルに格納してdocument.writeで書き出していたことがあります。

action先をソースコードから消せるため当初は効果がありましたが、そのうち誰かが外部の.jsファイルを見たんでしょうね。一度バレたら後はもうザル状態になり、私はまたコードを書き換えてと、結局は無限ループのいたちごっこになってしまいました。

当然、この方法にも限界はあるということです。

■ 一番マシな方法はどれ？

ただ、action先をリネームする方法は、一度ざっと全体のコードを見通せばいいだけ（読む必要はない）ですから比較的簡単ですね。現時点でのデフォルトのアクション先はwp-comments-post.phpですから、そのファイル名が登場する部分がどことどこにあって、という情報だけを掴んでおけば簡単に対処出来そうです。

どのファイルにwp-comments-post.phpという記述があるかを調べるには、コンソールから$ perlを実行して下記のプログラムを打ち込みます。


$ cd wordpress/wp-content/themes/bible-scholar
$ perl
@_ = `ls | grep php`;
foreach $_(@_){
　$cat = `cat $_ `;
　if($cat =~ /wp-comments-post/){
　　print;
　}
}
C^d


テーマディレクトリにあるファイル名からphpが付くものだけを抽出して配列に格納し、foreachで回しながら`cat`でファイルの中身を吐き出させて$catに格納、wp-comments-postにヒットしたファイル名だけを出力させます。簡単ですね。

これを実行すると、なんとcomments.phpだけがヒットします。あれ？

そういうことなら、この方法が一番お手軽ですね。これにしましょう。かなりベタなやり方ではありますが。

■ 必要なファイルの書き換えとリネーム

wp-comments-post.phpをリネームするだけでは、action先がnot foundになってコメントポストが出来ません。ですから、まずはそこを書き換えます。

Dashboardから[Appearance]→[Editor]→[Comments.php]で開き、下にスクロールして真ん中付近にありますね。そこのwp-comments.post.phpを、何か適当なファイル名に変更します。hana-mogera.phpでもqawsedrftgyhujiko.phpでも何でも構いません。

次に、ローカルでwp-comments-post.phpを同じ名前にリネームしてからftpで送ります。これでコメントポストを試したところ、問題なく投稿出来ました。

ただ、これで終了という訳ではありません。上に書いた通り、場合によってはスパマーとの「いたちごっこ」が起こり得るからです。

あと、これは私が使用しているBible Scolarというテーマの場合に限った話かも知れません。他のテーマの場合は分かりませんので、上記のperlスクリプトなり他の方法なりで事前に丁寧に調べておく必要はあるでしょう。

メール本文に張られたリンクを踏むと、顧客情報の登録フォームへ飛びます。

そこで必要な情報を入力し、送信すれば・・・カード番号やセキュリティコード、PINコード（暗証番号）までもが悪意の第三者に渡るということです。怖いですねぇ（笑）。

このメールの巧妙なところは、（上にも書きましたけれども）メール本文にある登録フォームへのリンクが、正しくBank of Americaのドメインであるところです。

上の画像をクリックして拡大表示して頂くとお分かり頂けると思いますが、

http://www.bankofamerica.com/srv_55701/～

と、確かに bankofamerica.com に繋がるように見えますね。そのドメイン自体は本物のサイトにしか利用出来ないものですから、これは信じる人もいるでしょう、間違いなく。

ですが、ここで疑わなければならない点がふたつあります。

ひとつは、顧客情報を登録するフォームなのに、SSL接続ではないという点です。

リンクのURLは http:// で始まっていますね？ 普通、こういったデリケートな情報を扱う場合は https:// で始まるSSLを使用するものです。

しかし、詐欺グループなど素性を明かせない者たちには、SSL証明書は利用出来ません。ですから、まずここがこのメールのおかしな点です。

もうひとつは、銀行が個人情報の提供を求めるのであれば、普通はログインするのが先でしょう。メールのリンクを踏んだら即登録画面というのは、余りにも不自然です。

では、なぜフィッシングメールにBOAの正規ドメインへのリンクが張れるのでしょうか？

そこで、登録フォームを少し眺めてみました。

見つけました（笑）。

左のスクリーンショット、上が詐欺サイトの登録フォームで下が正規のBOAサイトなんですが、ブラウザのアドレスバーをよくご覧下さい。

bankofamerica.comの後にある筈の /（スラッシュ）が、詐欺サイトの方にはありませんね。

これは、bankofamerica.comに繋がるのではなく、vera1ab.netというドメインに繋がることが分かります。

このvera1ab.netをwhoisで確認しましたが、何も出て来ませんでした。もしかしたら削除してトンズラを決め込んだか、もしくは当局に消されたのかも知れませんね。

メールの発信元を確認すると、アウトゴーイングサーバーにはmail.slpag.deが使用されていますが、こちらはデンマークの個人が登録しているドメインのようですね。踏み台に使われたのでしょうか。

実際の送り主はpldt.netで、こちらはフィリピンのISPのようです。ということは、このフィッシングメールの送り主はフィリピンにいる、ということですね。

今、このエントリーを書きながらメールにあったリンクを踏んでみると、もう繋がらなくなっていました。しかし、犯人はまたドメインを変更して、世界中に同じようなメールを送り続けていることでしょう。

日本の皆さんはこのような英語のメールに引っ掛かることはないでしょうが、これを日本の有名な銀行名で、日本語でやられたらどうなるかを想像してみて下さい。絶対に騙されない自信はありますか？

自信がない方は、もう一度上記の本文をよくお読みになって下さい。ポイントは、

1. 銀行などが個人情報を求める場合は、必ずSSL接続を使用する筈
2. 顧客に情報提供を求めるのであれば、まずログインしてからフォームが表示される筈
3. ドメイン名が本物であるかを注意深く確認する

の3点です。

これだけ気をつけていれば、騙される危険性はかなり低くなるでしょう。十分にご注意なさることをお勧めします。