我在 802.11ac 5GHz 频谱的第 36 信道上的单个信道上,在监控模式下使用 Wireshark 在 3 小时内捕获了 250 万个数据包。
我在 Wireshark 中打开 Statistics > Conversations,查看所有通过 Wi-Fi 相互通信的 MAC 地址。我随后将 Wireshark 提供的“Conversations”列表保存为 Google Sheet,共享如下,以供参考和分析。
https://docs.google.com/spreadsheets/d/1RE72s7DYXDhRdMopXQ9zIqNkww6OhzUeZbLeQvYqpPc/edit?usp=sharing
我在 Android 上的 Wi-Fi 管理应用程序的“我附近的设备”扫描期间看到的有效设备列在“Device_Validity”表中。在主要对话表中同样是绿色的。然而,只有前 1000 行(共 169,242 行)以任何方式进行了格式化,以保持合理的性能。
现在问题来了:我在 Wireshark 日志中看到了我的设备和邻居设备的 MAC 地址的几个变异版本。
通过突变,我的意思是如果18:56:80:7e:0d:c9
是一个有效的 MAC 地址,那么我在 Wireshark 中观察到的数据包的源/目标或发送器/接收器地址中看到以下变体:
18:56:80:7e:0d: 49 - 只有最后 1 或 2 个八位字节被更改。如果设备有多个网络接口且 MAC 地址略有修改,这可能是有效的。
19 :56:80:7e:0d:c9 - 前 N 个八位字节已更改。当数据包通过范围扩展器时可能会发生这种情况。尽管 AFAIK 通常更改3个八位字节,而不仅仅是 1 个。
看似随机的原始MAC地址突变如下:
18:56:80:7e:0d: a9
18:56:80:7e:0d: 29 - 一个设备可以有多少个接口?
18:56:80:7e: 4d:76
18:56:80:7e: 6d:39
18:56:80:7e: ad:05 - 附近是否有这么多来自同一制造商的其他设备,不知何故被遗漏了在我上面提到的“靠近我的设备”扫描期间?有可能,但不太可能
00 :56:80:7e:0d:c9 - 前缀更改了两次,一次更改为 19:56,一次更改为 00:56。有多少增程器?再一次,只改变第一个八位字节?
02 :56:80:7e:0d:c9 - 前缀再次更改。
02 :56:80:7e: ad:2b - 两端改变了 3 个八位字节。
98:6f :80:7e:0d: 05 - 两端改变了 3 个八位字节。
01:18:56:80:7e:0d - 所有八位字节向右移动,并在左侧填充01。
4b:27 :80:7e:0d: 63 - 另一个多重替换。
18:56:80:7e: b9:c4 -还有很多很多
我通过在 Google 表格中对八位字节子字符串进行简单搜索,发现了上述 14 个突变80:7e
,并且只查看了它出现的 7354 个结果中的 55 个。只需搜索有效 MAC 地址的不同八位字节子串,或检查更多搜索结果,就可以找到更多突变。
此外,如果您按“未解析地址”列之一对提供的 Google 表格进行排序,并分析任何有效 MAC 的邻域,您将看到地址不断变化,直到几乎所有八位字节都不同。
这仅适用于一台设备。在多个设备上发现了类似的突变,这些设备既属于我自己的,也属于我邻居的。下面是一组示例:
5c:f9:38:a7:d9:32 - 原始
d0 :f9:38:a7:d9:32
32 :f9:38:a7:d9:32
30:fa:38:a7:d9:32
fe :f9: 38:a7:d9:32
5e :f9:38:a7:d9: 5a
00:5c:f9:38:a7:d9 - 右移并添加前缀
f9:38:a7:d9:32:98 - 左移并添加后缀
59 :f9:38:a7:d9: f2 - and a d9: b2
5c:f9:38:a7: 71:2d - 不存在的设备
5c:f9:38:a7: 41:45 - 不存在的设备
和还有很多
这些是我为我的显示器范围内的十几台设备中的两个设备编目的模式。对于工作表 Device_Validity 选项卡中的任何设备,通过在 Conversations 选项卡中搜索特定的八位字节子字符串,可以轻松观察到这些移位/掩码模式。
网络流量模式:
这些移动或屏蔽的 MAC 地址不参与信标请求/响应、身份验证/取消帧等,或其他您期望新设备甚至“攻击者”设备不断弹出或消失的地方。相反,它们通常会突然在有效流量中间发送/接收随机 RTS/CTS、块确认、空函数和波束成形(VHT/HE NDP 公告帧)的一次性数据包。我再说一遍,只有一次性的框架,而不是整个对话。
最终导致数以万计的一次性变异 MAC 地址,与有效设备或其他变异 MAC 地址交换一次性数据包。
鉴于以上所有证据,
有效设备的这么多 _mutated_ MAC 地址最有可能的来源是什么
请注意,我们最终会在一个区域中获得数万个 MAC 地址,这些地址是从物理上存在于无线邻域中的大约十几个有效 MAC 地址变异而来的。设备的数量由前面提到的“我附近的设备”扫描验证(这些扫描查找附近的关联和非关联设备)。
可能的理论:
- 高概率- 数据包错误 - 由于某种原因未在 Wireshark 中标记为错误。为什么他们甚至出现在 Wireshark 中?为什么他们不被网卡/操作系统拒绝?(特别是 2013 年年中 MacBook Air 上的 macOS 10.14.5)
- 低概率- 恶意行为者 - 他们可以通过注入信标帧、RTS/CTS 等实现什么?此外,似乎需要付出大量努力才能实现……究竟是什么?
- 还有什么?
这些都是错误。您处于监控模式的 802.11 WNIC 正在尽最大努力接收和报告它在您设置的信道上可以看到的每一帧,但是由于无线介质的不可靠性,总会有很多数据包它可以看到 SNR 在哪里不够强大,无法正确接收和解码每一位。
它们不会被拒绝,因为您已将 WNIC 置于 802.11 监控模式,而监控模式通常被 802.11 工程师用来调试 802.11 问题,包括数据包错误问题,因此工程师希望能够看到错误而不是拥有他们自动被 WNIC 拒绝。
它们没有被 Wireshark 标记,因为处理 FCS 错误一直是 NIC 和嗅探器的一大难题(这可以追溯到有线以太网的早期,所以它早于 802.11)。一些 NIC 能够将 FCS 失败的帧向上传递给主机,而另一些则不能。一些 NIC 能够在它们传递给主机的数据包中包含 FCS,而有些则不能。从来没有一个好的方法可以让嗅探器自动找出它正在处理的是哪种 NIC,因此它不知道是否期望看到 FCS 或坏帧。
所以 Wireshark,我记得,默认为假设帧没有附加 FCSes 的安全位置,所以它不执行 FCS 验证检查,所以它不会标记坏帧。Wireshark 有几个设置可以让您控制它如何处理 FCSes。
参见,例如: