防止 DNS 項目懸空並避免子網域接管
本文說明子網域接管的常見安全性威脅,以及可採取的預防步驟。
什麼是子網域接管?
對於經常建立和刪除許多資源的組織,子網域接管是常見的高嚴重性威脅。 當您有 DNS 記錄指向已取消佈建的 Azure 資源時,可能會發生子網域接管。 這類 DNS 記錄也稱為「無關聯 DNS」項目。 CNAME 記錄特別容易遭受此威脅。 子網域接管可讓惡意執行者將組織網域的流量重新導向至執行惡意活動的網站。
子網域接管的常見案例:
建立:
您使用完整網域名稱 (FQDN)
app-contogreat-dev-001.azurewebsites.net
佈建 Azure 資源。您在 DNS 區域中以子網域
greatapp.contoso.com
指派 CNAME 記錄,將流量路由傳送至 Azure 資源。
取消佈建:
不再需要 Azure 資源之後,就取消佈建或刪除。
此時,應從 DNS 區域移除 CNAME 記錄
greatapp.contoso.com
。 如果未移除 CNAME 記錄,則會公告為作用中網域,但不會將流量路由傳送至作用中的 Azure 資源。 您現在有「懸置」DNS 記錄。懸置子網域
greatapp.contoso.com
現在易受攻擊,可能指派給另一個 Azure 訂用帳戶的資源而被接管。
接管:
威脅行為者使用常用的方法和工具來探索懸置子網域。
威脅行為者使用您先前所控制資源的相同 FQDN 來佈建 Azure 資源。 在此範例中是
app-contogreat-dev-001.azurewebsites.net
。傳送至子網域
greatapp.contoso.com
的流量現在路由傳送至惡意行為者的資源,而由他們控制內容。
子網域接管的風險
當 DNS 記錄指向無法使用的資源時,記錄本身應從 DNS 區域移除。 如果尚未刪除,則會變成「懸置 DNS」記錄,可能導致子網域接管。
懸置 DNS 項目可讓威脅行為者控制相關聯的 DNS 名稱,以裝載惡意網站或服務。 組織子網域上的惡意頁面和服務可能導致:
失去對子網域內容的控制權 - 出現組織無法保護內容的負面新聞,以及品牌受損和失去信任。
從不知情的訪客收集 Cookie - Web 應用程式通常會向子網域 (*.contoso.com) 公開工作階段 Cookie。 任何子網域都可以加以存取。 威脅行為者可以使用子網域接管來建立看似真正的頁面、欺騙不知情的使用者去瀏覽,然後收集其 Cookie (甚至是安全 Cookie)。 通常都誤解使用 SSL 憑證可保護網站及使用者的 Cookie,而免於遭到接管。 然而,威脅行為者可以使用被綁架的子網域來申請並得到有效的 SSL 憑證。 有效 SSL 憑證允許他們存取安全 Cookie,還可進一步讓人更相信惡意網站的合法性。
網路釣魚活動 - 惡意執行者經常在網路釣魚活動中利用看似真正的子網域。 此風險會擴展到惡意網站和 MX 記錄,這可讓威脅行為者接收導向與受信任品牌相關聯合法子網域的電子郵件。
進一步的風險 - 惡意網站可能用來逐步升級為其他傳統攻擊,例如 XSS、CSRF、CORS 略過等等。
識別懸置 DNS 項目
若要識別組織內可能懸置的 DNS 項目,請使用 Microsoft 放在 GitHub 上的 PowerShell 工具 "Get-DanglingDnsRecords"。
此工具協助 Azure 客戶列出網域,而這些網域全都有與訂用帳戶或租用戶上建立的現有 Azure 資源相關聯的 CNAME。
如果您的 CNAME 位於其他 DNS 服務中,並指向 Azure 資源,請以輸入檔提供 CNAME 給工具。
此工具支援下表所列的 Azure 資源。 此工具擷取或接受所有租用戶 CNAME 作為輸入。
服務 | 類型 | FQDNproperty | 範例 |
---|---|---|---|
Azure Front Door | microsoft.network/frontdoors | properties.cName | abc.azurefd.net |
Azure Blob 儲存體 | microsoft.storage/storageaccounts | properties.primaryEndpoints.blob | abc.blob.core.windows.net |
Azure CDN | microsoft.cdn/profiles/endpoints | properties.hostName | abc.azureedge.net |
公用 IP 位址 | microsoft.network/publicipaddresses | properties.dnsSettings.fqdn | abc.EastUs.cloudapp.azure.com |
Azure 流量管理員 | microsoft.network/trafficmanagerprofiles | properties.dnsConfig.fqdn | abc.trafficmanager.net |
Azure Container Instance | microsoft.containerinstance/containergroups | properties.ipAddress.fqdn | abc.EastUs.azurecontainer.io |
Azure API 管理 | microsoft.apimanagement/service | properties.hostnameConfigurations.hostName | abc.azure-api.net |
Azure App Service | microsoft.web/sites | properties.defaultHostName | abc.azurewebsites.net |
Azure App Service - 位置 | microsoft.web/sites/slots | properties.defaultHostName | abc-def.azurewebsites.net |
必要條件
以具有下列權限的使用者身分執行查詢:
- 至少有 Azure 訂用帳戶的讀者層級存取權
- Azure 資源圖表的讀取存取權
如果您是組織租用戶的全域系統管理員,請使用提高存取權以管理所有 Azure 訂用帳戶和管理群組 (部分機器翻譯) 中的指導,取得對組織所有訂用帳戶的存取權限
執行指令碼
深入了解 PowerShell 指令碼 Get-DanglingDnsRecords.ps1,並從 GitHub 下載:https://aka.ms/Get-DanglingDnsRecords。
修復懸置 DNS 項目
檢閱您的 DNS 區域,並識別懸置或受接管的 CNAME 記錄。 如果發現子網域懸置或已被接管,請移除易受攻擊的子網域,並透過下列步驟降低風險:
從 DNS 區域中,找出哪些 CNAME 記錄指向已不再佈建的資源的 FQDN,然後全部移除。
若要讓流量路由傳送至您所控制的資源,請以懸置子網域的 CNAME 記錄中指定的 FQDN 來佈建更多資源。
檢閱應用程式碼中對特定子網域的參考,並更新任何不正確或過期的子網域參考。
調查是否發生任何入侵,並根據組織的事件回應程序採取動作。 調查的秘訣和最佳做法:
如果您的應用程式邏輯導致秘密 (例如 OAuth 認證) 傳送至懸空子網域,或隱私權敏感性資訊傳送至這些子網域,則該資料有可能暴露給第三方。
了解取消佈建資源後,為何沒有從 DNS 區域移除 CNAME 記錄,並採取步驟以確保未來取消佈建 Azure 資源時,DNS 記錄會適當地更新。
防止懸置 DNS 項目
確保組織已實作程序來防止懸置 DNS 項目,並將引起的子網域接管納入為安全性計畫的重要部分。
某些 Azure 服務的功能可協助建立預防性措施,詳述如下。 您必須透過組織的最佳做法或標準作業程序,建立其他方法來防止此問題。
啟用適用於 App Service 的 Microsoft Defender
「適用於雲端的 Microsoft Defender」的整合式雲端工作負載保護平台 (CWPP) 提供一系列方案,以保護 Azure、混合式及多雲端資源和工作負載。
適用於 App Service 的 Microsoft Defender 方案包含懸置 DNS 偵測。 啟用此方案後,如果您解除委任 App Service 網站,但未從 DNS 註冊機構移除自訂網域,則會收到安全性警示。
不論您的網域由 Azure DNS 或外部網域註冊機構來管理,都有「適用於雲端的 Microsoft Defender」的懸置 DNS 保護,且適用於 Windows 和 Linux 上的 App Service。
若要深入了解這一點和 Microsoft Defender 方案的其他優點,請參閱適用於 App Service 的 Microsoft Defender 簡介。
使用 Azure DNS 別名記錄
Azure DNS 的別名記錄可以將 DNS 記錄的生命週期與 Azure 資源結合,以防止懸置參考。 例如,限定為別名記錄以指向公用 IP 位址或流量管理員設定檔的 DNS 記錄。 若您刪除這些基礎資源,則 DNS 別名記錄會變成空白記錄集, 不再參考已刪除的資源。 請務必注意,使用別名記錄可保護的項目有限。 目前只能保護:
- Azure Front Door
- 流量管理員設定檔
- Azure 內容傳遞網路 (CDN) 端點
- 公用 IP
儘管目前的服務供應項目有限,建議盡可能使用別名記錄來防範子網域接管。
使用 Azure App Service 的自訂網域驗證
建立 Azure App Service 的 DNS 項目時,請以網域驗證識別碼建立 asuid.{subdomain} TXT 記錄。 當這類 TXT 記錄存在時,沒有其他 Azure 訂用帳戶可以驗證自訂網域,也就是接管。
這些記錄無法防止使用 CNAME 項目中相同的名稱來建立 Azure App Service。 只要無法證明網域名稱的所有權,威脅行為者就無法接收流量或控制內容。
深入了解如何將現有的自訂 DNS 名稱對應至 Azure App Service。
建立並自動執行程序以減輕威脅
通常由開發人員和作業小組負責執行清除程序,以避免懸置 DNS 威脅。 下列做法有助於確保組織避免遭受此威脅。
建立預防程序:
教導應用程式開發人員每當刪除資源時就重新路由位址。
將「移除 DNS 項目」放在解除委任服務時的必要檢查清單上。
將刪除鎖定放在具有自訂 DNS 項目的任何資源上。 刪除鎖定如同指標,提醒取消佈建資源之前必須移除對應。 這種措施須結合內部教育計劃才能發揮作用。
建立探索程序:
定期檢閱 DNS 記錄,以確保子網域全都對應至以下 Azure 資源:
- 存在 - 在 DNS 區域中查詢哪些資源指向 Azure 子網域,例如 *.azurewebsites.net 或 *.cloudapp.azure.com (請參閱 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) 在 Azure 中重新宣告 DNS。 建議刪除非必要的最早 DNS 項目。 將雲端服務名稱附加至該雲端的 DNS 區域,即可得到保留的 DNS 名稱。
- Public - cloudapp.net
- Mooncake - chinacloudapp.cn
- Fairfax - usgovcloudapp.net
- BlackForest - azurecloudapp.de
例如,Public 中名為 “test” 的託管服務會有 DNS “test.cloudapp.net”
範例:訂用帳戶 'A' 和訂用帳戶 'B' 是唯一屬於 Microsoft Entra 租用戶 'AB' 的訂用帳戶。 訂用帳戶 'A' 包含具有 DNS 名稱 'test.cloudapp.net' 的傳統雲端服務 'test'。 刪除雲端服務時會保留 DNS 名稱 'test.cloudapp.net'。 在保留期間,只有訂用帳戶 'A' 或訂用帳戶 'B' 能夠建立名為 'test' 的傳統雲端服務,以宣告 DNS 名稱 'test.cloudapp.net'。 不允許其他訂用帳戶宣告 DNS。 保留期間結束之後,Azure 中的任何訂用帳戶馬上可以宣告 ‘test.cloudapp.net’。
下一步
若要深入了解可用來防範子網域接管的相關服務和 Azure 功能,請參閱下列頁面。