所以我一直在寻找WPA和4次握手机制，试图集体讨论创建一个带有WPA加密的假AP的可能性，这一选择似乎在airbase-ng中缺失。 到目前为止，我的想法是： 我创建了一个带有WPA-PSK加密标志的假AP，并将其ESSID设置为目标AP的ESSID。 通过对连接到目标AP的客户端进行解除认证，正常的反应是在WiFi列表中搜索他们的AP。 他们会尝试使用我试图检索的密码连接到虚拟AP。
根据维基百科的4次握手演示：https://en.wikipedia.org/wiki/IEEE_802.11i-2004#Protocol_operation 从不在AP和站（客户端）之间动态共享PTK;相反，MIC被比较。 在数据包2/4中，电台发送其用MIC签名的SNonce。 在接收到这个数据包之后，虚拟AP将跳过构建PTK，并且只发送带有随机分配的GTK和MIC的数据包3/4（我不确定该MIC是否经过客户端验证）。
所以我的问题是： 客户端是否从握手的第3个数据包中验证MIC？ 如果它没有，这是否意味着客户端已成功通过身份验证并连接到AP？
进一步的想法： 在没有AP侧PTK的情况下，我是否可以将原始未加密数据包发送到客户端以进行DNS欺骗？ 如果原始数据包未被客户端接受，那么Hole196漏洞（此处记录为http://www.airtightnetworks.com/WPA2-Hole196）是否可以用于DNS欺骗，因为伪造的AP知道GTK？
我希望你能解决我的问题;如果您需要进一步澄清，我很乐意回复。
答案 0 :(得分：1)
好的，我已经阅读了IEEE Std 802.11-2012文档，并得出结论，由于以下原因，我的概念无效且不可行：
在IEEE Std的 11.6.2 部分，第1249页的底部，出现以下声明：
如果KeyKey或SMK KDE包含在Key Data字段中，但Key Data字段不包含 加密后，EAPOL-Key帧将被忽略。
这排除了向请求者（客户端）发送未加密的GTK的选项，知道由于虚假AP无法生成实际的客户端，因此无法向请求者发送加密的GTK。 -sided）在四次握手的第3条EAPOL消息中加密密钥数据（包括GTK）所需的PTK。
WPA2 CCMP中密钥数据字段的加密通常通过IEFT RFC 3394 中记录的NIST AES密钥包装算法实现。
我认为GTK可以被发送给未加密的请求者（在我到达IEEE Std的那一部分之前）也最终导致完全失败;第1259页的IEEE Std 802.11-2012第11.6.6.4节对此进行了进一步说明：
在接收消息3，...时，请求者也是：
...
b）验证消息3 MIC。如果计算出的MIC与认证者的MIC不匹配 包含在EAPOL-Key框架中，Supplicant默默地丢弃消息3。
同样，由于假AP无法生成有效的PTK，因此无法计算消息3的有效MIC，从而导致丢弃消息和操作失败。