Cloudflare 參與了一項涉及多廠商、覆蓋全產業的工作，旨在緩解兩個關鍵的 DNSSEC 漏洞。這些漏洞給提供 DNS 解析服務的關鍵基礎架構帶來了重大風險。Cloudflare 的公用解析程式 1.1.1.1 服務免費為任何人提供 DNS 解析。在這些漏洞公開披露之前，我們已對 Cloudflare 的公用解析程式 1.1.1.1 服務採取了緩解措施。在發佈修復這些漏洞的新軟體版本後，使用 unbound（開放原始碼軟體）的內部解析程式得到了及時升級。
在這兩個漏洞披露之前，所有 Cloudflare DNS 基礎架構都已受到保護，目前是安全的。這些漏洞不會影響我們的權威 DNS 或 DNS 防火牆產品。
所有主要的 DNS 軟體廠商都發佈了其軟體的新版本。所有其他主要的 DNS 解析程式提供者也都採取了適當的緩解措施。如果您尚未更新 DNS 解析程式軟體，請立即更新。
背景
網域名稱系統 (DNS) 安全擴展（通常稱為 DNSSEC）是 DNS 通訊協定的擴展，它新增了驗證和完整性功能。DNSSEC 使用密碼編譯金鑰和簽名來驗證 DNS 回應的真實性。DNSSEC 通訊協定規範具有某些要求，這些要求優先考慮可用性，但代價是增加了驗證 DNS 解析程式的複雜性和運算成本。本部落格中討論的漏洞緩解措施要求套用本地策略來放寬這些要求，以避免耗盡驗證器的資源。
DNS 和 DNSSEC 通訊協定的設計遵循穩健性原則：「做事要謹慎，接受他人的東西要寬容」。過去有許多漏洞利用了遵循此原則的通訊協定要求。惡意行為者可以利用這些漏洞攻擊 DNS 基礎架構，在這種情況下，他們會透過製作具有複雜設定的 DNSSEC 回應來增加 DNS 解析程式的工作量。通常情況下，我們必須在允許通訊協定適應和發展的靈活性與維護我們所營運之服務的穩定性和安全性之間建立務實的平衡。
Cloudflare 的公用解析程式 1.1.1.1 是一項以隱私為中心的公用解析程式服務。我們一直在使用更嚴格的驗證和限制，旨在保護我們自己的基礎架構，以及保護在我們網路之外營運的權威 DNS 伺服器。因此，我們經常收到有關解析失敗的投訴。經驗告訴我們，嚴格的驗證和限制可能會在某些極端情況下影響可用性，尤其是在 DNS 網域設定不當的情況下。但是，這些嚴格的驗證和限制對於提高 DNS 基礎架構的整體可靠性和彈性是必不可少的。
下文將介紹這些漏洞並說明我們如何緩解這些漏洞。
Keytrap 漏洞 (CVE-2023-50387)
介紹
DNSSEC 簽名區域可以包含多個金鑰 (DNSKEY)，用於對 DNS 區域的內容進行簽名，DNS 回應中的資源記錄集 (RRSET) 可以有多個簽名 (RRSIG)。需要多個金鑰和簽名來支援金鑰輪換、演算法輪換和多簽名者 DNSSEC 等功能。DNSSEC 通訊協定規範要求驗證 DNS 解析程式在驗證 DNS 回應時嘗試所有可能的金鑰和簽名組合。
在驗證期間，解析程式會查看每個簽名的金鑰標籤，並嘗試找到用於簽名的關聯金鑰。金鑰標籤是一個無符號的 16 位元數字，它是金鑰資源資料 (RDATA) 的總和檢查碼。金鑰標籤旨在允許將簽名與據稱建立該簽名的金鑰高效配對。但是，金鑰標籤不是唯一的，多個金鑰可能具有相同的金鑰標籤。惡意行為者可以輕鬆製作 DNS 回應，其中包含多個具有相同金鑰標籤的金鑰以及多個簽名，但這些簽名都無法通過驗證。驗證解析程式在嘗試驗證此回應時必須嘗試每種組合（金鑰數量乘以簽名數量）。這會使驗證解析程式的運算成本增加很多倍，從而降低所有使用者的效能。這被稱為 Keytrap 漏洞。
此漏洞的變體包括使用多個簽名和一個金鑰、使用一個簽名和具有衝突金鑰標籤的多個金鑰，以及使用多個金鑰並將相應的雜湊值新增到父委託簽名者記錄中。
緩解
我們已經限制了在區域切割時可以接受的最大金鑰數量。區域切割是指父區域委託給子區域，例如 .com 區域將 cloudflare.com 委託給 Cloudflare 名稱伺服器。即使已經實施了此限制並為我們的平台構建了各種其他保護措施，我們仍然發現，處理來自權威 DNS 伺服器的惡意 DNS 答案仍然需要耗費大量運算資源。
為了解決並進一步緩解此漏洞，我們為每個 RRSET 新增了簽名驗證限制，並為每個解析任務新增了總簽名驗證限制。一個解析任務可能包括對外部權威 DNS 伺服器的多次遞迴查詢，以回答單一 DNS 問題。超出這些限制的用戶端查詢將無法解析，並將收到帶有擴展 DNS 錯誤 (EDE) 代碼 0 的回應。此外，我們新增了指標，使我們能夠偵測試圖利用此漏洞的攻擊。
NSEC3 iteration and closest encloser proof 漏洞 (CVE-2023-50868)
介紹
NSEC3 是用於驗證拒絕存在的另一種方法。您可以在此處瞭解有關驗證拒絕存在的更多資訊。NSEC3 使用從 DNS 名稱派生的雜湊值（而不是直接使用 DNS 名稱）來嘗試防止區域列舉，並且該標準支援雜湊計算的多次反覆運算。但是，由於完整的 DNS 名稱用作雜湊計算的輸入，因此增加超出初始值的雜湊反覆運算不會提供任何附加值，並且在 RFC9276 中不建議這樣做。在查找 closest enclosure proof 時，這種複雜性會進一步加劇。來自權威 DNS 伺服器的惡意 DNS 回應可以設定較高的 NSEC3 反覆運算次數和具有多個 DNS 標籤的長 DNS 名稱，從而透過使其執行不必要的雜湊計算來耗盡驗證解析程式的運算資源。
緩解
對於此漏洞，我們採用了與 Keytrap 類似的緩解技術。我們為每個解析任務新增一個總雜湊計算限制，以回答單一 DNS 問題。同樣，超過此限制的用戶端查詢將無法解析，並將收到帶有 EDE 代碼 27 的回應。我們還新增了指標來追蹤雜湊計算，以便儘早發現試圖利用此漏洞的攻擊。
時間表
|
UTC 日期和時間 |
活動 |
|
2023-11-03 16:05 |
Quad9 的 John Todd 邀請 Cloudflare 參加聯合工作組，討論新的 DNS 漏洞 |
|
2023-11-07 14:30 |
一組 DNS 廠商和服務提供者在 IETF 118 期間開會討論該漏洞。討論和協作仍在 DNS-OARC 託管的封閉聊天組中進行 |
|
2023-12-08 20:20 |
Cloudflare 公用解析程式 1.1.1.1 已完全修補，可緩解 Keytrap 漏洞 (CVE-2023-50387) |
|
2024-01-17 22:39 |
Cloudflare 公用解析程式 1.1.1.1 已完全修補，可緩解 NSEC3 iteration count and closest encloser 漏洞 (CVE-2023-50868) |
|
2024-02-13 13:04 |
Unbound 封裝發佈 |
|
2024-02-13 23:00 |
Cloudflare 內部 CDN 解析程式已完全修補，可緩解 CVE-2023-50387 和 CVE-2023-50868 |
鳴謝
我們要感謝德國國家應用網路安全研究中心 ATHENE 的 Elias Heftrig、Haya Schulmann、Niklas Vogel 和 Michael Waidner 發現 Keytrap 漏洞並進行負責任的披露。
我們要感謝網際網路系統聯盟 (ISC) 的 Petr Špaček 發現 NSEC3 iteration and closest encloser proof 漏洞並進行負責任的披露。
我們要感謝 Quad9 的 John Todd 以及 DNS 操作分析和研究中心 (DNS-OARC) 促進各利益相關者之間的協調。
最後，我們要感謝代表各種 DNS 廠商和服務提供者的 DNS-OARC 社群成員，他們齊心協力，不懈努力地修復這些漏洞，朝著使網際網路具有彈性和安全性的共同目標而努力。