1

因此，我一直在研究 WPA 和 4 次握手机制，试图集思广益创建具有 WPA 加密的假 AP 的可能性，airbase-ng 似乎缺少一个选项。到目前为止，这是我的想法：我创建了一个带有 WPA-PSK 加密标志的假 AP，并将其 ESSID 设置为目标 AP 的 ESSID。通过取消对连接到目标 AP 的客户端的身份验证，正常的反应是在 WiFi 列表中搜索他们的 AP。他们会尝试使用我要检索的密码连接到假 AP。

根据此 Wikipedia 演示的 4 次握手：https ://en.wikipedia.org/wiki/IEEE_802.11i-2004#Protocol_operation 在 AP 和站点（客户端）之间永远不会动态共享 PTK；相反，比较 MIC。在数据包 2/4 中，站发送其 SNonce 用 MIC 签名。收到此数据包后，假 AP 将跳过构建 PTK 并仅发送带有随机分配的 GTK 和 MIC 的数据包 3/4（我不确定此 MIC 是否经过客户端验证）。

所以我的问题是：客户端是否从握手的第三个数据包中验证 MIC？如果没有，这是否意味着客户端已成功通过身份验证并连接到 AP？

进一步思考：在没有 AP 端 PTK 的情况下，我是否可以将原始未加密数据包发送到客户端以进行 DNS 欺骗？在客户端不接受原始数据包的情况下，Hole196 漏洞（记录在此：http ://www.airtightnetworks.com/WPA2-Hole196 ）是否可以用于 DNS 欺骗，因为 GTK 是已知的假AP？

我希望你能理解我的问题；如果您需要任何进一步的澄清，我很乐意回复。

4

1 回答 1

1

好的，所以我通读了 IEEE Std 802.11-2012 文档，得出的结论是，我的概念是无效且不可行的，原因如下：
在 IEEE Std 的第11.6.2节中，在第 1249 页的底部，出现以下语句：

如果 GroupKey 或 SMK KDE 包含在 Key Data 字段中，但 Key Data 字段未加密，则应忽略 EAPOL-Key 帧。

这排除了向请求者（客户端）发送未加密 GTK 的选项，因为虚假 AP 无法生成实际（客户端），因此也不可能向请求者发送加密 GTK四次握手的第 3 条 EAPOL 消息中的 Key Data（包括 GTK）加密所需的 PTK。
WPA2 CCMP 中密钥数据字段的加密通常通过IEFT RFC 3394中记录的 NIST AES 密钥包装算法来实现。

我假设 GTK 可以不加密地发送给请求者（在我到达 IEEE 标准的那个部分之前）也以完全失败告终。IEEE Std 802.11-2012 第 1259 页的第 11.6.6.4 节进一步解释了这一点：

在收到消息 3 时，...，请求者还：
...
b) 验证消息 3 MIC。如果计算出的 MIC 与 Authenticator 包含在 EAPOL-Key 帧中的 MIC 不匹配，则请求者静默丢弃消息 3。

再次，由于假AP无法生成有效的PTK，因此无法计算出Message 3的有效MIC，导致消息被丢弃，操作失败。

于 2013-07-31T05:12:11.570 回答