Maginot DNS攻击复现报告

一、摘要

本报告旨在记录并分析论文[USENIX Security ‘23]《The Maginot Line: Attacking the Boundary of DNS Caching Protection》中所提出的Maginot DNS缓存投毒攻击的复现过程。实验通过构建一个包含易受攻击的条件DNS服务器（CDNS）、攻击者控制的权威服务器以及客户端的隔离网络环境，对BIND9和Microsoft DNS两种主流软件进行了测试。

攻击的核心在于利用CDNS在处理转发查询时存在的Bailiwick检查缺陷。攻击者诱导CDNS向其控制的权威服务器发起一个转发查询，然后在响应中恶意地包含针对其他域（甚至是顶级域，如.org）的伪造NS记录。由于CDNS的转发和递归模式共享全局缓存，这个被错误接受的恶意记录成功污染了缓存，从而劫持了目标域的所有后续解析请求。实验结果直观地验证了Maginot DNS攻击的强大威力与现实危害。

二、原理分析

Maginot DNS攻击与传统的Kaminsky攻击在目标和原理上均有显著区别。它并非依赖暴力猜测，而是利用了特定DNS服务器实现中的逻辑缺陷。

  1. 条件DNS服务器 (CDNS)
    CDNS是一种特殊的DNS服务器，它被配置为同时充当递归解析器和转发器。管理员可以定义一个转发区域 (ZF) 和一个递归区域 (ZR)。

    • 当查询的域名属于ZF时，CDNS会将查询转发给指定的上游服务器。
    • 当查询的域名属于ZR时，CDNS会执行标准的递归解析流程。
      关键在于，这两种模式共享同一个全局缓存。

  2. 转发模式下的Bailiwick检查缺陷
    Bailiwick检查是DNS安全的一项基本原则，旨在防止DNS服务器接受并缓存其权限范围之外的数据。然而，论文发现多种CDNS实现在转发模式下此检查存在漏洞：

    • 当CDNS为ZF中的域名（如example.com）转发查询时，它在验证收到的响应时，错误地将“允许的权限范围”（Q.zone）设置为一个非常宽泛的区域，例如根域（.）。

  3. 攻击流程

    1. 触发转发查询: 客户端向CDNS查询一个由攻击者控制且位于ZF区域的域名（例如 [uuid].example.com）。
    2. CDNS转发: CDNS根据配置，将此查询转发给攻击者控制的权威服务器。
    3. 情报获取与攻击窗口: 攻击者的权威服务器 (server.py) 收到查询后，便获知了CDNS的源IP、源端口和该查询的Transaction ID。它会先通过旁路信道将这些关键信息发送给攻击脚本 (attack.py)，然后故意延迟响应，为攻击创造一个“竞争窗口”。
    4. 发送恶意响应: 攻击脚本 (attack.py) 收到情报后，立即伪造一个DNS响应包，并抢在合法响应前发送给CDNS。
      • 设置AA标志位，声称这是一个权威回答，以提高其在缓存中的信任级别。
      • 在Authority Section中，包含核心的投毒数据：org. IN NS fake-ns.com.。这句伪造的记录声称攻击者的fake-ns.com是.org这个顶级域的权威服务器。
      • 在Additional Section中，提供相应的胶水记录：fake-ns.com. IN A 59.110.55.234（胶水记录的信任等级较低，推荐使用真实存在的域名）
    5. 投毒效果: 此后，任何通过该CDNS解析.org域下网站（如www.pir.org）的请求，都会被重定向到攻击者指定的恶意IP（59.110.55.234），从而实现了对整个顶级域的流量劫持。

需要特别指出的是，本次实验的攻击实现方法与论文中描述的某些攻击向量存在差异，这主要是为了在受限的实验环境中高效地验证核心漏洞

  • 本实验利用了一个Side-Channel，攻击者控制的权威服务器 (server.py) 和攻击脚本 (attack.py) 之间存在直接通信，可以无损、即时地传递源端口和Transaction ID等关键信息。这模拟了一种完美的On-Path攻击场景。

  • 论文中还探讨了更为复杂的Off-Path攻击场景。在这种场景下，攻击者无法直接监听到CDNS的查询流量。为了获取必要信息，攻击者需要采用更高级的技术，例如：

    • SAD DNS: 一种利用ICMP速率限制旁路信道来远程推断目标服务器所使用的源端口的技术（Linux 内核>5.10版本已修复）
    • 大规模暴力猜解: 在拥有足够带宽的条件下，对源端口和Transaction ID进行大规模的泛洪式暴力猜测。

  • 本次复现的核心目标是验证CDNS在转发模式下存在的Bailiwick检查漏洞本身。由于实验环境在带宽和网络复杂度上存在限制，采用理想化的旁路信道可以剥离攻击阶段的复杂性，让我们聚焦并证明核心漏洞的存在及其被利用后所产生的危害。实验中同样可以配置为完全不接收信息，进行暴力猜解，以模拟Off-Path攻击的基本逻辑。

三、实验复现

1. 实验环境

我们搭建了包含三个核心角色的网络环境，支持在Docker (BIND9) 和虚拟机 (MS DNS) 中复现。

服务/角色 IP地址 (示例) 软件/系统 作用
CDNS (受害者) 10.2.0.2 BIND9 / MS DNS 被攻击的条件DNS服务器。配置将example.com域转发到攻击者服务器。
攻击者 10.2.0.3 Debian / Python 运行attack.py和server.py，同时扮演攻击发起者和恶意权威服务器。
客户端 10.2.0.3 dig工具 用于在攻击前后验证CDNS的解析结果，确认投毒是否成功。

2. 实验步骤

  1. 环境启动与配置：

    • 启动Docker容器或虚拟机。
    • 确保CDNS的条件转发规则已正确配置：将example.com转发至攻击者IP (10.2.0.3)。
    • 在攻击者主机上，启动server.py脚本，使其监听在53端口，准备接收转发查询并创造攻击窗口。

  2. 攻击前状态验证：

    • 请勿在`BIND9`上运行，你的第三方权威服务器的信任等级较低
    • 在攻击者主机上，使用dig工具向CDNS查询目标域的NS记录。此时应返回来自合法权威服务器的正确结果。
      dig @10.2.0.2 org NS

  3. 执行攻击：

    • 运行攻击脚本attack.py。在本次复现中，我们主要采用旁路信道模式，即不进行暴力猜测，直接利用server.py泄露的源端口和TXID。
    • 在MS DNS环境下，可以关闭Source Port旁路，其范围较小，仅有2500左右
      # attack.py 关键配置
      PORT_RANGE = None  # 启用旁路信道模式获取端口
      ID_RANGE = None    # 启用旁路信道模式获取TXID
    • 脚本将自动触发查询、接收情报、并发送伪造的响应包。
      # 运行攻击
      python3 attack.py

      [INFO] Round 1: Starting...
      [INFO] Round 1: Waiting for side-channel intelligence...
      [*] [Server] Intelligence sent: sport=34567,txid=12345
      [INFO] Round 1: Sending 1 spoofed packets...
      [SUCCESS] Cache poisoned successfully in round 1!

  4. 攻击后结果验证：

    • 再次使用dig向CDNS查询。
    • 验证NS记录投毒: 查询.org的NS记录，可以看到其已被成功篡改为攻击者指定的kie-chi.com.。
      docker compose exec -it attacker dig @10.2.0.2 org NS

      ;; ANSWER SECTION:
      org.                    3586    IN      NS      kie-chi.com.

      ;; ADDITIONAL SECTION:
      kie-chi.com.            3586    IN      A       59.110.55.234
    • 验证流量劫持: 查询.org下的任意域名，其A记录已被劫持到攻击者指定的IP。
      docker compose exec -it attacker dig @10.2.0.2 www.org

      ;; ANSWER SECTION:
      www.org.                86400   IN      A       1.2.3.4
      实验结果与预期完全一致，证明Maginot DNS攻击复现成功。

3. 实验模式与挑战

  • On-Path/旁路信道模式: 这是最有效的攻击模式，模拟了攻击者能够监听到CDNS与上游服务器之间流量的场景。本实验通过server.py与attack.py之间的通信来模拟此模式，成功率极高
  • Off-Path/暴力猜解模式: 通过将PORT_RANGE和ID_RANGE设置为一个范围，可以模拟离线攻击。这需要暴力猜测源端口和TXID，成功率较低，但它证明了漏洞本身的存在与攻击者是否在网络路径上无关。特别是对于MS DNS，其源端口范围较小且相对固定，使得暴力猜解更为可行

四、防御措施

针对Maginot DNS攻击，论文和现代DNS实践提出了以下缓解与防御措施：

  1. 修复Bailiwick检查逻辑:
    最根本的修复方法是DNS软件厂商修正其在转发模式下的Bailiwick检查逻辑。例如，BIND在后续版本中已修复此问题，当处理转发查询的响应时，会将Q.zone正确地限制在ZF区域内，而不是根域。

  2. 源端口随机化 (SAD/Kaminsky防御):
    对于Off-Path攻击，增强源端口的随机性是行之有效的防御手段。这大大增加了攻击者暴力猜解的难度，但无法防御On-Path攻击。

  3. 部署DNSSEC:
    DNSSEC是抵御此类缓存投毒攻击的根本性解决方案。如果CDNS配置了DNSSEC验证，它在收到伪造的响应后，会检查其数字签名。由于攻击者无法提供由.org合法持有者签名的记录，该恶意响应将被识别为伪造并丢弃，从而彻底阻止攻击。

五、结论

本次实验成功复现了Maginot DNS缓存投毒攻击，深刻揭示了主流DNS软件在特定配置（CDNS）下存在的严重安全漏洞。实验证明，攻击者可利用转发模式的Bailiwick检查缺陷，污染共享缓存，从而实现对整个顶级域名的流量劫持，其危害远超传统缓存投毒攻击。该研究成果强调了在软件开发中，对所有功能模式进行一致且严格的安全检查的重要性，并再次凸显了在全球范围内推广和部署DNSSEC的紧迫性与必要性。