パスワードを忘れた? アカウント作成
9509 story

フィッシング詐欺で英銀行のインターネットバンキングが停止 69

ストーリー by Acanthopanax
DoS 部門より

von_yosukeyan曰く、"Impressの記事によると、急増するフィッシング詐欺の影響でイギリスの大手銀行Natwestのインターネットバンキングが一部停止に追い込まれた。現在、オンラインを経由しての振込など資金決済に制限がかかっているという。英セキュリティ企業mi2gの報告が伝えた。
Natwestは、Royal Bank of Scotland(RBS)グループ傘下の大手銀行で、HSBCグループに次いで欧州第二位の大手銀行。Natwestの顧客に対して、大量のフィッシング詐欺のメールが送りつけられ、顧客からの問い合わせや苦情が殺到していることから、Natwestはオンライン経由での資金移動サービスを停止し、顧客にコールセンター経由での資金移動を呼びかけているという。
一方でmi2gは、ID/パスワードを収集するキーロガー機能付きのトロイの木馬によるオンラインバンキング被害が今後増加すると予測している。また、対策として、メールに記載されたURLを通して銀行サイトにアクセスしたり、IDやパスワードを返信するように求めるメールに返信したりしないことを挙げている。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 邦銀のフィッシング詐欺対策に関しては、古典的ですが高木浩光先生の指摘 [aist.go.jp]などがありますが、現状としても不十分であるケースが多々見られます。銀行の基本的な対策としての、1)メールにURLを記載してサイトに誘導しない。2)銀行のサイトであることを確認できる手段を用意する。3)十分なパスワードを用意する。という三つの観点から見てみます

    #以下、文中で大手銀行としている場合では、みずほ銀行(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とパスワードが窃取された場合でも、現金の移動などを伴うサービスにおいて一定の安全性を確保でき
  • by akiraani (24305) on 2005年01月18日 11時10分 (#680587) 日記
    現状の利用者がオンラインバンキングサイトにアクセスするという形ですべての認証を行おうとしてますが、今後必要になってくるのは銀行→利用者へのリアルタイムかつセキュアな認証手段なのではないでしょうか。
    マルウェアでハックできるのはユーザー送信情報だけですからね。銀行側からの確認を別ルートから直接ユーザーに行うようにすれば、ほとんどのフィッシング被害は防げると思うんですけどね。(全部は無理かもしれませんが)
    --
    しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
    • by mocchino (13752) on 2005年01月18日 11時41分 (#680597)
      いやそのためのSSL電子証明書なんですけどね
      証明書発行会社が、確かにその会社で有ることを確認して発行すると

      ただし、認証された証明書だと、もし別の会社が取得した証明書だとしても警告なくアクセスできますからねぇ~
      SSLの通信を開始しますメッセージではなく、XXXの会社にアクセスしますみたいな表示が必要なのかもしれません

      アクセスしてからSSLの証明書を表示する操作をすれば取得会社を確認できますが、そこまでする人はフィッシング詐欺なんかにはかからないわけで...
      親コメント
      • うーん、それだと利用者→銀行の接続の延長なのではないかなぁ。
        例えばですが、インスタントメッセンジャーで銀行から利用者にメッセージを送って、それに対する返事がなければ出金しないようにすれば、防げるのでは?と
        成りすまして利用者にメッセージを送っても、銀行からのメッセージに返信されるわけではないですからね。
        --
        しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
        親コメント
        • 接続先が信頼出来る物(つまり銀行で有ること)が確認できれば、フィッシング詐欺は防げるわけで、この目的ではそれ以上は必要ないでしょう

          むろん、別ルートで返信されればクラックされたときに、送金操作等をされたタイミングで判明すると言う事もありますが
          その場合も送信元が必ず銀行であると言う証明が必要になります
          つまりその手のメッセージも送信元を保証する法が無いと、今度はその銀行からのメッセージもなりすまされたら...と言う懸念が出てくるわけです。

          正常に銀行に接続されている事を保証する方法と共に、正常に銀行に接続されているかをユーザーが確認する事を容易にする方のがこの手の詐欺の防止には役に立つと思います。
          親コメント
          • by akiraani (24305) on 2005年01月18日 12時52分 (#680643) 日記
            >銀行からのメッセージもなりすまされたら...と言う懸念が出てくるわけです。
            成りすまして利用者に偽の銀行のメッセージを送っても、そのメッセージに対する返信は成りすました連中に返されるわけで、銀行に送られるわけではないですから、メッセージに対する返答を要求するようにすればいいわけですよ。
            インスタントメッセンジャーをもうちょっとセキュアにすれば、リアルタイムで銀行からの問い合わせに利用者が返答できるシステムが作れるのではないかなぁ、と。

            あとは、利用者にとって「証明書の内容を逐一確認するよりも、別APIを起動しておいて返信を送るほうが楽」と思えるだけのシステムを構築できるかどうかですね。

            --
            しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
            親コメント
            • by mocchino (13752) on 2005年01月18日 13時07分 (#680654)
              それだと、その詐称された画面でクレジットカード情報、ログイン情報等を入力するように促し
              ユーザーが銀行だと思って入力してしまった場合、それらの情報が詐欺団体に流れてしまいませんか?
              銀行に対して情報を提示したつもりが、成りすました相手にその手の情報が流れてしまうと..フィッシング詐欺ってそう言うものですし
              親コメント
              • あー、クレジットカード情報が流出するのは防げないです。防げるのは「流出したクレジットカード情報を悪用される」ことです。クレジットカード情報が漏れるとたいへんなのは、その情報だけでお金が引き出せちゃうから問題なのであって、出金時に別ルートで銀行側から本人に確認を取るようにすれば、最悪のケースでも致命的な被害は防げると思いません?

                そりゃあ、情報が漏れないに越したことはないですが、どんなにがんばっても巧妙な成りすましにだまされてしまう人が出てくるわけで、だったら別方向からの防御手段も講じないと。

                --
                しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
                親コメント
              • なるほど、でもそれだと、通信経路を複数に分けるわかりに
                すでに既存で、PKI/IC カード [google.com]による相互確認とかがありますよ
                これだと、パスワードと異なり通信データーが漏れても大丈夫という安心があります
                また事前に双方で所持している秘密キーが無いと通信できません

                PKIカードとPKIにアクセスするためのパスワード等を併せて盗難したらアウトですが、フィッシング詐欺の結果として銀行のサイトにはアクセス出来ないでしょう。
                通信経路を別にしても、前に記載した通り発信元の保証、発信先の保証という問題はついてまわります。
                銀行とユーザーの間でやりとりされている事が保証されなければ、通信経路を別にしても意味がありません
                その別経路が詐称出来ない保証された通信経路(専用線を使ったホットラインとか)なら別ですが、インターネット等を使用するのであれば、そのどちらかが成りすまされてしまう可能性を秘めているからです

                無論コストがかかる話なので、なかなか導入はされてないのが現状ですが...
                親コメント
              • なるほど、公開鍵暗号方式+ICカードかぁ。でも、確かにこれだとコストはかかりそうだし、読み取り機の設置とか利用者の負担も大きそうだ(^^;

                今思いついたんですが、別経路の通信手段として、携帯電話とか使えませんかね?
                出金直前に銀行から支払い内容の詳細を確認電話がかかってきて、「*」を押して承認しないと出金がキャンセルされる、とか。

                --
                しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
                親コメント
              • 銀行に対しての操作結果の承認なら、実用上問題はないかもですね
                通信費が手数料に加算されそうですが(苦笑)

                電話での承認となると発信者番号詐称 [mainichi-msn.co.jp]も考慮しないとなので、それ以上の使用は注意が必要ですが..
                あれは個人的に衝撃でした..
                親コメント
              • フィッシングを防ぐ話で、なぜにオレオレ詐欺の話が?
                あれって、(だましてはいますが)本人合意の上で振り込んでるので、銀行側のシステムが何をしようと防ぐのは無理では?

                あと、銀行側にメリットが出ないなら、なぜ「英銀行のインターネットバンキングが停止」なんて自体になってるんでしょう? デメリットを回避できるってのは、立派なメリットですよ。

                --
                しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
                親コメント
              • オンラインバンキングシステムについて話してるつもりだったんですが……。
                --
                しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
                親コメント
              • うお、返信あるの気づいてなかった(苦笑
                たぶん見ないだろうけど...

                えと、オレオレ詐欺は別にどうでもよくて、発信番号偽造の方に注目してください
                電話を確認に使用すると言うことは、加入者は銀行からの電話である事を確認した上で承認すると言うことになります
                フィッシング詐欺側で、発信番号を偽造できると言うことは、銀行からの確認電話自体を偽造可能と言うことです。
                なので、この認証の場合、発信番号の詐称を考慮しなければないと言うことになるのです.

                #いやーしっぱいした(苦笑
                親コメント
      • >SSLの通信を開始しますメッセージではなく、XXXの会社にアクセスしますみたいな表示が必要なのかもしれません

        銀行のサイトがXXXだとして、釣師のサイトがXXxだとする。
        釣師はメールでXXxをXXXのサイトの様に見せて誤認させアクセスさせるが、誤認するような奴はXXxと表示されてもXXXのサイトだと思うだろうから、効果はそれ程期待出来ないと思う。
        親コメント
    • >マルウェアでハックできるのはユーザー送信情報だけですからね。

      画面をキャプチャして送信するやつはまだいないんですか?

  • by Anonymous Coward on 2005年01月18日 23時33分 (#680897)
    運用上の工夫も期待したい。
    例えばキャッシュカード番号などは、銀行の社屋以外とか、
    電話などでは確認しないことになっている筈なので、

    「当行よりお客さま宛のメールには、トップページ以外のURLを記入する
    ことはありません」とかいったルールを明確化して欲しい。
    • >「当行よりお客さま宛のメールには、トップページ以外のURLを記入する
      >ことはありません」とかいったルールを明確化して欲しい。

      「当行ドメインが変更になりました。変更後のURLはxxxです。変更前のURLにアクセスされますと支障が出ますのでアクセスしないで下さい」とかいったメールでも釣られる奴は釣られる。

      偽メールでの対策ならば、本文のサブジェクトにメールアドレスと秘の密鍵を元にSHA1とかのハッシュ関数を使ってキーワードを入れ、そのキーワードを元に仕分けして貰った方が識別し易くなる気がする。
      まぁ、ISPのサーバー管理者が釣師だった場合バレバレになるけど....
      親コメント
  • by Anonymous Coward on 2005年01月18日 8時46分 (#680549)
    さっさとICカード化して、PCからもカード使った認証ができるようにしてほしい。
    パスワードは安全じゃないと思うし。/.jp も別の認証に変えてみるとかしてみないのかな。
    • Re:なんだか (スコア:2, 興味深い)

      by Minap (9371) on 2005年01月18日 9時03分 (#680554) ホームページ 日記
       そのICカードの送信情報を丸ごと盗まれたら意味ないと思うけど?
       さすがカード丸ごとコピーは無理だから何回も使える手ではないけど、ログイン画面をリダイレクトしておいてログイン後の処理をダミーに振り替えつつ裏で上限額送金……ってのは可能だと思うから。

       結局のところ、まずは使う側の意識から改善しなければならないんではないのかな。
      --
      --- どちらなりとご自由に --- --
      親コメント
      • Re:なんだか (スコア:2, 参考になる)

        by Anonymous Coward on 2005年01月18日 10時17分 (#680573)
        盗めるんなら盗んでみれば・・・?
        ICカードリーダなら、住基カード用のとかFelica用のものも売られていますがな。

        http://www.sonyfinance-card.com/login/login.asp

        ここのパソリ使ったログインの真似しても、アカウントはわからないと思うぞ。
        アカウント知っててもここからは入れないと思うぞ。
        親コメント
        • Re:なんだか (スコア:2, 参考になる)

          by Minap (9371) on 2005年01月18日 10時42分 (#680580) ホームページ 日記
           すまぬ。わかりにくいので噛み砕いて書く。

          1.ログイン画面をフィッシング側サーバを経由して表示する
          2.ユーザのログイン操作はトンネルして通常の認証を実施させる
          3.ログインしたのを見計らってセッションを乗っ取る
          4.ユーザにはダミー画面を操作させつつ、フィッシング側は自動で送金を実施

           金額や履歴も読み込んで表示させておけば、ユーザは自分が操作しているのがダミー画面であることすら気づかないだろうね。
           実際に実行できるかは別として、ICカードが通信路の暗号化にまで関与しない限りは、理論上こういった乗っ取りの方法を考えることができる。

           想像可能な手段がある以上、その手法が絶対に安全とは言えないと思う。
          --
          --- どちらなりとご自由に --- --
          親コメント
          • Re:なんだか (スコア:3, 参考になる)

            by ytateyama (9050) on 2005年01月18日 11時48分 (#680604)

            平文パスワード認証方式で議論を進めようとしてませんか? いまどきは、ICカードも通信路に暗号をかけるようです。 例えば、felica はこれ [sony.co.jp]や これ [felicanetworks.co.jp]なんかを読んでみてください。

            共通鍵暗号なので、少々危険な気がしますが、それでも、Minap さんが心配なさるほど単純な方法ではクラックできません。

            親コメント
            • by Minap (9371) on 2005年01月18日 12時10分 (#680618) ホームページ 日記
               ytateyamaさん、ありがとうございます。参考になりました。

               そうかfelicaは通信路の暗号化もやってたのか……SONY、すっごく気合入ってたんだなー。
               私が想定していたのは、認証だけカードの暗号データを使用して、処理そのものはブラウザの暗号化のみという方式です。その方式だったら、受けるときはサーバの振りして送るときはブラウザの振り……というのも可能かな、と思って。

               まぁ、想定だけなので簡単に実現できるとは思っていませんけど。(w;
              --
              --- どちらなりとご自由に --- --
              親コメント
      • by Anonymous Coward
        > そのICカードの送信情報を丸ごと盗まれたら意味ないと思うけど?

        その送信情報は暗号化されていて、しかも毎回暗号化の鍵を変えるので、
        送信情報を再送信しても無効になるでしょ。
        • by Anonymous Coward
          >その送信情報は暗号化されていて、しかも毎回暗号化の鍵を変えるので、
          >送信情報を再送信しても無効になるでしょ。

          カードの情報とカードとの通信アルゴリズムが解析されたら終わりですよ。

          特定の信号でアクセスすると、暗号化されたデータで行っていると思われる。

          で、全てを解析してアルゴリズムがわかっ
          • by ytateyama (9050) on 2005年01月18日 11時56分 (#680609)

            普通のセキュアなカードシステムはカードの情報を渡さないよう努力します。通信路をウォッチしても、まず解けない(だろう)暗号方式というのが世の中には存在します。

            ただ、物理的に破壊するなどの手段が使えればカード内のすべての情報は手に入るかもしれません。とりあえず、カードを敵に渡さないのは大前提です。

            親コメント
            • by primavera (9253) on 2005年01月18日 12時27分 (#680628)
              >ただ、物理的に破壊するなどの手段が使えればカード内のすべての情報は手に入るかもしれません。
              >とりあえず、カードを敵に渡さないのは大前提です。

              そんなときはこいつ [zariganiworks.co.jp]を使え!
              親コメント
          • by Anonymous Coward
            > リアルタイムに解析するのに時間が掛かるだけで、

            時間掛かったらリアルタイムじゃないような....

            仮に鍵が解析できるとしても、鍵の寿命が解析に掛かる時間より十分に
            短ければ解析されても痛くもな
    • Re:なんだか (スコア:2, 興味深い)

      by Anonymous Coward on 2005年01月18日 9時35分 (#680559)
      ICカードとかの問題じゃないと思うんだけど
      日本なら架空請求の葉書に実在する会社の名前を書いているのと
      同じことをネットでやっているって感じで

      信用して行った騙されたってこととですよ。
      日本も51番目の州として公用語が英語ならきっと騙されてますよ。

      ICカードうんぬんって、
      カードそのものスキミングよるコピー防止しか役に立ちません。

      家庭でICカードと使ったハードを使うようになると解析する輩出るでしょうね。
      得にPCを使った場合は、読み出しのアルゴリズムや通信の認証方法をログって解析するでしょう。
      #今じゃパソコン寄せ集めてスパコン作れる時代ですから
      #解析に時間が掛かるだけで解析されたら終わりのような。
      #某ネット銀行で行っている毎回パスワードが変わる方式の方が手間が掛からずコスト低いですけど。
      #15個くらい数字のパスワードで、何番目の数字は何ですか?と問われるタイプ
      親コメント
      • by Anonymous Coward
        >信用して行った騙されたってこととですよ。
        >日本も51番目の州として公用語が英語ならきっと騙されてますよ。
        マイナーな言語は最大のセキュリティですか。
        薩摩藩にならって、日本語をどんどん外からは
        わからないものに変質させていきましょう。
    • って、何になるんでしょうね。やはり Felica ?

      結局のところ、セキュアな短距離無線通信規格ならなんでもいいと思うので、PAN の規格の動向に左右されるのかな?

      あと、パッシブかアクティブかってのはやはりパッシブがいいんでしょうかね?もし携帯電話を認証に使う、っていうことを考えると、アクティブでもいい気がします。
      --
      屍体メモ [windy.cx]
      親コメント
      • by whelp (25685) on 2005年01月18日 12時36分 (#680638)
        フィッシング詐欺とはあまり関係ないのですが・・・。

        識者ではないので、疑問に思っているのですが、Felicaや住民基本台帳カードなどは本当に秘密鍵の入れ物として実用的且つ安全なのでしょうか。
        署名計算などを内部で行わないICカードの場合、外部に鍵を出す必要があると思うので保管に問題があるように思えます。
        また、内部で署名計算を行う場合にはコプロセッサ相当の専用チップが別途必要になるのでしょうし、Felicaのような非接触型ICカードでは電力が、そのほかの場合でも署名に掛かる時間とかの問題もでると思いますが。

        そして、Felicaのように仕様もある程度公開されていて、世間にも普及している非接触型ICカードの場合は、狙ってスキミングの対象になり得るのでは無いのでしょうか。

        (良く財布を落とす人にとってカード1枚に情報を入れるというのはかなり恐怖です。)
        親コメント
        • Felicaって後から公開鍵暗号方式にも対応しませんでしたっけ?
          いま実際に使われているかは知りませんが,性能上使うことは可能だったかと.

          >内部で署名計算を行う場合にはコプロセッサ相当の専用チップが
          >別途必要になるのでしょうし

          最近の非接触型チップは,楕円曲線暗号など計算量の比較的少ない方式を
          用いることで内部処理で公開鍵暗号を扱えるようになってます.
          というか,コプロを積むよりはあまっているスペースに機能を実装するように
          なってますし.で,電力と計算時間は計算量の少ない方式を採用することで回避.
          親コメント
        • by Anonymous Coward on 2005年01月18日 13時02分 (#680650)
          >また、内部で署名計算を行う場合にはコプロセッサ相当の
          >専用チップが別途必要になるのでしょうし、Felicaのような
          >非接触型ICカードでは電力が、そのほかの場合でも署名に
          >掛かる時間とかの問題もでると思いますが。

          電力はアンテナから電波を受け取るのでそれを使います。
          演算には当然時間がかかりますが、FelicaはDES系を
          使っているので汎用のCPUでなく専用の回路で高速に
          処理が出来たはず。まぁ、時間が0.1秒とかそういう
          ものなのでタッチアンドゴーでいけるんですけどね。
          親コメント
    • by mocchino (13752) on 2005年01月18日 13時20分 (#680662)
      ICカード(PKIカード)を使っていないので、パスワードも併用しているようですが
      東京三菱 [btm.co.jp]だとクライアント認証を実施しているようですね

      これだと、アカウントやパスワードが漏洩してもクライアント側の所持している秘密キーが無ければログイン出来ないので少しは安心でしょう

      まぁもっともクレジットカード情報が漏洩したら無駄でしょうが...
      親コメント
      • by Anonymous Coward
        一般的なキーロガー対策にはなるので、かなり安心ですね。
        それでも、このシステムに対応したトロイを作られたら
        やはり危ない。「秘密鍵」がクライアントのパソコンに
        格納されているわけだから、それを盗み出す仕組みを
        トロイに実装すればいいだけ。
  • by Anonymous Coward on 2005年01月18日 11時11分 (#680589)
    s/RBC/RBS/

    それだけなのでAC
  • by Anonymous Coward on 2005年01月18日 13時13分 (#680657)
    小説地下銀行 [bk1.co.jp]
typodupeerror

人生の大半の問題はスルー力で解決する -- スルー力研究専門家

読み込み中...