聚焦源代码安全,网罗国内外最新资讯!
编译:奇安信代码卫士团队
清华大学和加州大学组成的研究团队发现一种可发动 DNS 缓存投毒攻击的新方法。这种方法重新激活了本以为已完全修复的2008年现身的一个 bug。
DNS 欺骗或缓存投毒简介
域名系统 (DNS) 可理解为互联网的电话本。它和电话本很像,如果你想拨打朋友 Alex 的电话,那么就需要通过电话本这个系统查找他的电话。与之类似,当你浏览某个域名时,Web 浏览器试图通过互联网目录系统 DNS 来识别其 IP 地址。
实际流程会分好多步骤,而并非如此简单直接。
例如,如果你或者你所在网络上的其他人曾访问 codesafe.qianxin.com,那么我们的 IP 地址将会被缓存在你的电脑上或者中介服务器上。也就是说,下次你访问 codesafe.qianxin.com 时,就不必再次执行 DNS 查找了。你的计算机或 Web 浏览器已经知道定位你。
DNS 缓存投毒攻击指的是污染已经存在于中介服务器上的这个缓存。想象一下,如果你的计算机(客户端)所依赖的用于查找 codesafe.qianxin.com 的IP 地址 DNS 缓存返回的 IP 地址不是我们的会发生什么情况?攻击者如果可疑投毒 DNS 缓存,那么就能够损害互联网。
这个漏洞是由安全研究员 Dan Kaminsky 在2008年发现的。当设备通过 DNS查找某域名的 IP 地址时,在向 DNS 服务器发出的请求中会包含一个唯一的 ‘交易ID‘号码。当该服务器响应该设备时(如 codesafe.qianxin.com 的 IP 地址),那么设备将仅接受包含该原始交易 ID 的响应。这样做的原因很简单:阻止恶意 DNS 服务器通过恶意无效的 DNS 条目对设备发起洪水攻击。
如果未部署这些检查,那么恶意 DNS 服务器能够轻易给出用户一个受欺骗的 IP 地址,而当用户连接到网站时会被重定向至攻击者的服务器而非合法服务器,而这都是由受欺骗的 DNS 响应造成的。
不过,Kaminsky 发现仅存在 65,536 个交易 ID。因此,攻击者可以发送多个虚假的 DNS 响应,其ID 号码范围是0到65,535,而同时阻止第一个响应被缓存。为阻止第一个 DNS 响应被缓存,攻击者会发送含有该域名多个变体的响应,如包含不同子域名的响应:1.codesafe.qianxin.com、2.codesafe.qianxin.com 等。
最终,攻击者能够猜测出 DNS 请求的正确交易 ID,同时通过 DNS 响应提供恶意服务器 IP。下次当用户访问 codesafe.qianxin.com 时,如攻击成功实施,则该域名将解析到攻击者的服务器。
DNS 缓存投毒是如何重返的?
为阻止 DNS 缓存投毒攻击,已实现源端口随机化。这意味着,即使作为攻击者,如果我最终猜测出你的设备在 DNS 请求中指定的交易 ID,那么我也不清楚将 DNS 响应发送到什么地方,因为你的设备现在提出的 DNS 查找源自随机端口(理论上有65,536个)而非端口53。
鉴于存在数十亿种可能性,这就使得 DNS 缓存投毒攻击实际上不可能通过 Kaminsky 发现的方法执行。但研究人员发布了一种方法利用侧信道攻击推断 DNS 客户端的源端口号码。由于源端口不确定,因此通过上述方法猜测交易 ID 就很可能执行 Kaminsky 所述的 DNS 缓存投毒攻击。
由于 Linux 内核处理 ICMP 请求的方法为人所知和(ping 或 tracert),因此就可能猜出源端口。为节约带宽,Linux 内置的速度限制器将导入请求的数量默认限制为1000/秒并使用计数器追踪这些请求。在基于 Linux 服务器上的封闭端口上每收到一个请求,计数器都会减1而服务器会响应“无法达到“。也就是说,如果你向服务器上不同的随机端口上发送1000个程序包,服务器将在这一秒截断你。但这也表明你关于哪个端口会开放的所有1000个猜测都是错误的。有意思的是,对于在有效的开放端口上收到的每个请求,计数器并不会减少。而且,服务器也不会发送”无法到达“的响应。也就是说,每秒钟,攻击者会将1000个受欺骗的程序包对 DNS 解析器发起洪水攻击。以这种方式,在数秒时间内,攻击者将能够推断出DNS 解析器上哪些端口是开放的并尝试投毒。获得正确的端口后,他们之后就能重新利用 Kaminsky 发现的漏洞启动 DNS 投毒攻击。
是否存在解决方案?
和源端口随机化为攻击者增加复杂性一样,Linux 内核随机化了速率限制器的最大值而非总是使用1000,是已证明的行之有效的方法。这一修复方案将使攻击者难以推断执行 DNS 欺骗攻击所需要的正确端口。
BlueCat 公司的软件安全总监 David Maxwell 提供的建议是,“Linux 在10月16日发布的 Linux 内核钟包含了自动随机化速率限制,这一变化意味着多数系统在运行该内核还需要时日。速率限制值尚未发布。同时,你可以使用小型 shell 脚本不断变换 ICMP 的速率限制。虽然不如内核钟内置的那样干净,但是一种可行的应变措施。目前我们正在推出此类样本脚本。“
Linux 内核 icmp.c 文件的修复方案目前向计数器 (‘credit’) 分配了一个随机化值,但全球 Linux 服务器要用上尚需时日。
Maxwell 并未推荐完全拦截 ICMP 流量,因为该协议具有合法的用例如 IPv6 分段。Maxwell 指出,“如果DNS服务器完全拦截 ICMP,那么如果在它和其它服务器之间存在跳转(MTU更小,拦截 ICMP 引发 PMTUD 黑洞),时区转换将失败。
这种侧信道攻击的发现为互联网工程师提升 DNS 的安全性又增加了负担。DNS 已经是将速度置于性能和安全之上的相对不安全的协议。即使构建了增强措施如 DNS-over-HTTPS (DoH),也无法阻止攻击者滥用 DNS 实施恶意活动。
推荐阅读
谷歌:注意 Linux 内核中严重的零点击 “BleedingTooth” 蓝牙缺陷
比 Windows DNS 蠕虫漏洞更严重!SharePoint 反序列化RCE漏洞详情已发布,速修复
原文链接
https://www.bleepingcomputer.com/news/security/dns-cache-poisoning-attacks-return-due-to-linux-weakness/
题图:Pixabay License
本文由奇安信代码卫士编译,不代表奇安信观点。转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。
奇安信代码卫士 (codesafe)
国内首个专注于软件开发安全的
产品线。
觉得不错,就点个 “在看” 吧~