この記事では、サブドメインの乗っ取りという一般的なセキュリティ脅威と、それを軽減するための対策について説明します。
サブドメインの乗っ取りとは
サブドメインの取得は、多くのリソースを定期的に作成・削除する組織にとって、一般的で深刻な脅威です。 サブドメインの引き継ぎは、プロビジョニング解除された Azure リソースを指す DNS レコード がある場合に発生する可能性があります。 このような DNS レコードは、"未解決の DNS" エントリとも呼ばれます。 CNAME レコードは、この脅威に対して特に脆弱です。 サブドメインの乗っ取りが発生すると、悪意のあるアクターが悪意のあるアクティビティを実行しているサイトに、組織のドメイン向けのトラフィックをリダイレクトできるようになります。
サブドメインの乗っ取りの一般的なシナリオは次のとおりです。
創造：
app-contogreat-dev-001.azurewebsites.netの完全修飾ドメイン名 (FQDN) を使用して、Azure リソースをプロビジョニングします。Azure リソースにトラフィックをルーティングするサブドメイン
greatapp.contoso.comを使用して、DNS ゾーンに CNAME レコードを割り当てます。
プロビジョニング解除:
Azureリソースは不要になった後に非プロビジョニングまたは削除されます。
この時点で、CNAME レコード
greatapp.contoso.comDNS ゾーンから削除する必要があります。 CNAME レコードが削除されていない場合でも、アクティブなドメインとして公開されますが、トラフィックはアクティブな Azure リソースにルーティングされません。 これで "未解決" の DNS レコードがある状態になります。未解決のサブドメイン
greatapp.contoso.comが現在脆弱であり、別の Azure サブスクリプションのリソースに割り当てられることで乗っ取られる可能性があります。
乗っ取り:
脅威アクターが一般的に使用可能な方法とツールを使用して、未解決のサブドメインを検出します。
脅威アクターは、以前に管理していたリソースと同じ FQDN を使用して Azure リソースをプロビジョニングします。 この例では、
app-contogreat-dev-001.azurewebsites.netです。サブドメイン
greatapp.contoso.comに送られたトラフィックは、悪意のあるアクターのリソースにルーティングされ、そこで彼らがコンテンツを管理します。
サブドメインの乗っ取りのリスク
DNS レコードが使用できないリソースへポイントしている場合、レコード自体は DNS ゾーンから削除する必要があります。 削除されていない場合、これは "未解決の DNS" レコードになり、サブドメインの乗っ取りが行われる可能性があります。
未解決の DNS エントリが存在していると、脅威アクターは、関連付けられている DNS 名を制御して、悪意のある Web サイトやサービスをホストできるようになります。 組織のサブドメインに悪意のあるページやサービスがあると、次のような結果になる可能性があります。
サブドメインのコンテンツに対するコントロール喪失:組織がコンテンツの保護を怠っていること、ブランドへのダメージ、信頼の喪失に関する否定的な報道。
無防備な訪問者からのクッキー収集:ウェブアプリがセッションクッキーをサブドメイン(*.contoso.com)に公開するのはよくあることです。 どのサブドメインからもアクセスできます。 脅威アクターはサブドメインの奪取を利用して本物らしいページを作成し、無防備なユーザーを騙して訪問させ、クッキー(安全なクッキーであっても)を収集できます。 よくある誤解は、SSL証明書がサイトやユーザーのクッキーを乗っ取りから守るというものです。 しかし、脅威アクターはハイジャックしたサブドメインを使用して、有効な SSL 証明書を適用して受け取ることができます。 有効な SSL 証明書により、セキュリティで保護された Cookie へのアクセスが許可され、悪意のあるサイトの見かけの正当性をさらに向上させることになります。
フィッシングキャンペーン:悪意のある攻撃者はしばしば本物らしいサブドメインを悪用します。 リスクは悪意のあるウェブサイトやMXレコードの両方に及びます。 MXレコードは、脅威アクターが信頼できるブランドに関連する正当なサブドメイン宛てのメールを受け取ることを可能にする可能性があります。
さらなるリスク:悪意のあるサイトはXSS、CSRF、CORS Bypassなどの従来の攻撃にエスカレートする可能性があります。
未解決の DNS エントリを特定する
未解決の可能性がある組織内の DNS エントリを識別するには、Microsoft の GitHub でホストされている PowerShell ツール "Get-DanglingDnsRecords" を使用します。
このツールは、サブスクリプションやテナントで作成した既存のAzureリソースに関連付けられたCNAMEを持つすべてのドメインをリストアップするのに役立ちます。
CNAME が他の DNS サービス内にあり、Azure リソースを示している場合は、入力ファイルの CNAME をツールに指定します。
このツールでは、以下の表に示す Azure リソースがサポートされています。 このツールでは、すべてのテナントの CNAME が抽出されるか、または入力として処理されます。
| サービス | タイプ | FQDNの性質 | 例 |
|---|---|---|---|
| Azure Front Door | microsoft.network/frontdoors (マイクロソフト ネットワーク/フロントドアーズ) | properties.cName | abc.azurefd.net |
| Azure Blob Storage | microsoft.storage/storageaccounts | properties.primaryEndpoints.blob | abc.blob.core.windows.net |
| Azure CDN | microsoft.cdn/profiles/endpoints | プロパティ.ホスト名 | abc.azureedge.net |
| パブリック IP アドレス | microsoft.network/パブリックIPアドレス | properties.dnsSettings.fqdn | abc.EastUs.cloudapp.azure.com |
| Azure Traffic Manager | microsoft.network/trafficmanagerprofiles | properties.dnsConfig.fqdn | abc.trafficmanager.net |
| Azure Container Instances | microsoft.containerinstance/containergroups (サービス名: マイクロソフト コンテナ インスタンス/コンテナー グループ) | properties.ipAddress.fqdn | abc.EastUs.azurecontainer.io |
| Azure API Management | microsoft.apimanagement/service | properties.hostnameConfigurations.hostName | abc.azure-api.net |
| Azure App Service | microsoft.web/sites | プロパティ.デフォルトホスト名 | abc.azurewebsites.net |
| Azure App Service - スロット | microsoft.web/sites/slots | プロパティ.デフォルトホスト名 | abc-def.azurewebsites.net |
前提条件
次のものを持つユーザーとして、クエリを実行します。
- 少なくとも
ReaderロールはAzureサブスクリプションへのアクセスを許可しています。 - Azure Resource Graphへのアクセスを読む。
もしあなたが組織のテナントのグローバル管理者であれば、Elevate accessのガイダンスに従って、すべてのAzureサブスクリプションと管理グループを管理し、組織のすべてのサブスクリプションへのアクセスを得てください。
ヒント
大規模なAzure環境がある場合は、Azure Resource Graphのスロットリングやページングの制限を考慮してください。
大規模な Azure リソース データ セットの操作について詳しくは、こちらをご覧ください。
このツールでは、サブスクリプションのバッチ処理を使用してこれらの制限を回避しています。
スクリプトを実行する
PowerShellスクリプトの詳細については、 Get-DanglingDnsRecords.ps1を参照してください。
未解決の DNS エントリを修復する
DNS ゾーンをレビューし、未解決の CNAME レコードまたは乗っ取られている CNAME レコードを特定します。 もしダングしている、または乗っ取られたサブドメインを見つけた場合は、脆弱なサブドメインを削除し、以下の手順でリスクを軽減してください。
DNS ゾーンから、プロビジョニングされなくなったリソースの FQDN を示す CNAME レコードをすべて削除します。
制御するリソースにトラフィックをルーティングするには、ダングルサブドメインのCNAMEレコードで指定されたFQDNSでより多くのリソースをプロビジョニングしてください。
アプリケーション コードで特定のサブドメインへの参照をレビューし、誤ったサブドメイン参照や古いサブドメイン参照を更新します。
侵害があったかどうかを調査し、組織のインシデント対応手順に従って対応を講じましょう。 調査のヒントやベストプラクティスについては:
もしアプリケーションロジックがOAuth認証情報などの秘密情報を依存サブドメインに送信したり、プライバシーに敏感な情報がそれらのサブドメインに送信された場合、そのデータは第三者に漏れる可能性があります。
リソースをデプロビジョニングした際になぜDNSゾーンからCNAMEレコードが削除されなかったのかを理解し、将来Azureリソースを解除する際にDNSレコードが適切に更新されるよう対策を講じてください。
未解決の DNS エントリを防止する
DNSエントリの不安定さやサブドメインの乗っ取りを防ぐプロセスをセキュリティプログラムの重要な一部にしましょう。
以下のセクションでは、予防策の作成に役立つAzureサービスの機能について説明します。 組織のベストプラクティスや標準作業手順を通じて、この問題を防ぐための他の方法を確立しましょう。
Microsoft Defender for App Service を有効にする
Microsoft Defender for Cloud の統合クラウド ワークロード保護プラットフォーム (CWPP) には、Azure、ハイブリッド、マルチクラウドのリソースとワークロードを保護するためのさまざまなプランが用意されています。
Microsoft Defender for App Service プランには、未解決の DNS 検出が含まれています。 このプランを有効にすると、App Serviceのウェブサイトを終了させたが、そのカスタムドメインをDNSレジストラから削除しない場合にセキュリティアラートが届きます。
Microsoft Defender for Cloudのぶら下がるDNS保護は、Azure DNSでドメインを管理しても外部ドメインレジストラでも利用可能で、WindowsとLinuxの両方のApp Serviceに適用されます。
この機能やこれらのMicrosoft Defenderプランのその他の利点についての詳細は、「Microsoft Defender for App Serviceの紹介」をご覧ください。
Azure DNS エイリアス レコードの使用
Azure DNSエイリアスレコードは、DNSレコードのライフサイクルをAzureリソースと組み合わせることで、ダングルリファレンスを防ぐことができます。 たとえば、パブリック IP アドレスまたは Traffic Manager プロファイルをポイントするエイリアス レコードとして修飾されている DNS レコードについて考えます。 これらの基になるリソースを削除すると、DNS エイリアス レコードが空のレコード セットになります。 DNSエイリアスレコードはもはや削除されたリソースを参照しません。 エイリアス記録には保護できる範囲に限界があります。 現在、リストは以下に限定されています:
- Azure Front Door
- Traffic Manager プロファイル
- Azure Content Delivery Network (CDN) エンドポイント
- パブリック IP
現在のサービス提供は限られていますが、可能な限りサブドメインの乗っ取りを防ぐためにエイリアスレコードを使用してください。
詳細については、Azure DNSエイリアスレコード機能をご覧ください。
Azure App Service のカスタム ドメインの検証を使用する
Azure App ServiceのDNSエントリを作成する際は、ドメイン検証IDを含むasuid.{subdomain} TXTレコードを作成してください。 そのようなTXTレコードが存在する場合、他のAzureサブスクリプションはカスタムドメインを検証したり引き継いだりできません。
これらのレコードは、あなたのCNAMEエントリと同じ名前でAzure App Serviceインスタンスを作成することを妨げるものではありません。 ドメイン名の所有権を証明できないため、悪意のある者はトラフィックを受け取ったりコンテンツを管理したりできません。
詳細については、「既存のカスタムDNS名をAzure App Serviceにマッピングする」をご覧ください。
脅威を軽減するためのプロセスを構築して自動化する
開発者や運用チームは、DNSの脅威を回避するためにクリーンアッププロセスを実施すべきです。 以下の実践は、組織がこの脅威を回避するのに役立ちます。
防止のための手順を作成します。
リソースを削除するたびにアドレスを再ルーティングするようにアプリケーション開発者に指導します。
サービスを停止するときに、必要なチェック事項の一覧に "DNS エントリの削除" を含めます。
- カスタムDNSエントリを持つリソースには 削除ロック を追加します。 削除ロックは、リソースがプロビジョニング解除される前にマッピングを削除する必要があることを示すインジケーターとして機能します。 このような措置は、内部教育プログラムと組み合わせて初めて効果を発揮します。
検出の手順を作成します。
DNS レコードを定期的に確認して、サブドメインがすべて以下の Azure リソースにマップされていることを確認します。
- 存在確認: DNS ゾーンで、*.azurewebsites.net や *.cloudapp.azure.com などの Azure サブドメインを参照するリソースを検索してください（Azure ドメインの参照一覧を参照）。
- あなたの所有権:DNSサブドメインが対象とするすべてのリソースを所有していることを確認しましょう。
Azure の完全修飾ドメイン名 (FQDN) エンドポイントとアプリケーション所有者のサービス カタログを維持します。 Azure Resource Graph、Azureポータル、その他の資産インベントリプロセスを使い、アクセス可能なリソースのFQDNエンドポイント情報を定期的にエクスポートしてください。 テナント内のすべてのサブスクリプションにアクセスできる場合は、すべてのサブスクリプションをインベントリに入れてください。 もし知らなければ、在庫がカバーするサブスクリプションを記録してください。
修復のための手順を作成します。
- チームがDNSの不安定なエントリを見つけたら、侵害があったかどうかを調査してください。
- リソースが使用停止になったときにアドレスが再ルーティングされなかった理由を調査します。
- 使用されなくなった DNS レコードは削除するか、組織が所有する正しい Azure リソース (FQDN) へポイントされるようにします。
DNSポインタのクリーンアップやDNSの再取得
クラシックなクラウドサービスリソースを削除すると、AzureはAzure DNSポリシーに従って対応するDNS名を予約します。 予約期間中は、元々DNS名を所有していたMicrosoft Entraのテナントに属するサブスクリプションのみが再利用可能です。 予約期間が切れた後は、どのAzureサブスクリプションでもDNS名を請求できます。 DNS予約は、関連付けやDNS名へのポインタを整理したり、AzureでDNS名を再取得する時間を与えてくれます。 不要なDNSエントリはできるだけ早く削除してください。 予約DNS名は、そのクラウドのDNSゾーンにクラウドサービス名を付け加えることで導出できます。
- パブリック:
cloudapp.net - 月餅:
chinacloudapp.cn - フェアファックス:
usgovcloudapp.net - ブラックフォレスト:
azurecloudapp.de
例えば、パブリックのホストサービス名 test DNS名は test.cloudapp.netです。
例: サブスクリプション A と B は、Microsoft Entra テナント AB に属する唯一のサブスクリプションです。 サブスクリプションAには、DNS名testのクラシッククラウドサービスtest.cloudapp.netが含まれています。 クラウドサービスを削除すると、Azure DNS名はtest.cloudapp.net予約されます。 予約期間中は、サブスクリプション型Aまたはサブスクリプション型Bのみが、test.cloudapp.netというクラシッククラウドサービスを作成することでDNS名testを請求できます。 他のサブスクリプションは請求できません。 予約期間終了後は、Azureサブスクリプションでtest.cloudapp.netを請求できます。
次のステップ
サブドメインの乗っ取りを防ぐために使用できる関連のサービスと Azure の機能の詳細については、以下のページを参照してください。
