DNS 漏洞导致域控失陷的风险有多大?

很多人看到 CVSS 9.8 这个分数,第一反应是"完了";也有人看到"补丁发布时未确认在野利用、公开漏洞库标注无公开利用代码",立刻松一口气觉得可以拖两周。这两种反应都偏了。CVE-2026-62878 这条 Windows DNS 的栈缓冲区溢出,风险到底有多大,得看它落在哪台机器上——落在一台只服务单一网段的内部解析服务器上,和落在一台兼任 DNS 角色的域控制器上,完全是两回事。

打个通俗的比方:DNS 相当于整个网络的电话簿查询台。平时没人注意它,但所有人打电话都得先问它号码。而在 Windows 域环境里,这个查询台常常和"发身份证的办事窗口"设在同一间屋子里。攻击者不需要账号密码,不需要骗谁点链接,只要网络能把数据包送到解析服务面前,就有机会在这台机器上执行代码。这也是 ZDI 把它列为当月四个未认证 9.8 级远程代码执行缺陷中最突出的一条的原因:攻击门槛低,而它待的位置太关键。

为什么域控上的这条风险要单独算

域控排第一,不是因为它那台机器的分数更高——同一个漏洞,分数是一样的。差别在失陷之后。解析服务和身份基础设施跑在同一台主机上,一次代码执行的后果就直接落在域环境上,而不是仅仅让某个网段查不到域名。反过来,处置的时候也麻烦:域控上的解析一中断,登录、组策略和所有依赖名称解析的业务都会跟着受影响,所以维护窗口宁可拆成多批、按站点错开,也别为了赶进度一次性重启所有解析节点。

还有一层容易被忽略的连带关系是转发器。本地解析不了的查询会递交给上游,链路上任何一环先被拿下,依赖它的下游节点就得面对攻击者可控的响应流量。需要说清楚的是,"从一台暴露在互联网上的未修补 DNS 服务器向内网级联渗透"目前属于分析文章里的风险推断,不是已证实的事件。但这个推断足以支撑一个判断:对外暴露的解析节点要优先处置。

普通运维能控制的变量只有一个

在补丁排期落地之前,唯一还捏在自己手里的变量是网络可达性。把解析服务的入站来源从"任意地址"收到明确的客户端网段和上下游节点,取消非必要的对外映射,关掉不该开的开放递归,把区域传输限制到已知的辅助服务器。这些都不是这条漏洞的专属操作,但它们决定了攻击者的数据包能不能送到有问题的代码面前。至于确实短期内打不上补丁、又对互联网可达的节点,临时下线或彻底阻断外部访问,比"加监控继续观察"更实际——无需凭据、复杂度又低的漏洞,留给检测侧的反应时间本来就不多。

顺带提醒一点:关于代码执行拿到的权限级别,不同来源表述并不一致,有说以服务进程权限执行的,也有说高权限的。内部通告里按更坏的假设准备就行,别急着给出比公开资料更确定的结论。

真正决定风险大小的,往往不是漏洞本身,而是资产清单里有没有漏掉哪台启用了 DNS Server 角色的机器,以及入站规则里有没有几条连自己都说不清来由的放通。