首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >问答首页 >无MITM局域网中的DNS缓存中毒

无MITM局域网中的DNS缓存中毒
EN

Security用户
提问于 2014-02-12 21:17:53
回答 2查看 3.1K关注 0票数 4

关于DNS缓存中毒(又名Kaminsky攻击),已经有人问过许多问题,但我没有找到一个明确的答案:

是否可能在局域网中造成DNS缓存中毒,而不执行MITM攻击?

澄清:

正常情况下,在MITM攻击期间DNS缓存中毒是可能的。

然而,我没有看到很多主题围绕着缓存毒害LAN的技术,而不执行MITM攻击(比如Kaminsky攻击)。我认为这应该是可能的,因为所有DNS请求/答复都是纯http,未加密。因此,我们应该能够看到请求(包括事务ID和确切端口),并在“好的”DNS服务器能够回答请求之前准备一个假答案。攻击者与目标位于同一个LAN上,因此响应速度将比局域网外的另一个DNS服务器快得多。

这样的攻击有可能吗?我知道在MITM攻击期间更容易执行DNS欺骗,我只想知道是否可以在不执行MITM攻击的情况下通过赢得DNS响应竞赛而在LAN上缓存有毒客户端。

注:这不是关于如何防止Kaminsky攻击的问题(事务ID和端口随机化)。

EN

回答 2

Security用户

回答已采纳

发布于 2014-02-12 21:32:21

是的,这是可能的,虽然更好的攻击也是可用的。

DNS缓存中毒通过多种方法是可能的,Kaminsky攻击只是其中之一。卡明斯基攻击之所以引起如此大的兴趣,是因为你不需要在同一个局域网上。你可以攻击绕地球一半的DNS服务器。

众所周知,您可以在同一个LAN中篡改与您自己相同的通信量--除非该流量受到加密的保护。大多数工具(如Android网络欺骗器)使用ARP中毒与DNS中毒相结合,因为这是最可靠的方法。原则上,您可以在不使用MITM的情况下进行DNS中毒,正如您建议的那样,但是由于您依赖的是竞争条件,所以不太可靠。

这就是为什么你没有看到太多关于你提议的攻击的讨论。在任何实际情况下,你都有更好的选择。

票数 2
EN

Security用户

发布于 2014-02-12 21:39:52

DNS请求和答复不是HTTP;它们是.DNS。见标准。大多数情况下,DNS请求和响应使用UDP:请求是单个IP数据包,响应也是如此。

在UDP中,每个数据包通过以下方式标识:

  • 源IP地址
  • 目标IP地址
  • 源端口
  • 目的端口

从客户端C到DNS服务器S的DNS请求将以C的IP地址为源,S的IP地址为目的地,随机端口值p为源端口,53为目的端口( DNS服务器的标准端口值)。DNS响应将以C的IP地址为目标,S的IP地址为源,53为源端口,p为目的端口。客户端将接受响应为“正确”,因为它使用p作为目标端口,与客户机用作请求源的p相同。

希望向客户端C提供假DNS信息的攻击者可以知道C的IP地址和S的IP地址,并且可以很好地猜测客户端发送请求的时间。攻击者的目标是发送假DNS响应,声称来自DNS服务器S,但包含。如果没有完全的窃听访问,攻击者就无法知道p的值,因为他看不到数据包。然而,端口号在一个有限的范围内(端口号从0到65535,但是随机分配的数字的实际范围更小,并且取决于所涉及的操作系统)。因此,攻击者可能只为所有可能的端口p值发送数千个伪造IP数据包,每个数据包都包含假信息。除了使用正确的p值的客户端之外,客户端将删除所有这些数据。

同样的概念也可以扩展到DNS服务器之间的通信,因为它们相互通信,以及缓存响应。对于攻击者来说,通常更容易成功,因为他可以触发DNS到DNS的交换,从而为他启动数千个欺骗响应提供了一个精确的时间。当他成功地向DNS服务器提供假信息时,该DNS服务器就被称为毒死

即使对于没有窃听能力的低技术攻击者来说,这类事情也相对容易,更不用说拦截能力了,就像客户端和它的DNS服务器之间或DNS服务器之间真正的MitM所需要的那样。让它变得容易的原因是UDP的使用,这意味着攻击者知道除随机源端口之外的一切,该端口生活在一个很小的范围内。如果两台DNS服务器通过TCP相互通信,那么攻击就会更加困难,因为在TCP流中注入假数据意味着猜测连接序列号,这些序列号是在32位范围内随机选择的:“数千个数据包”已经变成了“数十亿个数据包”。

票数 5
EN
页面原文内容由Security提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://security.stackexchange.com/questions/51413

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档