コピーサイトは何が問題なのか対策すべきなのか、脆弱性なのか
コピーサイトはどんな問題を引き起こすのか
偽サイトの目的は、コピー元サイトの信用を悪用して個人情報を騙しとることやマルウェアをデリバリする(被害者にダウンロードさせる)ことが主な目的になります。
なので申込画面やログイン画面を作るツールや水飲み場攻撃用の偽サイトなど単体で手早く作られることが多かったのですが、
5月半ばに官公庁系のサイトを中心に1000サイト以上が作製されました。ここまでくると組織的犯行です。
最近は犯罪者のプラットフォームクラウドベースのサービスが拡充してきているので、CaaS(Crime-as-a-Service)としてフィッシングサイトのサービスオプションが追加されたのでしょうか。
付け焼き刃の蓋をして回る対策では、このような組織的な動きには対応できません。しっかりフェーズ毎に対応を明確化し組織が一律に防衛体制を取れるようにしなければなりません。
ここでは、予防、防御、検知、対応、復旧のフェーズ毎に考えていきたいと思います。
コピーサイトは組織の脆弱性になる
脆弱性なのかの問いに関してはソフトウェアの脆弱性ではないでしょうが、ブランドイメージや信用が攻撃の対象である以上、組織の脆弱性となるでしょう。
まずは自社サイトがスクレイピングされやすい存在なのかどうか調査しましょう。
✔︎ コピーサイトが作られた際の通知されるサービスの設定や通知窓口を用意している
✔︎ 類似ドメインを取得して管理している
✔︎ 直接コピーコンテンツが取得されないように要求元の確認を行う仕組みを取り入れている
予防
無料ドメイン
ソニー銀行や金沢大学、さらには首相官邸なども偽ドメインでサイトが作られています。
tkドメインで自ら取得して作らせないようにすることで予防策になります。ただし無料ドメインは、tkドメインではなく、無料ドメイン（.tk / .ml / .ga / .cf / .gq等）と存在するのでプロジェクトとして管理しつつ計画的に掃討作戦を行う必要があります。
HTTPSサイト
HTTPSのサイトにすることは、通信の安全性だけでなく、真正性 (authenticity)を担保し、客観的に本物であることを保証されるのでコピーサイトの予防につながります。
一口にHTTPSのサイトと言っても、緑のバー「保護された通信」と「組織名が表示」などと複数種類があるのはご存知かと思います。
最近ではLet’s EncryptやAWSなどで簡単にSSL発行してHTTPSサイトにできてしまうこともあり、ドメイン認証では信用できません。企業のメインサイトであれば最低、企業認証できればEV認証まで行たいところです。
| ドメイン認証 | 「ドメイン名の使用権」を認証する→CN（Common Name）で確認できる |
|---|---|
| 企業認証 | 「ドメイン名の使用権」「組織の法的実在性」を認証する→O（Organization）まで確認できる |
| EV認証 | 「ドメイン名の使用権」「組織の法的・物理的実在性」 「組織の運営」「承認者・署名者の確認」を認証する→バーに組織名が表示されている |
自組織内にはセキュリティ教育を
実践的なフローや考え方(How to)にフォーカスした実践的な教育を行います。日本では特に意識や喚起にフォーカスした教育が過剰です。定期的に定量的に効果測定し管理していなければ、結果を良い方向にマネジメントすることは不可能でしょう。例えば怪しいサイトは開かないでは、まず怪しいと判断するための判断フローと観点を業務フローに組み込み訓練する必要があります。いつもと違う気がしても業務で必要だからと引っかかる水飲み場攻撃は「怪しいサイトを開かない」では防ぐことはできません。
一般ユーザは、中にはリテラシーが非常に高い方もいますがよっぽどの外れ値でない限りリテラシーのボトム集合(低い集合)に合わせます。
防御
要求元を確認し任意の場所から要求できなくする
これには保護する対象により、３つ観点があります。
・リソースの要求オリジンを制限する→画像などのリソース
・遷移時に正当な遷移元であるかを確認する→ページそのものや直書きされているコンテンツ
・User-Agentを確認しブラウザ以外からの要求を落とす→開発ツールも落とされる可能性があるので注意して管理する
プラットフォームに合わせ設定することで、コピーサイトに対してかなり防御できるようになります。
機械的実行を妨害する。reCAPTACHを導入するなど
申込画面などの遷移にreCAPTACHをいれるとスクレイピンの難易度が上がります。
将来的にCAPTCHAソルバーなどが進化を遂げればスクレイピングで突破される可能性はあります。
インターネット上に公開しエンディックスさせないサイトであるならば、robots.txtに記載してクローラーの妨害をするなどの策も有効と考えられます。
HTMLの書き方を工夫する
・パスを絶対パス(ドメイン込みのフルパス)で記載し、相対パスで書かないこと
・独自リソースにintegrity属性(HTML5)を設定する(リソースごと引っ越しができなくなる)(注意：IEでは未対応・・)
ドメインが侵害されないように管理する
ドメインを挿げ替えられたら、提供サーバ側でいくら頑張ってもフィッシングサイトへ誘導されてしまいます。
コインチェックが不正アクセスを受け、ドメインの登録情報が第三者によって意図しない内容に変更された事件がありました。
過去にもラブライブ！公式サイトのドメイン乗っ取り事件が有名となっていますが、ドメイン管理の脆弱性を突きドメイン名のハイジャック（乗っ取り）が行われることを注意しなければなりません。
対策として管理画面での行動を承認制にするなど制限するドメインプロテクションを導入することを推奨します。
検知
サーチコンソールなどの警告設定で通告をもらえるようにしましょう。また、社内や社内からの報告も識別できるように報告の仕組みを制定し、周知できているか定期的に確認しましょう。
対応
コピーサイト、フィッシングサイトの存在を通告
Cloudflareに悪用を報告する場合は
①問題とされているドメイン、および
②フィッシングページへのリンク。
DMCAの問題、フィッシング、商標権侵害、マルウェアサイト、児童搾取記録物
ユーザへの注意喚起
確認されたサイトを見分ける特徴や被害があった場合の問合せ先を明確にします。
復旧
ユーザへの報告
公表していた場合、対応経緯改善確認結果を公表します。社外だけ社内だけでなく双方に行います。
原因となった要求元をブロックする
IPや地域でブロックすると、利用者の正当な利用まで侵害する可能性があるので、サービスの範囲を確認しつつ、１つの要求元からの単位時間あたりの要求(リクエスト)数と組み合わせで制限するなどしWAFなどに組み込む経過を見ながらブロックを施しましょう。
いかがでしょうか。咄嗟にはフェーズごとの対策や一律したフローの実行は困難です。この機会に組織のコピーサイト対策を見直して見ましょう。
以上です。参考になりましたら幸いです。