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

高木浩光@自宅の日記

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

2005年03月15日

銀行業界が自治体に苦情を申し立てても不思議でない

UFJ銀行を装った日本語phishingが発生した。

報道によれば、14日の21時半からUFJ銀行のコールセンターに通報が多数寄せ られたとのことで、UFJ銀行は15日の11時ごろに注意喚起の発表をしたようだ。

公式見解がプレス向けに発表されることで、一般紙が報道として扱えるように なる。そして事実が幅広く市民に周知され、そして被害の拡大が抑えられる。 このように、迅速な公式発表は顧客保護のために重要である*1

さて、そのUFJの注意喚起文を見てみる。

■UFJ銀行のホームページを安全にご利用いただくため以下の点をご確認ください

◎UFJ銀行のホームページで暗証番号、パスワード等の重要情報の入力を受付 ける場合には、SSLによる暗号化通信を行っております。SSLによる暗号化通信 が行われるページのアドレスは「https://」から始まっており、画面の右下 (Webブラウザのステータスバー)に鍵のマークが表示されます。鍵マークを ダブルクリックしてサーバ証明書を表示し、UFJ銀行のドメインおよび英文 組織名が書かれていることをご確認ください。

【UFJ銀行のSSL(暗号化通信)証明書】

・UFJ銀行のドメイン名は「ufjbank.co.jp」です。証明書の「発行先」は 「www.ufjbank.co.jp」「direct.ufjbank.co.jp」のように、「ufjbank.co.jp」 で終わっています。

・UFJ銀行の英文組織名は「UFJ Bank Limited」です。

(略)

UFJ銀行を偽装した電子メール詐欺が発生していますのでご注意ください, UFJ銀行

ここまでは適切な説明だ。続いて「証明書の確認方法はこちら」として、 「SSL(暗号化通信)証明書の確認方法」 というページが紹介されている。ここを見ていくと、上の方には、アドレスバー とサーバ証明書の「発行先」ドメイン名を確認する方法が書かれており、真ん 中あたりには、証明書の「詳細設定」の「サブジェクト」欄で英文組織名を 確認する方法が説明されている。

問題はその下だ。「2.証明書の発行元の確認」として、このサーバ証明書が VeriSignによって発行されていることを確認する方法が説明されている。

2. 証明書の発行元の確認

当行は日本ベリサイン(株)発行のSSLサーバ証明書を使用しています。証明書 の発行元が正しいことの確認方法は以下の通りです。

(1) 「証明のパス」タブをクリックして表示された画面で、「VeriSign/RSA Secure Server CA」を選択し、「証明書の表示(V)」をクリックする。

(2) 「詳細設定」タブをクリックして表示される「拇印」の値と、証明書発行元の日本ベリサイン(株)のルート証明書表示ページ(https://www.verisign.co.jp/repository/root.html)に記載の数値が一致することを確認する。

SSL(暗号化通信)証明書の確認方法, UFJ銀行

これはどうだろうか。証明書発行元認証局のルート証明書のフィンガープリント まで確認せよと言っている事例は珍しい。

本来ならばそこまで確認する必要はない。ルート証明書のフィンガープリント が一致しない状況があるとしたら、ユーザが、偽のVeriSignルート証明書をイ ンストールしてしまっている場合であり、それは、ユーザが手作業で入れてし まった場合と、スパイウェアやトロイの木馬などを誤って実行した(もしくは 脆弱性を突かれて強制的に実行させられた)場合がある。

たしかに、昨今では「ファーミング詐欺」 という、フィッシングとは別の呼称まで付けられた攻撃手法が流行りつつある と言われている。hostsファイルを書き換えられたうえ、偽VeriSign証明書を 入れられてしまっている場合、ブックマークなどから https://www.ufjbank.co.jp/ のURLにアクセスしても、偽サイトにつながったうえ、偽サイトにSSLで接続し ているときにはブラウザが出してくれるはずの警告ダイアログも出なくなって しまう。だから、UFJ銀行としては、フィンガープリントを確認せよと言って いるのかもしれない。

しかし、そのような状況においては、UFJ銀行が説明している方法は、本物で あることの確認にはならない。

なぜなら、偽のVeriSignルート証明書を入れられてしまっている状況では、 「日本ベリサイン(株)のルート証明書表示ページに記載の数値」 も偽ページであることを否定できないからだ。攻撃者は、 www.verisign.co.jp のホスト名を偽のIPアドレスで hosts に登録し、 偽の www.verisign.co.jpサーバ証明書を偽VeriSignルート証明書で発行して 偽サイトを動かす可能性があるのだから。

したがって、UFJ銀行のこの説明は不適切である。誤った確認方法を正しい確 認方法であるかのごとく人々を誤解させる点で、有害である。この確認に意義 があるかというと、攻撃者が偽VeriSignルート証明書を人々に入れさせていな がら、「日本ベリサイン(株)のルート証明書表示ページ」の偽装まではやって いない場合には意義があると言えるが、それは小さな益であり、それに比較し て人々を混乱させる害の方が大きい。よって、この解説は削除するべきである。

なぜ、銀行がこのようにフィンガープリントを確認せよなどという普通でない 説明をしてしまうのだろうか。ひとつには、日本ではあちこちの自治体が、 LGPKI Application CAのフィンガープリントを確認しなさいと、そこらじゅう で説明しまくっているためではなかろうか。UFJ銀行の担当者はその種のもの を目にした経験があって、見よう見まねで、事の本質を考えることもなく、 書いてしまっているのではないか。

偽のルート証明書が入ってしまっていないかを確実に確認する術は、いまのと ころない。オンラインではどうやっても完全にはできないだろう。CD-ROMで 販売されるソフトウェアにそうした機能を搭載するか、オンラインで配布する チェックツールに電子署名を付けて、そのフィンガープリントを紙媒体の雑誌 や新聞の記事に掲載して、それを使用者が自らの理解に基づいて確認するしか ない*2。 したがって、ルート証明書の真正性確認の説明は、一介の企業であるUFJ銀行 がやることではない。

むしろ、こういうときに銀行がやるべきことは、オレオレ証明書の警告が出た ら必ず「いいえ」を押しなさいという説明をすることだろう。たとえばこんな ふうに書けばよい。

■○○銀行を安全にご利用いただくため以下の点にご注意ください

1. (略)

2. ブラウザの警告に注意する

当行は△△発行のSSLサーバ証明書を使用しています。Internet Explorer 6、 Mozilla/Forefox、Opera 6 などのブラウザでは正常にお使いいただけること を確認しております。

ブラウザが以下の図の警告を出したときは、異常な事態であることを示してお り、お客様のコンピュータが偽のサイトに接続している可能性が否定できませ ん。「いいえ」を押してアクセスを中止してください。

そもそも、この警告が出たら「いいえ」を押すのが当然の常識として人々に もともと理解されているはずのところが、昨今では、その常識が崩れつつある。 その原因は、自治体の電子申請システムだ。自治体の愚かな行いが、銀行に対 するphishing攻撃の危険性を増大させている。

そもそもWebのサーバ証明書は、Webというグローバルなアプリケーションドメ インに対して設定されたそれ固有のPKIモデルで稼動しているものであり、 銀行をはじめとする事業者たちはこれまで、そのモデルのルールに則って証明 書を購入し運用してきた。そこへ、後からやってきた役所の連中が、そのモデ ルのルールを無視し、勝手認証局を立て、「私達も仲間ですよ」と利用者達を たぶらかしている。(ブラウザベンダーに対して「仲間に入れて」とお願いす るのではなしに。)

銀行業界は、このような自治体の迷惑行為に対して、やめてもらえないかと、 要請してはどうか。

ちなみに、話を戻すと、

当行では、電子メールではこうしたご連絡はいたしておりませんのでご注意ください。

UFJ銀行を偽装した電子メール詐欺が発生していますのでご注意ください, UFJ銀行

とあるが、UFJ銀行は3年前にこんなメールを顧客に流したという実績がある。

**************************************
             UFJ銀行誕生ごあいさつ
        三和銀行と東海銀行は、UFJ銀行になりました
**************************************

三和銀行と東海銀行は、2002年1月15日に合併し、UFJ銀行として新たに
スタートいたしました。

――――――――――――――――――――――――――――――――――――――
        インターネットバンキングのご利用について
――――――――――――――――――――――――――――――――――――――

●現在、UFJ銀行のホームページは、アクセス集中により、大変つながりにくく
 なっております。お客さまには大変ご迷惑をおかけし、誠に申し訳ございません。
 しばらく経ってからご利用いただきますようお願い申し上げます。

 尚、インターネットバンキングのご利用は、当面、下記のURLよりログイン
 していただきますようお願いいたします。

  http://www.csweb.co.jp/TBK/ufj/login.htm

このメールに対する返信は受付できませんので、ご不明な点等がございましたら、
下記までお問い合わせください。

――<お問い合わせ先>――――――――――――――――――――――――――― 
(略)

 ◇このメールは、旧三和インターネットバンキング2000ご契約者および
 旧<東海>ダイレクトの方に配信しております。
――――――――――――――――――――――――――――――――――――――

さすがに、フィッシング詐欺がこれだけ認知された今では、こうしたメールが 流されることはないだろうと思われるが、実際につながりにくい事態が今後起 きた際には、どうするのだろうか? やはり、公式メールには電子署名があるのが当然という世論形成を今から準備していくしか ないだろう。

Phishing報道は何を伝えるべきか

今回のphishing事案で、ネットのメディアは画像付きで報道しているが、 そのいくつかは、どういうわけか、わざわざアドレスバーを隠した画面を掲載 している。なぜこういうことをするのか理解しかねる。

「実際のUFJ銀行のサイトと見た目は同じ」というのは当たり前であり、 単に恐怖を煽るのが報道の目的でないのなら、 どうやって見分けるかを伝えることこそが画面掲載の意義だろう。

その点、ITmediaの報道では、アドレスバーについて画像付きで説明しており、的確だ。

*1 自社が配 布していたソフトウェアに脆弱性が見つかったときにも、このようにして広く 周知されるべきだろうが、脆弱性パッチのリリースをプレス発表するという事 例はほとんど存在しない。かつて、ソニーがVAIOのセキュリティホールを発表 したことがあった程度。

*2 それでもなお、そのチェックツールの動作を狂わせる仕掛けが、 トロイによって組み込まれていたら駄目だし、署名確認の操作が偽の処理に差 し替えられる仕掛けが組み込まれていたら駄目だ。トロイを実行してしまった ら、原理的にはもはやどうしようもない。TCGなどの成果を待つし かないか。

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

祝400エントリーなこのエントリーでは、 前々から幾度となく考えてきたブログについてです。 もう一度、Trackback。 つぐみ、どこにいるの? つぐみ、どこにいるの?@まい だいありーさん 感情が盲目にさせる@Ride the skyさん 『つぐみ、どこにいるの?』という記事に..

検索

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

最近のタイトル

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|
<前の日記(2005年03月11日) 次の日記(2005年03月16日)> 最新 編集