☰

为什么欺骗的 DNS 数据包会被忽略？

tag-icon • tag-icon networking macos dns spoofing
为什么欺骗的 DNS 数据包会被忽略？

首先，让我澄清一下，这个问题涉及一个仅用于教育目的的私人项目。

我尝试编写自己的“DNS欺骗器”。别担心，这个问题与任何编码实践无关。

当前设置

操作机器是本地网络中的 MacBook（装有 OSX）（因此还有一些其他不重要的设备）。有一个基本路由器，它使用另一台机器（也在本地网络中）作为本地 DNS 服务器。虽然这种设置有点不寻常，但它不应该是导致问题（如下面所描述的）。

目标

DNS 欺骗 - 当 MacBook 发送 DNS 请求时，发送带有虚假 IP 地址的答复。

我目前的方法

我使用 BPF (伯克利包过滤器）获取数据链路层的原始访问权限。

现在，我正在监听/捕获 MacBook 以太网网络接口上的任何查询（在下文中称为“MB”）。

我在 MB 上禁用了 IPv6。

我使用以下命令删除 MB 上的 DNS 缓存：

sudo killall -HUP mDNSResponder;sudo killall mDNSResponderHelper;sudo dscacheutil -flushcache

程序

  1. MB 发送带有一些查询的 DNS 请求
  2. 我创建一个 DNS 响应，其中包含对所有 A 类 (IPv4) 查询的相同查询和答案，并发送此响应
  3. MB 收到两个响应：首先是我的虚假响应，然后是真正的本地 DNS 服务器发送的真实响应

每个伪造的 DNS 响应数据包将包括：

  • 请求的 DNS 服务器的以太网 MAC 地址作为以太网源地址
  • 请求的 DNS 服务器的 IP 地址作为 IP 源地址
  • 端口 53 作为源端口
  • DNS 请求源自的端口作为目标端口
  • 正确的 IP 报头校验和
  • 正确的 UDP 校验和
  • 正确的帧校验序列/以太网校验和。

每个 DNS 响应都通过我正在监听的同一网络接口发送。

每当发送查询时，都会有两个响应：

  1. “DNS欺骗器”立即发送的第一个数据包（即“假”数据包/DNS响应）在第二个数据包到达之前到达
  2. 第二个是“真实”的 DNS 响应，由本地 DNS 服务器发送。

我也假定（尽管我不确定这一点）OSX 总是选择它获得的第一个 DNS 响应来将域名解析为其 IP 地址。

总结一下，除了校验和以及 DNS 应答 IP 地址不同之外，两个 DNS 响应是相同的。此外，“真实”DNS 服务器不会发送（无论出于什么原因）FCS（帧校验序列）。我会发送，尽管它没有计算出来，只是设置为零（清零）。

问题

OSX 似乎忽略虚假的 DNS 响应。也可能是操作系统负担过重；使用 Safari 打开网站时的行为如下：

使用 Safari 并输入“http://some-url.com”进入地址栏，什么都没有发生。它既没有连接到真正的网站，也没有连接到虚假的页面。页面似乎永远加载。有时，十年后，它才连接到真正的页面。

示例（使用Wireshark）

一个随机的例子。

Request: 
0000   b8 27 eb b9 a0 0f a0 ce c8 10 75 8c 08 00 45 00   
0010   00 33 74 2c 00 00 ff 11 62 06 c0 a8 b2 1f c0 a8   .3t,..ÿ.b.À¨².À¨
0020   b2 16 f2 7e 00 35 00 1f 49 71 67 00 01 00 00 01   ².ò~.5..Iqg.....
0030   00 00 00 00 00 00 01 32 03 63 6f 6d 00 00 01 00   .......2.com....
0040   01                                                .



Fake Response:
0000   a0 ce c8 10 75 8c b8 27 eb b9 a0 0f 08 00 45 00   
0010   00 43 12 34 00 00 40 11 82 ef c0 a8 b2 16 c0 a8   .C.4..@..ïÀ¨².À¨
0020   b2 1f 00 35 f2 7e 00 2f 46 44 67 00 81 80 00 01   ²..5ò~./FDg.....
0030   00 01 00 00 00 00 01 32 03 63 6f 6d 00 00 01 00   .......2.com....
0040   01 c0 0c 00 01 00 01 00 00 07 08 00 04 ac d9 17   .À...........¬Ù.
0050   8e 22 4f 80 1c                                    ."O..



Real Response:
0000   a0 ce c8 10 75 8c b8 27 eb b9 a0 0f 08 00 45 00   
0010   00 7c 9c 19 40 00 40 11 b8 d0 c0 a8 b2 16 c0 a8   .|..@.@.¸ÐÀ¨².À¨
0020   b2 1f 00 35 f2 7e 00 68 83 00 67 00 81 83 00 01   ²..5ò~.h..g.....
0030   00 00 00 01 00 00 01 32 03 63 6f 6d 00 00 01 00   .......2.com....
0040   01 c0 0e 00 06 00 01 00 00 03 84 00 3d 01 61 0c   .À..........=.a.
0050   67 74 6c 64 2d 73 65 72 76 65 72 73 03 6e 65 74   gtld-servers.net
0060   00 05 6e 73 74 6c 64 0c 76 65 72 69 73 69 67 6e   ..nstld.verisign
0070   2d 67 72 73 c0 0e 5c 83 f7 73 00 00 07 08 00 00   -grsÀ.\.÷s......
0080   03 84 00 09 3a 80 00 01 51 80                     ....:...Q.

1] 2]

任何帮助高度非常感谢。如果您需要更多详细信息，请告诉我。如果您想要赏金，请告诉我。

答案1

首先，以太网帧在线路上始终具有 FCS，但是并非所有以太网 NIC 在将接收到的帧传递到主机时都会保持 FCS 连接，这意味着您的嗅探器无法始终看到 FCS 或知道它是否有效或无效。

因此您需要正确获取您的FCS。

如果您不确定注入器/欺骗器设备平台上的 BPF 版本、其 NIC 驱动程序或硬件是否会为您计算正确的 FCS（如果省略它或用零填充它），那么您可能必须先弄清楚。我猜如果您尝试注入未正确设置的数据包，它不会为您修复它，因此您可能需要自己计算它并在执行 bpf_write() 之前在数据包缓冲区的末尾插入正确的值。

其次，我只是目测你的十六进制转储，但如果我正确地解码，你的 DiffServ 字段看起来是假的。如果你不知道如何处理它，请将其默认为 0x00 而不是 0xff。

第三，您的 IP 总长度字段看起来是假的（零）。您可能需要计算并正确设置它。在计算校验和之前，请务必这样做。

我没有发现其他问题。所以如果我是你，我会解决这三个问题，然后再试一次。

相关内容