サブドメインテイクオーバー概要

概要

• 組織や個人が所有するドメインのサブドメインが、正しいリソースに紐づけられていない（または解放されている）状態を第三者が悪用し、そのサブドメインを制御下に置いてしまう攻撃手法。
• クラウドサービスをはじめ、外部サービスへのCNAMEレコードを設定しているケースでよく発生し、誤ってサブドメインのレコードが残ったままサービスを停止・削除すると、そのリソースを他人に取得され、意図しないコンテンツが配信される可能性がある。

概念・用語

• サブドメイン
  メインドメイン（例: example.com）に属するドメインで、sub.example.com のように表されるもの。
• DNSレコード
  ドメイン名に対してIPアドレスやCNAMEなどの情報を設定する仕組み。
  例: Aレコード, CNAMEレコード, MXレコード など。
• CNAMEレコード
  あるドメイン名を別のドメイン名にエイリアスとして紐づけるDNSレコード。
  例: sub.example.com CNAME some.cloudservice.com
• クラウドサービス（外部ホスティング）
  GitHub Pages、Heroku、AWS S3など、ユーザがカスタムドメインを割り当ててホストできる外部のサービス。

発生により生じるリスク

1. ブランド・信用毀損
   攻撃者が企業ドメインのサブドメインを取得し、不正なサイトやフィッシングサイトを公開することで企業のブランドや信用を傷つける可能性がある。

2. マルウェア配布・フィッシング
   正当なドメインのサブドメインを利用して、マルウェアやフィッシング詐欺を行われる可能性がある。

3. 内部システムやAPIの悪用
   サブドメインが内部向けシステムやAPIと紐づいている場合、不用意な情報漏えいや認証情報の不正利用につながるリスクがある。

4. SEO被害
   検索エンジンの検索結果において、攻撃者が作成したページが上位に表示されることで、正当なコンテンツが影響を受ける場合がある。

ケース

1. AWS Route53 + S3
   • ユーザが sub.example.com をS3バケットに割り当ててサイトをホスティングしていた。
   • 何らかの理由でS3バケットを削除したが、Route53のCNAMEレコードは削除し忘れた。
   • 攻撃者が同じ名前（sub.example.com）のS3バケットを作成可能な場合、テイクオーバーが成立し、sub.example.com へ任意のコンテンツを配置できてしまう。
2. AWS Route53 + CloudFront
   • sub.example.com をCloudFrontディストリビューションに割り当て。
   • CloudFront側のディストリビューションを削除またはドメイン設定を解放。
   • Route53のCNAMEレコードがそのまま残っていると、他のユーザが同じカスタムドメインをCloudFrontで設定できてしまう場合がある。
3. GitHub Pages
   • sub.example.com をGitHub Pagesのリポジトリに紐づけ。
   • リポジトリを削除したがCNAMEレコードは残存。
   • 攻撃者が同じリポジトリ名を取得し、CNAMEに sub.example.com を設定して奪取。

発生メカニズム

1. サブドメインのDNSレコードが外部サービスを指している
   AレコードまたはCNAMEレコードで、外部サービスのエンドポイントを指定している状態。
2. 外部サービスでリソースまたはオブジェクトを削除
   バケット、ウェブホスティング設定、ディストリビューションなどを削除してしまうが、DNS設定（CNAMEレコードなど）を削除せずに放置。
3. 攻撃者が同じリソース名を作成または取得
   バケット名やホスティング設定、またはディストリビューションで同一のカスタムドメインを再度設定。
4. DNSのレコードが指すリソースが攻撃者の手に渡り、サブドメインが奪取される
   その結果、サブドメイン宛のトラフィックは攻撃者の管理下にあるサービスへ誘導される。

確認方法

1. subjack
   • サブドメインテイクオーバーを検知するためのツール。
   • subjack -w subdomains.txt -o results.txt -ssl などのコマンドで対象サブドメインを走査。
2. SubOver
   • GitHubで公開されている類似のツール。
   • サブドメインのステータスを調べ、テイクオーバーが可能かどうかを判定。
3. dnsrecon, amass, sublist3r など
   • サブドメインの探索ツール。
   • 大量のサブドメインを収集してから、上記のサブドメインテイクオーバー検出ツールで評価すると効率が良い。
4. 手動確認
   • ブラウザでアクセスしてエラー内容を確認する。
   • dig sub.example.com でDNSレコードの確認。
   • サービス上で該当のリソース（バケット名やホスティング設定）が利用可能かどうかを手動で試す。

対策

1. 不要なDNSレコードの即時削除
   利用停止・削除した外部サービスに対応するDNSレコードは、速やかに削除する。
2. サブドメインの定期的な棚卸し
   DNS管理ツールやクラウドプロバイダのコンソールを用いて、サブドメインおよび外部サービスの紐づけを定期的に確認し、不要な設定がないかチェック。
3. オーナーシップ検証の徹底
   CloudFrontなど一部のサービスでのCNAMEに対するオーナーシップ検証を実施する。
4. ワイルドカードサブドメインの慎重な運用
   ワイルドカード(*.example.com)を乱用するとリスクが高まる場合があるため、本当に必要な場合のみ利用する。
5. カスタムドメインを使用する外部サービスの監査
   GitHub Pages、S3、Herokuなど、カスタムドメインを簡単にマッピングできるサービスに対しては、常に設定状況を把握する。
6. 自動化された脆弱性スキャンの導入
   CI/CDパイプラインや定期的なセキュリティスキャンにサブドメインテイクオーバーのチェックを組み込み、早期に発見する。

参考文献

1. HackerOne Blog - Subdomain Takeover
2. AWS Docs - Amazon Route 53
3. GitHub Pages - カスタムドメインの設定
4. subjack (GitHub)