フィッシング詐欺で英銀行のインターネットバンキングが停止 69
ストーリー by Acanthopanax
DoS 部門より
DoS 部門より
von_yosukeyan曰く、"Impressの記事によると、急増するフィッシング詐欺の影響でイギリスの大手銀行Natwestのインターネットバンキングが一部停止に追い込まれた。現在、オンラインを経由しての振込など資金決済に制限がかかっているという。英セキュリティ企業mi2gの報告が伝えた。
Natwestは、Royal Bank of Scotland(RBS)グループ傘下の大手銀行で、HSBCグループに次いで欧州第二位の大手銀行。Natwestの顧客に対して、大量のフィッシング詐欺のメールが送りつけられ、顧客からの問い合わせや苦情が殺到していることから、Natwestはオンライン経由での資金移動サービスを停止し、顧客にコールセンター経由での資金移動を呼びかけているという。
一方でmi2gは、ID/パスワードを収集するキーロガー機能付きのトロイの木馬によるオンラインバンキング被害が今後増加すると予測している。また、対策として、メールに記載されたURLを通して銀行サイトにアクセスしたり、IDやパスワードを返信するように求めるメールに返信したりしないことを挙げている。"
邦銀のフィッシング詐欺対策 (スコア:4, 参考になる)
#以下、文中で大手銀行としている場合では、みずほ銀行(MHFG)、三井住友銀行(SMFG)、東京三菱銀行(MTFG)、UFJ銀行(UFJHD)、りそな銀行(りそなHD)、中央三井信託銀行(MTHD)の六グループ(括弧内はグループ名)傘下の主要銀行と、住友信託銀行を指すものとします。ネット銀行という場合には、ジャパンネット銀行、イーバンク銀行、ソニー銀行のネット専業三行に加え、暫定的に新生銀行を加えた四行を指すものとします
第一に、1)の部分ですが、現状では銀行が取引確認のために送付するメールの大半では、特定のURLに誘導するメールは減りつつあると思います。以前記載していた銀行も、直接記載はやめる傾向にあります
しかし、問題はメールを使って決済機能を提供しているネット銀行で、イーバンク銀行のメルマネ [ebank.co.jp]とジャパンネット銀行のJ振 [japannetbank.co.jp]の二つがあります。これらは、基本的には欧米で猛威を振るっているフィッシング詐欺の標的になっているPaypalと同じスキームを使った決済手段であるという点に注目すべきだと思います。特に、後発であるJ振の場合、単にメールでURLを表示してJNBの口座保有者を誘導できるだけでなく、振込先の口座番号の入力を省略できるサービスなので、リスクはメール以外でもWebサイトなど無制限に拡大する可能性があります
第二に、銀行のサイトであることを確認する手段を確保するという点ですが、高木先生が2001年の段階でご指摘されているように、a)URLを確認できるようにアドレスバーを隠さない。b)SSL通信が行えるか確認できるようステータスバーを隠さないの二点に関して、基本的な対策を行っていない銀行が多く存在するという問題です。特に大手銀行では東京三菱銀行が、ネット系銀行ではソニー銀行、ジャパンネット銀行、イーバンク銀行、新生銀行の全行が、ログインスクリーンをポップアップで表示して、アドレスバーとステータスバーを隠す仕様でした
こう言った問題点は、欧米でのフィッシング詐欺を背景に、2004年末にはログインスクリーンでは表示するように仕様を変更 [takagi-hiromitsu.jp]されています。しかし、現実には仕様が変更されているのはログインスクリーンのみで、その他の画面では仕様が変更されていない場合があります
例えば、イーコマースサイトや証券会社などが、銀行と提携して資金決済サービス(例えば東京三菱銀行の東京三菱ダイレクト [btm.co.jp]など)を提供していますが、コマースサイトや証券会社、銀行によっては商品や資金移動の確定画面から、決済を行うために銀行のサイトに移動するときに、ポップアップでログインスクリーンを表示し、なおかつアドレスバーを隠す場合があります。いくつかのサイトと銀行で確認したところ、同じ銀行の決済サービスでもコマースサイトや証券会社によっては銀行の正式なサイトか確認できない場合がありました。また、ある証券会社では、普通のオンライバンキングではポップアップのログインスクリーンではない三井住友銀行が、決済サービス用のログインスクリーンではポップアップで開き、アドレスバーを非表示にするケースすらありました。言うまでもなく、こういった仕様はサイトを確認する手段を奪い、フィッシング詐欺の手段であるなりすましを行う余地になります
そもそも、ポップアップウィンドウでログインスクリーンを開くのは、余り必要性がないケースが多いと思います。ユーザーが戻るボタンを押すことを回避など理由は様々なものがあると思いますが、ポップアップウィンドウが最も大量に開く最悪なケースであるソニー銀行の場合、ログインスクリーンからメニュー画面が表示されるまで最悪4回ポップアップウィンドウが表示され、ログアウトの確認表示にもポップアップを使用するなど、セキュリティ上のリスクを発生させるだけでなく、ユーザーに操作上の苦痛を強いるという点においては操作性を低下させる要因になっていると思います
第三に、3)の十分なパスワードを用意するというところですが、1)または2)の方法、トロイの木馬などでIDとパスワードが窃取された場合でも、現金の移動などを伴うサービスにおいて一定の安全性を確保でき
銀行→利用者ルートの認証 (スコア:3, 参考になる)
マルウェアでハックできるのはユーザー送信情報だけですからね。銀行側からの確認を別ルートから直接ユーザーに行うようにすれば、ほとんどのフィッシング被害は防げると思うんですけどね。(全部は無理かもしれませんが)
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
Re:銀行→利用者ルートの認証 (スコア:2, 参考になる)
証明書発行会社が、確かにその会社で有ることを確認して発行すると
ただし、認証された証明書だと、もし別の会社が取得した証明書だとしても警告なくアクセスできますからねぇ~
SSLの通信を開始しますメッセージではなく、XXXの会社にアクセスしますみたいな表示が必要なのかもしれません
アクセスしてからSSLの証明書を表示する操作をすれば取得会社を確認できますが、そこまでする人はフィッシング詐欺なんかにはかからないわけで...
Re:銀行→利用者ルートの認証 (スコア:1)
例えばですが、インスタントメッセンジャーで銀行から利用者にメッセージを送って、それに対する返事がなければ出金しないようにすれば、防げるのでは?と
成りすまして利用者にメッセージを送っても、銀行からのメッセージに返信されるわけではないですからね。
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
Re:銀行→利用者ルートの認証 (スコア:1)
むろん、別ルートで返信されればクラックされたときに、送金操作等をされたタイミングで判明すると言う事もありますが
その場合も送信元が必ず銀行であると言う証明が必要になります
つまりその手のメッセージも送信元を保証する法が無いと、今度はその銀行からのメッセージもなりすまされたら...と言う懸念が出てくるわけです。
正常に銀行に接続されている事を保証する方法と共に、正常に銀行に接続されているかをユーザーが確認する事を容易にする方のがこの手の詐欺の防止には役に立つと思います。
Re:銀行→利用者ルートの認証 (スコア:2, 興味深い)
成りすまして利用者に偽の銀行のメッセージを送っても、そのメッセージに対する返信は成りすました連中に返されるわけで、銀行に送られるわけではないですから、メッセージに対する返答を要求するようにすればいいわけですよ。
インスタントメッセンジャーをもうちょっとセキュアにすれば、リアルタイムで銀行からの問い合わせに利用者が返答できるシステムが作れるのではないかなぁ、と。
あとは、利用者にとって「証明書の内容を逐一確認するよりも、別APIを起動しておいて返信を送るほうが楽」と思えるだけのシステムを構築できるかどうかですね。
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
Re:銀行→利用者ルートの認証 (スコア:2, すばらしい洞察)
ユーザーが銀行だと思って入力してしまった場合、それらの情報が詐欺団体に流れてしまいませんか?
銀行に対して情報を提示したつもりが、成りすました相手にその手の情報が流れてしまうと..フィッシング詐欺ってそう言うものですし
Re:銀行→利用者ルートの認証 (スコア:1)
そりゃあ、情報が漏れないに越したことはないですが、どんなにがんばっても巧妙な成りすましにだまされてしまう人が出てくるわけで、だったら別方向からの防御手段も講じないと。
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
Re:銀行→利用者ルートの認証 (スコア:1)
すでに既存で、PKI/IC カード [google.com]による相互確認とかがありますよ
これだと、パスワードと異なり通信データーが漏れても大丈夫という安心があります
また事前に双方で所持している秘密キーが無いと通信できません
PKIカードとPKIにアクセスするためのパスワード等を併せて盗難したらアウトですが、フィッシング詐欺の結果として銀行のサイトにはアクセス出来ないでしょう。
通信経路を別にしても、前に記載した通り発信元の保証、発信先の保証という問題はついてまわります。
銀行とユーザーの間でやりとりされている事が保証されなければ、通信経路を別にしても意味がありません
その別経路が詐称出来ない保証された通信経路(専用線を使ったホットラインとか)なら別ですが、インターネット等を使用するのであれば、そのどちらかが成りすまされてしまう可能性を秘めているからです
無論コストがかかる話なので、なかなか導入はされてないのが現状ですが...
Re:銀行→利用者ルートの認証 (スコア:1)
今思いついたんですが、別経路の通信手段として、携帯電話とか使えませんかね?
出金直前に銀行から支払い内容の詳細を確認電話がかかってきて、「*」を押して承認しないと出金がキャンセルされる、とか。
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
Re:銀行→利用者ルートの認証 (スコア:1)
通信費が手数料に加算されそうですが(苦笑)
電話での承認となると発信者番号詐称 [mainichi-msn.co.jp]も考慮しないとなので、それ以上の使用は注意が必要ですが..
あれは個人的に衝撃でした..
Re:銀行→利用者ルートの認証 (スコア:1)
あれって、(だましてはいますが)本人合意の上で振り込んでるので、銀行側のシステムが何をしようと防ぐのは無理では?
あと、銀行側にメリットが出ないなら、なぜ「英銀行のインターネットバンキングが停止」なんて自体になってるんでしょう? デメリットを回避できるってのは、立派なメリットですよ。
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
Re:銀行→利用者ルートの認証 (スコア:1)
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
Re:銀行→利用者ルートの認証 (スコア:1)
たぶん見ないだろうけど...
えと、オレオレ詐欺は別にどうでもよくて、発信番号偽造の方に注目してください
電話を確認に使用すると言うことは、加入者は銀行からの電話である事を確認した上で承認すると言うことになります
フィッシング詐欺側で、発信番号を偽造できると言うことは、銀行からの確認電話自体を偽造可能と言うことです。
なので、この認証の場合、発信番号の詐称を考慮しなければないと言うことになるのです.
#いやーしっぱいした(苦笑
Re:銀行→利用者ルートの認証 (スコア:1)
銀行のサイトがXXXだとして、釣師のサイトがXXxだとする。
釣師はメールでXXxをXXXのサイトの様に見せて誤認させアクセスさせるが、誤認するような奴はXXxと表示されてもXXXのサイトだと思うだろうから、効果はそれ程期待出来ないと思う。
Re:銀行→利用者ルートの認証 (スコア:0)
画面をキャプチャして送信するやつはまだいないんですか?
Re:銀行→利用者ルートの認証 (スコア:1)
---にょろ~ん
フィッシング防止策として、 (スコア:1, 興味深い)
例えばキャッシュカード番号などは、銀行の社屋以外とか、
電話などでは確認しないことになっている筈なので、
「当行よりお客さま宛のメールには、トップページ以外のURLを記入する
ことはありません」とかいったルールを明確化して欲しい。
Re:フィッシング防止策として、 (スコア:1)
>ことはありません」とかいったルールを明確化して欲しい。
「当行ドメインが変更になりました。変更後のURLはxxxです。変更前のURLにアクセスされますと支障が出ますのでアクセスしないで下さい」とかいったメールでも釣られる奴は釣られる。
偽メールでの対策ならば、本文のサブジェクトにメールアドレスと秘の密鍵を元にSHA1とかのハッシュ関数を使ってキーワードを入れ、そのキーワードを元に仕分けして貰った方が識別し易くなる気がする。
まぁ、ISPのサーバー管理者が釣師だった場合バレバレになるけど....
なんだか (スコア:0)
パスワードは安全じゃないと思うし。/.jp も別の認証に変えてみるとかしてみないのかな。
Re:なんだか (スコア:2, 興味深い)
さすがカード丸ごとコピーは無理だから何回も使える手ではないけど、ログイン画面をリダイレクトしておいてログイン後の処理をダミーに振り替えつつ裏で上限額送金……ってのは可能だと思うから。
結局のところ、まずは使う側の意識から改善しなければならないんではないのかな。
--- どちらなりとご自由に --- --
Re:なんだか (スコア:2, 参考になる)
ICカードリーダなら、住基カード用のとかFelica用のものも売られていますがな。
http://www.sonyfinance-card.com/login/login.asp
ここのパソリ使ったログインの真似しても、アカウントはわからないと思うぞ。
アカウント知っててもここからは入れないと思うぞ。
Re:なんだか (スコア:2, 参考になる)
1.ログイン画面をフィッシング側サーバを経由して表示する
2.ユーザのログイン操作はトンネルして通常の認証を実施させる
3.ログインしたのを見計らってセッションを乗っ取る
4.ユーザにはダミー画面を操作させつつ、フィッシング側は自動で送金を実施
金額や履歴も読み込んで表示させておけば、ユーザは自分が操作しているのがダミー画面であることすら気づかないだろうね。
実際に実行できるかは別として、ICカードが通信路の暗号化にまで関与しない限りは、理論上こういった乗っ取りの方法を考えることができる。
想像可能な手段がある以上、その手法が絶対に安全とは言えないと思う。
--- どちらなりとご自由に --- --
Re:なんだか (スコア:3, 参考になる)
平文パスワード認証方式で議論を進めようとしてませんか? いまどきは、ICカードも通信路に暗号をかけるようです。 例えば、felica はこれ [sony.co.jp]や これ [felicanetworks.co.jp]なんかを読んでみてください。
共通鍵暗号なので、少々危険な気がしますが、それでも、Minap さんが心配なさるほど単純な方法ではクラックできません。
Re:なんだか (スコア:1)
そうかfelicaは通信路の暗号化もやってたのか……SONY、すっごく気合入ってたんだなー。
私が想定していたのは、認証だけカードの暗号データを使用して、処理そのものはブラウザの暗号化のみという方式です。その方式だったら、受けるときはサーバの振りして送るときはブラウザの振り……というのも可能かな、と思って。
まぁ、想定だけなので簡単に実現できるとは思っていませんけど。(w;
--- どちらなりとご自由に --- --
Re:なんだか (スコア:0)
その送信情報は暗号化されていて、しかも毎回暗号化の鍵を変えるので、
送信情報を再送信しても無効になるでしょ。
Re:なんだか (スコア:0)
>送信情報を再送信しても無効になるでしょ。
カードの情報とカードとの通信アルゴリズムが解析されたら終わりですよ。
特定の信号でアクセスすると、暗号化されたデータで行っていると思われる。
で、全てを解析してアルゴリズムがわかっ
Re:なんだか (スコア:1)
普通のセキュアなカードシステムはカードの情報を渡さないよう努力します。通信路をウォッチしても、まず解けない(だろう)暗号方式というのが世の中には存在します。
ただ、物理的に破壊するなどの手段が使えればカード内のすべての情報は手に入るかもしれません。とりあえず、カードを敵に渡さないのは大前提です。
Re:なんだか (スコア:1)
>とりあえず、カードを敵に渡さないのは大前提です。
そんなときはこいつ [zariganiworks.co.jp]を使え!
Re:なんだか (スコア:0)
時間掛かったらリアルタイムじゃないような....
仮に鍵が解析できるとしても、鍵の寿命が解析に掛かる時間より十分に
短ければ解析されても痛くもな
Re:なんだか (スコア:2, 興味深い)
日本なら架空請求の葉書に実在する会社の名前を書いているのと
同じことをネットでやっているって感じで
信用して行った騙されたってこととですよ。
日本も51番目の州として公用語が英語ならきっと騙されてますよ。
ICカードうんぬんって、
カードそのものスキミングよるコピー防止しか役に立ちません。
家庭でICカードと使ったハードを使うようになると解析する輩出るでしょうね。
得にPCを使った場合は、読み出しのアルゴリズムや通信の認証方法をログって解析するでしょう。
#今じゃパソコン寄せ集めてスパコン作れる時代ですから
#解析に時間が掛かるだけで解析されたら終わりのような。
#某ネット銀行で行っている毎回パスワードが変わる方式の方が手間が掛からずコスト低いですけど。
#15個くらい数字のパスワードで、何番目の数字は何ですか?と問われるタイプ
Re:なんだか (スコア:0)
>日本も51番目の州として公用語が英語ならきっと騙されてますよ。
マイナーな言語は最大のセキュリティですか。
薩摩藩にならって、日本語をどんどん外からは
わからないものに変質させていきましょう。
Re:なんだか (スコア:1)
>わからないものに変質させていきましょう。
⊇ωナょ、ζ,ぅレニτ〃£ヵゝ?
Re:なんだか (スコア:0)
PCで使うICカードの規格 (スコア:1)
結局のところ、セキュアな短距離無線通信規格ならなんでもいいと思うので、PAN の規格の動向に左右されるのかな?
あと、パッシブかアクティブかってのはやはりパッシブがいいんでしょうかね?もし携帯電話を認証に使う、っていうことを考えると、アクティブでもいい気がします。
屍体メモ [windy.cx]
Re:PCで使うICカードの規格 (スコア:3, 参考になる)
識者ではないので、疑問に思っているのですが、Felicaや住民基本台帳カードなどは本当に秘密鍵の入れ物として実用的且つ安全なのでしょうか。
署名計算などを内部で行わないICカードの場合、外部に鍵を出す必要があると思うので保管に問題があるように思えます。
また、内部で署名計算を行う場合にはコプロセッサ相当の専用チップが別途必要になるのでしょうし、Felicaのような非接触型ICカードでは電力が、そのほかの場合でも署名に掛かる時間とかの問題もでると思いますが。
そして、Felicaのように仕様もある程度公開されていて、世間にも普及している非接触型ICカードの場合は、狙ってスキミングの対象になり得るのでは無いのでしょうか。
(良く財布を落とす人にとってカード1枚に情報を入れるというのはかなり恐怖です。)
Re:PCで使うICカードの規格 (スコア:3, 興味深い)
いま実際に使われているかは知りませんが,性能上使うことは可能だったかと.
>内部で署名計算を行う場合にはコプロセッサ相当の専用チップが
>別途必要になるのでしょうし
最近の非接触型チップは,楕円曲線暗号など計算量の比較的少ない方式を
用いることで内部処理で公開鍵暗号を扱えるようになってます.
というか,コプロを積むよりはあまっているスペースに機能を実装するように
なってますし.で,電力と計算時間は計算量の少ない方式を採用することで回避.
Re:PCで使うICカードの規格 (スコア:3, 参考になる)
>専用チップが別途必要になるのでしょうし、Felicaのような
>非接触型ICカードでは電力が、そのほかの場合でも署名に
>掛かる時間とかの問題もでると思いますが。
電力はアンテナから電波を受け取るのでそれを使います。
演算には当然時間がかかりますが、FelicaはDES系を
使っているので汎用のCPUでなく専用の回路で高速に
処理が出来たはず。まぁ、時間が0.1秒とかそういう
ものなのでタッチアンドゴーでいけるんですけどね。
Re:なんだか (スコア:1)
東京三菱 [btm.co.jp]だとクライアント認証を実施しているようですね
これだと、アカウントやパスワードが漏洩してもクライアント側の所持している秘密キーが無ければログイン出来ないので少しは安心でしょう
まぁもっともクレジットカード情報が漏洩したら無駄でしょうが...
Re:なんだか (スコア:0)
それでも、このシステムに対応したトロイを作られたら
やはり危ない。「秘密鍵」がクライアントのパソコンに
格納されているわけだから、それを盗み出す仕組みを
トロイに実装すればいいだけ。
Re:なんだか (スコア:2, 参考になる)
Copyright (c) 2001-2014 Parsley, All rights reserved.
Royal Bank of Scotland (スコア:0)
それだけなのでAC
そんなあなたに (スコア:0)
Re:RBSが欧州2位?HSBCでなくて? (スコア:2, 参考になる)
Natwestは、ロンドンの超名門銀行でRBS本体と合わせるとイギリスの預金シェアの28%を占める英国本土では最大の金融機関です。HSBCの方がでかいことは確かですが、 自身が"The world's local bank"を標榜しているとおり、HSBCの最大拠点は香港を初めとする旧英系植民地やアングロサクソン系の移民が多い国です
またRBSは、傘下に損害保険会社Directlineなど複数の保険ブランドを保有し、保険会社としても英国第二位で、PB部門でも英国最大のCoutts Groupを、米国にはニューイングランドでは第二位の規模のリージョナルバンクのCitizensを保有しています。
そういうわけでRBSは時価評価でHSBCホールディングスに次いで第二位、総資産ベースでも第四位です。
雑学的知識 (スコア:2, 参考になる)
ほかにも
Edinburgh, Scotland (スコア:1)
> エジンバラ(人口10万人程度)のスコットランドの地方都市
エジンバラはスコットランドの「首都」で、人口は約45万人です。
フェスティバル時には人口が倍になるという噂もありますけど :-)
まぁ、RBS 自体は決してサービスが良いわけではなかったです。
Re:RBSが欧州2位?HSBCでなくて? (スコア:1)
Re:RBSが欧州2位?HSBCでなくて? (スコア:1)
それじゃ、EU > 欧州 になってしまいますが。
Re:つーか・・・・ (スコア:1)
フィッシングに利用されるってのは銀行にとって見ればイメージダウンだし、立派な被害だよね。
#いや、詭弁だということは自覚してますw
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
Re:つーか・・・・ (スコア:2, 興味深い)
そもそも、これは日本の話じゃないし、あへん法45条と、銃砲刀剣類取締法27条の3にも許容条文があるし、機会提供型のおとり捜査は、たとえ明文の許容規定が無くても、判例は合法と解することが多いような。
#と、私の教科書(田口守一先生)には書いてある
ことに、フィッシング詐欺に関しては、相手方がもう犯罪行為を始めてるんで、これに捜査官が乗っかるだけなら、捜査方法として許容されるでしょう。
# For man might be free./人は自由になれるかもしれないから。