ワイルドカード DNS の危険性：GitHub Pages サイトがハイジャックされた事例

旅行から帰ってきたら、プロフェッショナルなドメインがいくつかのインドネシアのオンライン賭博サイトやスロットマシン詐欺をホストしていることに気づくことを想像してみてください。これは開発者 rmeertens にまさに起きたことで、彼らは自分のドメイン immersivepoints.com がサードパーティによって GitHub Pages を使って悪用されていることに気付きました。

このインシデントは、DNS 設定とプラットフォームレベルのドメイン確認の交差点における重要なケーススタディとして機能し、単純な利便性であるワイルドカード DNS レコードがどのように大きなセキュリティホールを開けるかを示しています。

攻撃の構造

著者は GitHub Pages を使って 3D と VR のポイントクラウドビジュアライザーをホストしました。セットアップを簡単にするため、ワイルドカード (*.immersivepoints.com) を GitHub のサーバーに向けるように DNS レコードを設定しました。その意図は、www のような任意のサブドメインが自動的に自分の GitHub Pages サイトに解決されるようにすることでした。

しかし、著者は GitHub Pages がカスタムドメインを処理する方法における根本的な欠陥を発見しました：GitHub は、そのドメインに一致する CNAME ファイルを含むリポジトリがある限り、そのサーバーを指す任意のドメインを解決します。

著者がワイルドカード DNS レコードを持っていたため、immersivepoints.com の 任意 のサブドメインへのリクエストはすべて GitHub にルーティングされました。攻撃者は、プライベートな GitHub リポジトリを作成し、kafka.immersivepoints.com や hd.immersivepoints.com のようなサブドメインの CNAME ファイルを追加するだけでよかったです。GitHub のロードバランサーはリクエストを確認し、攻撃者のリポジトリにマッチさせ、著者のドメインの下で攻撃者のコンテンツを提供しました。

影響: SEO ポイズニングと詐欺

この悪用は、Google Search Console のアラートによって発見されました。そのアラートは、さまざまなサブドメインの新しい所有者が確認されたことを著者に通知しました。調査の結果、著者はこれらのサブドメインが検索結果でランクインしていることを発見し、時には正規のサイトよりも上位に表示されることもありました。

私は間違いなく質の悪いスロットマシン詐欺サイトが私のドメインでホストされていることに誰も巻き込まれないことを願っています。

これは「サブドメイン ハイジャック」の典型的な例であり、攻撃者はダングリング DNS レコードや許容的な設定を利用して悪意のあるコンテンツをホストし、ドメインの評判を傷つけ、ユーザーをフィッシングや詐欺サイトに誘導する可能性があります。

議論: 誰が責任があるのか？

このインシデントは Hacker News で重要な議論を引き起こし、意見はユーザーの設定ミスとプラットフォームの保護措置の欠如の間で分かれました。

「ユーザーの誤り」の視点

いくつかのコメント者は、責任はドメイン所有者に完全にあると主張しました。ワイルドカード レコードをサードパーティ プラットフォームに向けることは、定義上、未割り当てのサブドメインの制御をそのプラットフォームに委ねることを意味します。

あなたは NS に GitHub（あなたが所有していないプラットフォーム）へのあらゆるリクエストを転送するように指示しました。これが期待される結果だと私は思います。

「プラットフォームの責任」の視点

他の人々は、GitHub がより厳格な確認を実装すべきだと主張しました。ユーザーがすでに別の GitHub ユーザーによって使用されているドメインを主張しようとする場合、または所有権の確認済みレコードがない状態でドメインが GitHub の IP に向けられている場合、プラットフォームはその関連付けをブロックすべきです。

一つの提案された解決策は、ドメイン確認のために TXT レコードの使用を義務付けることでした。これは、リクエスターが実際に DNS 設定を制御していることを確認するために、Google Search Console やその他の主要なクラウド プロバイダーで一般的に行われている慣習です。

ドメイン ハイジャックを防ぐ方法

この種の悪用の被害に遭わないために、開発者とサイト所有者は以下のベスト プラクティスに従うべきです。

1. サードパーティ ホスティングでのワイルドカード DNS の回避

特定の理由がありリスクを理解している場合を除き、GitHub Pages、Netlify、Vercel などのサービスにドメインを向けるためにワイルドカード (*) レコードを使用しないでください。使用するつもりのすべてのサブドメインを明示的に定義してください（例: www, blog, app）。

2. ドメイン確認を使用する

GitHub では現在、カスタム ドメインを確認する機能が提供されています。これにより、DNS TXT レコードを介してドメインの所有権を証明し、他の GitHub ユーザーがあなたのドメインまたはそのサブドメインを主張することを防ぐことができます。この設定は個々のリポジトリの設定ではなくアカウント設定にあるため、見落としやすい場合があります。

3. ドメインを監視する

Google Search Console などのツールを使用すると、不正な変更や新しい "所有者" がサブドメインを主張する早期警告サインを得ることができます。DNS レコードと検索エンジンのインデックスを定期的に監査することで、重大なダメージを引き起こす前にハイジャックを特定するのに役立ちます。

最後の考え

このインシデントは、現代のウェブ インフラストラクチャにおける繰り返しテーマを浮き彫りにしています。「使いやすさ」と「デフォルトでのセキュリティ」の間のギャップです。ワイルドカード DNS は便利ですが、GitHub アカウントを持つ誰でも悪用できる脆弱性を作り出します。明示的な確認に向かい、許容的な DNS レコードを避けることで、開発者は自分のデジタル アイデンティティが次のスロットマシン詐欺の波のホストになることを防ぐことができます。