ドメイン/サブドメインのテイクオーバー

ドメインテイクオーバー

もし、スコープ内のサービスによって使用されているドメイン（domain.tld）を発見し、会社がその所有権を失っている場合、あなたはそれを登録し（十分に安価であれば）、会社に知らせることができます。このドメインがGETパラメータやRefererヘッダーを介してセッションクッキーのような機密情報を受信している場合、これは確実に脆弱性です。

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

会社のサブドメインが登録されていない名前の第三者サービスを指している場合、あなたがこの第三者サービスでアカウントを作成し、使用中の名前を登録できれば、サブドメインテイクオーバーを実行できます。

可能なテイクオーバーをチェックするための辞書を持ついくつかのツールがあります：

DNSワイルドカードによるサブドメインテイクオーバー生成

ドメインでDNSワイルドカードが使用されている場合、そのドメインの異なるアドレスが明示的に指定されていない任意の要求されたサブドメインは、同じ情報に解決されます。これはA IPアドレスやCNAMEなどです。

例えば、*.testing.comが1.1.1.1にワイルドカードされている場合、not-existent.testing.comは1.1.1.1を指します。

しかし、IPアドレスを指すのではなく、システム管理者がCNAMEを介して第三者サービスに指す場合、例えばGithubのサブドメイン（sohomdatta1.github.io）のように、攻撃者は自分自身の第三者ページ（この場合はGihub上）を作成し、something.testing.comがそこを指していると言うことができます。なぜなら、CNAMEワイルドカードにより、攻撃者は被害者のドメインに対して任意のサブドメインを生成し、自分のページに指すことができるからです。

この脆弱性の例は、CTFのレポートで見つけることができます：https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api

サブドメインテイクオーバーの悪用

サブドメインテイクオーバーは、インターネット上の特定のドメインに対するDNSスプーフィングであり、攻撃者がドメインのAレコードを設定し、ブラウザが攻撃者のサーバーからのコンテンツを表示することを可能にします。この透明性は、ブラウザがフィッシングに対してドメインを脆弱にします。攻撃者はこの目的のためにtyposquattingやDoppelganger domainsを使用することがあります。特に脆弱なのは、フィッシングメールのURLが正当であるように見えるドメインであり、ドメインの固有の信頼性により、ユーザーを欺き、スパムフィルターを回避します。

詳細についてはこの投稿を確認してください

SSL証明書

SSL証明書は、攻撃者がLet's Encryptのようなサービスを介して生成した場合、これらの偽のドメインの正当性を高め、フィッシング攻撃をより説得力のあるものにします。

クッキーセキュリティとブラウザの透明性

ブラウザの透明性は、同一生成元ポリシーのようなポリシーによって管理されるクッキーセキュリティにも及びます。クッキーは、セッションを管理し、ログイントークンを保存するために使用されることが多く、サブドメインテイクオーバーを通じて悪用される可能性があります。攻撃者は、ユーザーを侵害されたサブドメインに誘導することでセッションクッキーを収集し、ユーザーデータとプライバシーを危険にさらすことができます。

メールとサブドメインテイクオーバー

サブドメインテイクオーバーのもう一つの側面は、メールサービスに関するものです。攻撃者はMXレコードを操作して、正当なサブドメインからメールを受信または送信し、フィッシング攻撃の効果を高めることができます。

高次のリスク

さらなるリスクにはNSレコードのテイクオーバーが含まれます。攻撃者がドメインの1つのNSレコードを制御すると、彼らはトラフィックの一部を自分の制御下にあるサーバーに向けることができます。このリスクは、攻撃者がDNSレコードのTTL（生存時間）を高く設定する場合に増幅され、攻撃の持続時間を延ばします。

CNAMEレコードの脆弱性

攻撃者は、もはや使用されていないか、廃止された外部サービスを指す未請求のCNAMEレコードを悪用する可能性があります。これにより、信頼されたドメインの下にページを作成し、フィッシングやマルウェアの配布をさらに促進することができます。

緩和戦略

緩和戦略には以下が含まれます：

脆弱なDNSレコードの削除 - サブドメインがもはや必要ない場合に効果的です。
ドメイン名の請求 - 関連するクラウドプロバイダーでリソースを登録するか、期限切れのドメインを再購入します。
脆弱性の定期的な監視 - aquatoneのようなツールは、脆弱なドメインを特定するのに役立ちます。組織はまた、DNSレコードの作成がリソースの作成の最終ステップであり、リソースの破棄の最初のステップであることを確認するために、インフラ管理プロセスを見直すべきです。

クラウドプロバイダーにとって、ドメイン所有権の確認はサブドメインテイクオーバーを防ぐために重要です。例えば、GitLabのように、この問題を認識し、ドメイン検証メカニズムを実装しているプロバイダーもあります。

8.1 KiB Raw Blame History Unescape Escape