釣りかよ !!(フィッシング詐欺あれこれ)

Pocket


(Yanik Chauvin / Shutterstock.com)

こんにちは、中山です(写真は私ではありません)。
これは TECHSCORE Advent Calendar 2017 の 10 日目の記事です。

以前、あわよくばと Google の脆弱性報償金プログラムに応募したことがあります。
こちらが当時 Google に報告した内容です。

Google ad serviece has a security issue.
(open-redirection)

Steps to reproduce the vulnerability:
1. http://pagead2.googlesyndication.com/pagead/imgad?id=CICAgIDQp961eBDYBRhaMggPIKH46gXDKg&clickTAG=https://evil.com/
2. click ad
3. move to https://evil.com/

確認したところ 2017/11/26 時点でも上記手順は再現可能(Flash を有効にしている場合)でした。

Google の保持するドメインと Google の自社稿の信頼性に便乗し、悪意あるページに誘導(いわゆる Phishing)可能である、という指摘です。
これに対する回答は以下の通りでした。

Thanks for your email.
In this particular case, we believe the usability and security benefits of a well-implemented and carefully monitored URL redirector tend to outweigh the perceived risks.
For a more detailed explanation, check the URL redirection section here: http://www.google.com/about/appsecurity/reward-program/#notavuln

というわけで、残念ながら報酬金はゲットできませんでした(笑)。
私の指摘は、ありがちな低リスク問題とのことです。

遷移先を作り込んだ Google の偽ページにすることで、騙されるケースがあるのではと考えましたが、広告プロダクトに使われる pagead2.googlesyndication.com ドメインでは確かに低リスクですね。
そんなわけで、今回は Phishing に関する考察を述べたいと思います。

Phishing x pushState

以下のようなページ遷移の場合、多くの人は信頼できるページに戻ることを期待しています。

  1. 信頼できるページA(trust.com)を閲覧
  2. リンクからページB(decoy.com)に遷移
  3. ヒストリバック
  4. ( ... ページAのはず !?)

ですが、実際には以下のような遷移となっている可能性があります。

  1. 信頼できるページA(trust.com)を閲覧
  2. リンクからページB(decoy.com)に遷移
    1. この時Bはダミーの URL を history.pushState
    2. アドレスバーにはダミーの URL を表示される
  3. ヒストリバック
    1. 元々のBの URL に戻る
    2. この時Bは onpopstate イベントを実行
    3. ページAを巧妙に模したページC(evil.com)に強制的に遷移
  4. ユーザーは期せずしてページC(evil.com)を閲覧
    (URL を確認しないとページAだと信じてしまうかもしれない !!)

ちなみにページBはこんな感じです。

ページAに UGC(ユーザー生成コンテンツ)として外部リンクを書き込むことが出来たり、ページAに掲載された広告からページBに誘導することが出来た場合、このような遷移も可能になります。

この(ページAを巧妙に模した)ページCのタイミングで「セッション切れでログアウトしました。再度ログインしてください」とログイン情報の再入力を促した場合、促されるままに入力してしまう人もいるかもしれません。

Phishing x iframe

全てを偽造したページと比較して、本物のページ(の一部)が書き換えられたケースでは、偽造に気付けないリスクが高まります。
例えばページA(trust.com)が以下の条件

  • Aは iframe 内に表示されることを拒否(X-Frame-Options: DENY)していない
  • Aはコンテンツ内に name 属性の定義された iframe 要素(f)を持つ

を満たす場合fのコンテンツを差し替えることが可能です。
具体的には以下のようなコンテンツを用いることで

見た目はページA(trust.com)のまま、一部(f)を evil.com のコンテンツに差し替えることができます。
さらにログイン機能を有するサービスの場合、ページA(ログイン中)はアカウント情報などが表示されるため、自分が騙されていることに気付けなくなるリスクも高まります。

実際に、上記条件を満たすサービスを見つけることは難しくありません。
とある実在するページ(モザイクフィルタを適用してます)で

下方の iframe で表示されているプレスリリース部分を差し替えることができました。

このサービスにはログイン機能もあるため、ログインセッションを維持したまま罠ページに誘導された場合、多くのユーザーが騙されてしまう危険性があります。

蛇足ですが、ブラウザのウインドウ操作(上述 window.open など)に関する仕様は HTML5 の 5.1 Browsing contexts や 5.1.4 Security を参考にしてください。

Phishing x SSL/EVSSL


(https://news.netcraft.com/archives/2017/05/17/phishing-sites-react-promptly-to-new-browser-changes.html)

2017/05/19 に NETCRAFT で公開された資料 から HTTPS を用いた Phishing サイトの割合が増加傾向にあることが分かります。
これを受け、身元保証を強化した EVSSL を採用するサービスも増えてくるでしょう。

一方で HTTPS 共用サービス(弊社の Synergy! FORM 機能も該当します)においては EVSSL の採用によってリスクを高めてしまう懸念があります。
悪意ある事業者が HTTPS(EVSSL)共用サービスを利用し、緑色のアドレスバーでエンドユーザーのミスリードを狙う可能性があるからです。

複数サービス(事業者)のドメインを横断した信頼関係を明示するプロトコルなり UI なりを作れるといいのですが(→ これについては別途考察してみたいと思います)。

まとめ

  • 特別な理由がなければ X-Frame-Options は使いましょう
  • ページA(trust.com)であるはず、という思い込みは捨てましょう
  • 鍵マークでも(サービスによっては緑色のアドレスバーでも)リスクがあることを理解しましょう
  • 兎にも角にも、まずは URL を確認しましょう !!
Pocket

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です