この記事では、サブドメインの乗っ取りに関する一般的なセキュリティの脅威と、その軽減手順について説明します。
サブドメインの乗っ取りとは
サブドメインの乗っ取りは、多くのリソースを定期的に作成したり削除したりする組織にとって、重大度の高い一般的な脅威です。 サブドメインの引き継ぎは、プロビジョニング解除された 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 サイトやサービスをホストできるようになります。 組織のサブドメインに悪意のあるページやサービスがあると、次のような結果になる可能性があります。
サブドメインのコンテンツに対する制御の喪失 - 組織がコンテンツをセキュリティで保護できないこと、ブランドの損害、信頼の喪失に関する否定的な報道。
疑いのない訪問者からの Cookie の収集 - Web アプリでは、セッション Cookie をサブドメイン (*.contoso.com) に公開するのが一般的です。 それらには任意のサブドメインからアクセスできます。 脅威アクターは、サブドメインの乗っ取りを使用して、本物に似せた検索ページを作成し、疑いを持たないユーザーを騙してアクセスさせることで Cookie (セキュリティで保護されているものも含む) を収集することができます。 よくある誤解は、SSL 証明書を使用することで、サイトとユーザーの Cookie を乗っ取りから保護できるというものです。 しかし、脅威アクターはハイジャックしたサブドメインを使用して、有効な SSL 証明書を適用して受け取ることができます。 有効な SSL 証明書により、セキュリティで保護された Cookie へのアクセスが許可され、悪意のあるサイトの見かけの正当性をさらに向上させることになります。
フィッシング キャンペーン - 悪意のあるアクターは、フィッシング キャンペーンで本物の見た目のサブドメインを悪用することがよくあります。 このリスクは悪意のある Web サイトと MX レコードの両方にまで及びます。その結果、信頼できるブランドに関連付けられた正規のサブドメイン宛てのメールを、脅威アクターが受信できる可能性があります。
さらなるリスク - 悪意のあるサイトを使用して、XSS、CSRF、CORS バイパスなどの他の従来の攻撃にエスカレートする可能性があります。
未解決の DNS エントリを特定する
未解決の可能性がある組織内の DNS エントリを識別するには、Microsoft の GitHub でホストされている PowerShell ツール "Get-DanglingDnsRecords" を使用します。
このツールを使用すると、Azure の顧客がサブスクリプションまたはテナントで作成された既存の Azure リソースに CNAME が関連付けられているすべてのドメインを一覧表示できます。
CNAME が他の DNS サービス内にあり、Azure リソースを示している場合は、入力ファイルの CNAME をツールに指定します。
このツールでは、以下の表に示す Azure リソースがサポートされています。 このツールでは、すべてのテナントの CNAME が抽出されるか、または入力として処理されます。
| サービス | 種類 | FQDNプロパティ | 例 |
|---|---|---|---|
| Azure Front Door（アジュール フロント ドア） | microsoft.network/frontdoors (マイクロソフト ネットワーク/フロントドアーズ) | properties.cName (プロパティ.c名前) | abc.azurefd.net |
| Azure Blob Storage (アジュール・ブロブ・ストレージ) | microsoft.storage/storageアカウント | 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 |
前提条件
次のものを持つユーザーとして、クエリを実行します。
- 少なくとも Azure サブスクリプションへの閲覧者レベルのアクセス権
- Azure Resource Graph への読み取りアクセス権
組織のテナントの全体管理者である場合は、「アクセス権の昇格」のガイダンスに従って 、すべての Azure サブスクリプションと管理グループを管理 し、組織のすべてのサブスクリプションにアクセスできるようにします。
ヒント
Azure Resource Graph には、大規模な Azure 環境を使用している場合に考慮する必要がある調整およびページングの制限があります。
大規模な Azure リソース データ セットの操作について詳しくは、こちらをご覧ください。
このツールでは、サブスクリプションのバッチ処理を使用してこれらの制限を回避しています。
スクリプトを実行する
PowerShell スクリプトの詳細を確認し、 Get-DanglingDnsRecords.ps1し、GitHub からダウンロードします: https://aka.ms/Get-DanglingDnsRecords。
未解決の DNS エントリを修復する
DNS ゾーンを確認し、未解決の、または乗っ取られている CNAME レコードを特定します。 サブドメインが未解決であるか、または乗っ取られていることが判明した場合は、次の手順に従って、脆弱なサブドメインを削除して、リスクを軽減します。
DNS ゾーンから、プロビジョニングされなくなったリソースの FQDN を示す CNAME レコードをすべて削除します。
コントロール内のリソースにトラフィックをルーティングできるようにするには、未解決のサブドメインの CNAME レコードに指定されている FQDN を使って、その他のリソースをプロビジョニングします。
アプリケーション コードで特定のサブドメインへの参照をレビューし、誤ったサブドメイン参照や古いサブドメイン参照を更新します。
侵害が発生しているかどうかを調査し、組織のインシデント対応手順に従って対処します。 調査に関するヒントとベスト プラクティス:
アプリケーション ロジックにより、OAuth 資格情報などのシークレットが未解決のサブドメインに送信された場合、またはプライバシーに関する機密情報がそれらのサブドメインに送信された場合、このデータが第三者に開示される可能性があります。
リソースのプロビジョニングが解除されたときに、CNAME レコードが DNS ゾーンから削除されなかった理由について理解し、今後は Azure リソースのプロビジョニングが解除されたときに、DNS レコードが適切に更新されるようにするための手順を実行します。
未解決の DNS エントリを防止する
未解決の DNS エントリと、その結果として生じるサブドメインの乗っ取りを防止するためのプロセスを組織で導入していることを確認することは、セキュリティ プログラムの重要な部分です。
一部の Azure サービスでは、予防策の作成に役立つ機能が提供されています。詳細については、以下で説明します。 この問題を防止するための他の方法は、組織のベスト プラクティスまたは標準の操作手順に従って確立する必要があります。
Microsoft Defender for App Service を有効にする
Microsoft Defender for Cloud の統合クラウド ワークロード保護プラットフォーム (CWPP) には、Azure、ハイブリッド、マルチクラウドのリソースとワークロードを保護するためのさまざまなプランが用意されています。
Microsoft Defender for App Service プランには、未解決の DNS 検出が含まれています。 このプランを有効にすると、App Service Web サイトを使用停止にしても、そのカスタム ドメインを DNS レジストラーから削除しない場合にセキュリティ アラートを受け取ります。
Microsoft Defender for Cloud による未解決の DNS の保護は、ドメイン管理に Azure DNS を使用しているか、外部のドメイン レジストラーを使用しているかに関係なく利用でき、Windows 上の App Service と Linux 上の App Service の両方に適用されます。
この Microsoft Defender プランのその他の利点の詳細については、「 Microsoft Defender for App Service の概要」を参照してください。
Azure DNS エイリアス レコードの使用
Azure DNS の エイリアス レコード は、DNS レコードのライフサイクルと Azure リソースを結合することで、未解決の参照を防ぐことができます。 たとえば、パブリック IP アドレスまたは Traffic Manager プロファイルをポイントするエイリアス レコードとして修飾されている DNS レコードについて考えます。 これらの基になるリソースを削除すると、DNS エイリアス レコードが空のレコード セットになります。 削除されたリソースは参照されなくなります。 エイリアス レコードを使用して保護できるものには制限があることに注意してください。 現在の、この一覧の制限は次のとおりです。
- Azure Front Door（アジュール フロント ドア）
- Traffic Manager プロファイル
- Azure Content Delivery Network (CDN) エンドポイント
- パブリック IP
現時点で提供されているサービス内容は限られていますが、サブドメインの乗っ取りを防ぐため、可能な限りエイリアス レコードを使用することをお勧めします。
Azure DNS のエイリアス レコードの機能の詳細について説明します。
Azure App Service のカスタム ドメインの検証を使用する
Azure App Service の DNS エントリを作成する場合は、Domain Verification ID を持つ asuid.{subdomain} TXT レコードを作成します。 このような TXT レコードが存在する場合、他の Azure サブスクリプションによってカスタム ドメインの検証を行うこと、つまり乗っ取ることはできません。
これらのレコードによって、他の誰かが CNAME エントリにある同じ名前の Azure App Service を作成することを阻止するわけではありません。 ドメイン名の所有権を証明することができない脅威アクターが、トラフィックを受信したりコンテンツを制御したりすることはできません。
既存のカスタム DNS 名を Azure App Service にマップする方法について説明します。
脅威を軽減するためのプロセスを構築して自動化する
多くの場合、未解決の DNS による脅威を回避するためのクリーンアップ プロセスの実行は、開発者や運用チームの担当になっています。 以下のプラクティスは、組織がこの脅威による問題を回避するのに役立ちます。
防止のための手順を作成します。
リソースを削除するたびにアドレスを再ルーティングするようにアプリケーション開発者に指導します。
サービスを停止するときに、必要なチェック事項の一覧に "DNS エントリの削除" を含めます。
カスタム DNS エントリを持つリソースに 対して削除ロック を設定します。 削除ロックは、リソースがプロビジョニング解除される前にマッピングを削除する必要があることを示すインジケーターとして機能します。 このような対策は、社内の教育プログラムと組み合わせて初めて機能します。
検出の手順を作成します。
DNS レコードを定期的に確認して、サブドメインがすべて以下の Azure リソースにマップされていることを確認します。
- 存在 - *.azurewebsites.net や *.cloudapp.azure.com などの Azure サブドメインを指すリソースを DNS ゾーンに照会します ( Azure ドメインのリファレンス一覧を参照)。
- 所有者が自分であるかどうか - DNS サブドメインが対象としているすべてのリソースを所有していることを確認します。
Azure の完全修飾ドメイン名 (FQDN) エンドポイントとアプリケーション所有者のサービス カタログを維持します。 サービス カタログをビルドするには、次の Azure Resource Graph クエリ スクリプトを実行します。 このスクリプトからは、アクセスできるリソースの FQDN エンドポイント情報が表示され、それらが CSV ファイルに出力されます。 テナントのあらゆるサブスクリプションにアクセスできる場合、このスクリプトでは、次のサンプル スクリプトで確認できるように、それらすべてのサブスクリプションが考慮されます。 特定のサブスクリプション セットに結果を制限するには、画像のようにスクリプトを編集します。
修復のための手順を作成します。
- 未解決の DNS エントリが見つかった場合、チームは侵害が発生したかどうかを調査する必要があります。
- リソースが使用停止になったときにアドレスが再ルーティングされなかった理由を調査します。
- 使用されなくなった DNS レコードは削除するか、組織が所有する正しい Azure リソース (FQDN) へポイントされるようにします。
DNS ポインターをクリーンアップするか、DNS を再要求します。
従来のクラウド サービス リソースが削除されると、対応する DNS は Azure DNS ポリシーに従って保留されます。 予約期間の間、もともと DNS を所有するサブスクリプションの Microsoft Entra テナントに属するサブスクリプションを除き、DNS の再使用は禁止されます。 予約期間が過ぎると、あらゆるサブスクリプションで DNS を自由に再要求できます。 DNS を予約すると、カスタマーには 1) かかる DNS への関連付け/ポインターをクリーンアップする、または 2) Azue で DNS を再要求するための時間が与えられます。 不要な DNS エントリは、できるだけ早く削除することをお勧めします。 予約される DNS 名は、そのクラウドの DNS ゾーンにクラウド サービス名を追加することで派生させることができます。
- パブリック - cloudapp.net
- ムーンケーキ - chinacloudapp.cn
- フェアファックス - usgovcloudapp.net
- ブラックフォレスト - azurecloudapp.de
たとえば、"test" という名前のパブリック ホステッド サービスには "test.cloudapp.net" という DNS が与えられます。
例: サブスクリプション "A" とサブスクリプション "B" は Microsoft Entra テナント "AB" に属する唯一のサブスクリプションです。 サブスクリプション "A" には、DNS 名が "test.cloudapp.net" のクラシック クラウド サービス "test" が含まれます。 クラウド サービスを削除すると、DNS 名 "test.cloudapp.net" が予約されます。 保留期間中、サブスクリプション "A" またはサブスクリプション "B" だけが "test" という名前のクラシック クラウド サービスを作成することで、DNS 名 "test.cloudapp.net" を要求できます。 他のサブスクリプションはそれを要求することはできません。 保留期間を過ぎると、Azure のすべてのサブスクリプションが "test.cloudapp.net" を要求できるようになります。
次のステップ
サブドメインの乗っ取りを防ぐために使用できる関連のサービスと Azure の機能の詳細については、以下のページを参照してください。