<前の日記(2005年02月11日) 次の日記(2005年02月16日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 76   昨日: 2746

2005年02月12日

ファーミング詐欺と区別がつかない自治体電子申請サイト

日経IT Proに勝村氏の「記者の眼」が出ていた。

pharming(栽培、耕作)というのは、なかなかよいネーミングではないかと思っ た。勝村氏は、ベンダーのセールストークということを気にしているようだけ ども(私もフィッシング対策でアドホックな対策技術のビジネス展開には疑問 を感じるが)、フィッシングでないものまでもフィッシングと呼ぶよりはよい のではないか*1

勝村氏は、おそらくメディア記者の中で最もセキュリティ話に強い記者さんで はないかと思う。かなりマニアックな話題が出てくることもあり、技術的に深 く突っ込んで解説されていることが多いし、間違ったことが書かれることが少 ないし、ベンダーの宣伝に踊らされることもない。が、足りないところもある ので、突っ込んでおこう。

今回の話題は、

具体的には,(1)ウイルス(ワーム)などを使って,クライアントのhostsファ イルを書き換える,(2)DNSサーバーに虚偽の情報をキャッシュさせる(これ は「DNSポイズニング」と呼ばれる)――など。(略)

ユーザーとしては,「メール中のURLをクリックせずに,自分でアドレス・バーにURLを入力する」といった,フィッシング対策の一つを実施しているにもかかわらず,偽サイトへ誘導されてしまうのだ。ブラウザのアドレス・バーには,正規のURLが表示されているので,偽サイトだと見抜くのが難しい。

pharming(ファーミング)――オンライン詐欺は「釣り」から「農業」へ?, 勝村幸博, 日経IT Pro 記者の眼

という話であるが、そのケースであれば、ブラウザの錠前アイコンを確認すれ ばよい。そもそも、フィッシング詐欺に遭って困るような情報を入力するとき は、通信が暗号化されていることを確認するのが基本だ*2

hostsの書き換えで誘導される偽サイトは、ドメイン名は本物であるのだから、 本物ドメイン名でのSSLのサーバ証明書を、詐欺師達は持つことができない (認証局がミスをしない限り)ので、もし https:// ページになっているなら、 必ずブラウザが警告を出す。

偽サイトがよそのサイト用の正規のサーバ証明書を使っているなら、IEでは 「セキュリティ証明書の名前が無効であるか、またはサイト名と一致しません」 と出るし、偽サイトがサイト名を一致させようとすれば、偽の認証局から発行 するしかないので、「このセキュリティ証明書は、信頼する会社から発行され ていません」と出る。Firefoxならば、「あなたの個人情報を入手するために www.example.co.jp であると偽装しているサイトに接続しようとしています」 とズバリそのものの警告が出る。

なぜこの自衛策のことをもっと書かないのだろうか。「ファーミング」の話は ここ最近あちこちで報道されているが、錠前アイコンを見よという話はどこで も出てなかったような気がする*3

いちおう、勝村氏の記事でも、最後の部分で、証明書をチェックという話は出 てきている。しかし、

また,DNSサーバーに虚偽の情報をキャッシュされた場合などに備えて,個人情報などを入力するページでは,SSLが使われていることを確認するとともに,ディジタル証明書の内容をチェックしたい。DNSポイズニング攻撃などを受けないように,DNSサーバーの管理者がきちんと対策を施すことも重要だ。

pharming(ファーミング)――オンライン詐欺は「釣り」から「農業」へ?, 勝村幸博, 日経IT Pro 記者の眼

この書きぶりだと、SSLが使われていることの確認が、DNSスプーフィング攻撃 にのみに有効な対策のように読めてしまうが、hosts書き換えにも有効なのだ。

それに、DNSポイズニング攻撃は、DNSサーバの管理でどうにかなるかもしれな いが、それ以外のDNSスプーフィングもあり得て、そちらは脆弱性が原因では なく、盗聴されるのと同じようにあり得る話なので、管理で防ぐ話ではないの ではないか。そうした攻撃があり得るため、(フィッシング、ファーミング以前に) SSLの確認が必要になっているわけで、微妙に誤解があるように読める。

偽サイトで警告が現れるという話をぜひ書いてもらいたいものだ。どんな場合 にもこの警告が出たら「いいえ」を押すという習慣を徹底する。仮に「はい」 を押しても、その先の画面は偽かもしれないと意識して、情報は入れない。

そして、日本の自治体はこの警告を出しまくっていると。

そのルート証明書は本物?それともファーミング用?

上では、ファーミング詐欺サイトでないか見分けるために、錠前アイコンが、 ブラウザの警告なしに現れているかを確認せよという話を書いたが、ファーミ ング詐欺師達がユーザに踏ませるトロイの木馬が、hostsを書き換えるのと同 時に、偽のルート証明書までインストールしてしまっていたら、これは有効な 自衛策とならない。

ということは、ファーミング詐欺が流行りつつあるという今、求められている ことは、Windowsの「信頼されたルート認証機関」に入っている各証明書が、 本物かどうかを確認する手段を確立することであるはずだ。

偽認証局の証明書は誰にでも作れ、認証局の名前は自由につけられるので、見分ける手段は、フィンガープリントしかない。

現状では、一個一個フィンガープリントを目視で照合するしかないのかもしれ ないが、そのために、正規のフィンガープリントの一覧表というものが必要だ が、どこかにあるのだろうか。

近いうちに、自動でチェックするツールが必要になるだろう。*4

しかし、LGPKI Application CA のように、自力で追加インストールしたルー ト認証局がいっぱいあると、そうした自動チェックツールに頼れなくなる。 どうすればよいのか?

JPRSの偽サイト登場??

http://xn--wgv71a119e.jp/access/phishing.html

このサイトは本物だろうか? URLを見ても判別できない。INTERNET Watchの 記事からリンクされていたのだが。

どうやら、これの記述に従ったものらしい。

日本語JPドメイン名のサイトへのリンクの記述方法

日本語JPドメイン名でアクセスできるサイトへのリンク方法はとても簡単です。 「日本語.jp」にリンクしたい場合
<a href="http://日本語.jp/">日本語.jp</a>
もしくは
<a href="http://XN--WGV71A119E.jp/>日本語.jp</a>
という形でhtmlファイルに記述します。

http://xn--wgv71a119e.jp/support/index.html#link, 登録・運用・サポート - 日本語.jp

後者でリンクしてしまうと、偽サイトかどうか確認できない。

下記ページで当該ドメイン名がPunycodeでどのように表現されるか確認することができます。

http://xn--wgv71a119e.jp/support/index.html#link, 登録・運用・サポート - 日本語.jp

とあるが、むしろ逆変換の方が重要なのではないか?

ブラウザが逆変換してアドレスバーに表示するべきだとも思うが、 どうだろうか。

このままだと、Punycodeでリンクしまくる人たちが大量発生して(自治体とか)、 アドレスバーが無いも同然になってしまうおそれがある。

ああ、いやな予感がする。

ところで、

現実には、フィッシングでは誘導先のURIを偽装したり隠蔽したりするなど、 もっと巧妙な手段が使われていることから、視覚的に似たドメイン名を使用す ること自体はあまり有効なフィッシング手段ではないと考えます。

http://xn--wgv71a119e.jp/support/index.html#link, 登録・運用・サポート - 日本語.jp

この主張はいただけない。

URLを偽装できるのは、ブラウザかサイトに脆弱性があるのが原因であり、 それは取り除かれるべきであるし、隠蔽されているところに入力しないという リテラシが確立されるべきであるのだから、きちんと対策と理解が進めば、 最後には、似通ったドメイン名の問題だけが残ることになる。

現時点で相対的に「あまり有効なフィッシング手段ではない」とするのはけっ こうだが、期限を限定せず絶対的に「あまり有効なフィッシング手段ではない」 と言ってしまうのは、「他の人らかて駐車違反してるやん」と言う大阪のおば ちゃんのようなものだ。JPRSともあろう者が見苦しい。

あ、JPRSじゃないかもしれないけど。

*1 フィッシングとファーミングでは、責任の所在や、ユーザの自衛策のあり方の 点で、性質が異なっているように思う。フィッシングでは、アドレスバー偽装 が可能なブラウザの脆弱性が排除されていれば、また、本物サイトのクロスサ イトスクリプティング脆弱性が排除されていれば、つまりベンダー達が責任を 果たしていれば、あとは、ユーザがアドレスバーの確認を怠らないというリテ ラシーが肝となる。それに対してファーミングでは、hostsが書き換えられる ことなどは本来あってはいけないことで、スパイウェアなどに感染してしまっ た(添付ファイルを実行してしまったなど)ユーザの責任、もしくは、任意コー ド実行を許してしまうブラウザの脆弱性に原因があるということになる。 むしろ、何でもかんでも「フィッシング」とひとくくりに言う人たちにこそ、 ユーザの自衛策を整理せずに、製品でアドホックに対策しようとする商魂が見 え隠れするのではないか?

*2 確認は必ず自 分でやらないと意味がない。サイト側が暗号化されるようにリンクを作ってく れているはずだから確認しなくてよい――という考え方は誤りである。なぜな ら、暗号化ページに入る前の非暗号化ページで、通信路上でパケット改竄され たら、リンク先が本来「https://」であるところを「 http://」に書き換えら れるということが起こり得るので、情報を入れようとしている画面が https:// になっていることを自分で確認する必要がある。

*3 それこそ、対策ソフト売りベンダーに、 そういうことをあえて言わないでおく動機があり得る。

*4 あるい は、[memo:3827] に書かれているように、 証明書を削除してしまって、正規のものだけ復 活するのを待つという手もあるかもしれない。 Windows XPでは、「Windowsコンポーネントウィザード」で「ルート証明書の 更新」がONになっていれば、削除したルート証明書が必要に応じて復活する。 しかし、ルート証明書の安全なダウンロードのために、Microsoft認証局発行 の証明書による署名を検証しているはずなので、全部削除するとその仕組みも 動かなくなるかもしれないので、それはやらない方がよいかもしれない(未確 認)。 ちなみに、特定の認証局を信じたくないときは、削除するのではなく、証明書 を表示して、「詳細」タブで「プロパティの編集」ボタンを押し、「証明書の 目的」のところで「この証明書の目的をすべて無効にする」を選択すればよい。

本日のTrackBacks(全84件) [TrackBack URL: http://takagi-hiromitsu.jp/diary/tb.rb/20050212]

Firefoxならば、「あなたの個人情報を入手するために www.example.co.jp であると偽装しているサイトに接続しようとしています」 とズバリそのものの警告が出る。 ズバリな警告だなぁ。これは日本語版の警告なのだろうか? 英語FireFoxで「Security Error: Domain Name Mismatch..

pharming(ファーミング)――オンライン詐欺は「釣り」から「農業」へ? 久々のエントリでこんな話題するのもなんだけど. ネーミングがおもろかったのでつい. フィッシングの場合は公式サイトからの情報に見せかけて詐欺サイトに誘導するのに対して,ファーミングでは,..

ウィルスなどが OS のファイル hosts に偽の IP アドレス情報を登録することで、ユーザを偽サイトに誘導するフィッシング詐欺への注意が呼びかけられています。

ファイル hosts は、ドメイン名から IP アドレスを調べるときに、最初に参照するファイルです。そのため、こ

偽装した無線LANアクセスポイントを仕掛け、DHCPに偽サイトを登録したDNSサーバを設定することで最近はやりのファーミング(Pharming)が可能だ。不用意に疑わしい無線LANには接続しないとともに、重要情報をWebから入力する際はサーバの証明書の確認をしっかりと行うよう..

24LIVE:IT用語:ファーミング (2005年05月26日 00:57)

最新のインターネット詐欺です。ご注意を。DNSサーバやHOSTSファイルをターゲットにするというのは、なかなか新手の手法ですが、「だます」という意味では、とても確実で有効な手段です・・・って、肩をもっ...

検索

<前の日記(2005年02月11日) 次の日記(2005年02月16日)> 最新 編集

最近のタイトル

2024年11月11日

2024年07月28日

2024年07月27日

2024年07月07日

2024年04月07日

2024年04月01日

2024年03月23日

2024年03月19日

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|04|07|11|
<前の日記(2005年02月11日) 次の日記(2005年02月16日)> 最新 編集