ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

WPA-PSK四次握手与离线字典攻击实验:从抓包到口令验证

WPA-PSK四次握手与离线字典攻击实验:从抓包到口令验证 简介这份资源是电子科技大学网络安全协议课程的WPA-PSK口令攻击实验报告面向学习无线网络安全、需要完成同类实验的高校学生与安全入门者。报告围绕WLAN工作原理、RSN密钥层次与四次握手原理展开完整记录了配置无线攻击环境、抓取握手包、编写程序破解口令的全过程并附有beacon帧、Probe response、四次握手各消息及MIC计算字段的抓包分析。资源包共1个docx文件约176KB内容涵盖实验目的、原理、器材、步骤与结果验证结构完整。目前已有1475人学习下载适合作为无线安全实验的参考模板帮助读者理解PMK、PTK推导与MIC校验逻辑掌握从数据包分析到口令还原的完整思路也可用于对照排查抓包与破解环节的常见问题。1. WPA-PSK 口令实验到底在验证什么从四次握手到离线字典攻击很多人第一次接触 WPA-PSK 口令实验以为就是跑个工具抓包然后等结果。实际动手才发现抓包容易抓到有效握手包难抓到之后跑不出结果更让人抓狂。这个实验的核心不是“破解”而是理解 WPA-PSK 认证过程中四次握手暴露出的安全边界——口令强度决定了整个无线网络的抗攻击能力。电子科技大学网络安全协议课程里的这个实验本质是让你亲手复现一条完整的攻击链监听无线信道、捕获 WPA 四次握手报文、提取 PMK 派生所需的参数、用字典做离线比对。做完这个实验你会真正理解为什么 WPA-PSK 的安全性完全押注在口令熵上也会明白为什么企业级网络要上 802.1X 而不是共享一个预共享密钥。适合正在学网络安全协议、准备无线安全方向实验报告、或者想搞清楚 WPA-PSK 认证流程的从业者。2. WPA-PSK 四次握手与离线攻击的完整链路2.1 四次握手到底交换了什么WPA-PSK 认证的核心是四次握手4-Way Handshake它的目的是在客户端和 AP 之间派生出一组会话密钥用于后续数据加密。整个过程建立在双方都知道 PMKPairwise Master Key的前提上。PMK 的推导公式是PMK PBKDF2(HMAC-SHA1, Passphrase, SSID, 4096, 256)这里 Passphrase 就是无线密码SSID 是网络名称4096 是迭代次数256 是输出位数。注意 SSID 参与了 PMK 的计算——这意味着同一个密码在不同 SSID 下产生的 PMK 完全不同。很多人做实验时换了 SSID 却忘了重新计算结果一直对不上这是血泪经验。四次握手的报文交换流程报文方向内容关键参数Message 1AP → STAANonceAP 生成的随机数Message 2STA → APSNonce MIC客户端随机数 消息完整性码Message 3AP → STAANonce MIC 加密的 GTK确认密钥 组密钥Message 4STA → APMIC最终确认PTKPairwise Transient Key由 PMK、ANonce、SNonce、AP MAC、STA MAC 拼接后经伪随机函数派生。攻击者抓到 Message 1 和 Message 2或 Message 3 和 Message 4就拥有了计算 PTK 所需的全部公开参数唯一缺的就是 PMK——而 PMK 由口令决定。这就是离线字典攻击的立足点攻击者不需要与 AP 交互本地对字典中每个候选口令计算 PMK → PTK → MIC与抓到的 MIC 比对。匹配成功即口令正确。2.2 实验环境搭建与网卡选型做这个实验第一个翻车点就是网卡。不是所有无线网卡都支持监听模式和注入功能。常见做法是选支持 monitor mode 和 packet injection 的芯片比如 Atheros AR9271、Ralink RT3070、Realtek RTL8812AU 这几款。Intel 内置网卡基本不支持注入别浪费时间。在 Kali Linux 下检查网卡是否支持# 查看无线网卡列表 iwconfig # 查看网卡支持的接口模式 iw list | grep -A 8 Supported interface modes # 如果输出中有 MONITOR 和 PACKET_INJECTION 相关标记说明可用确认支持后将网卡切换到监听模式# 关闭可能干扰的网络管理进程 sudo airmon-ng check kill # 开启监听模式wlan0 替换为实际网卡名 sudo airmon-ng start wlan0 # 确认监听接口已创建通常为 wlan0mon iwconfig参数说明airmon-ng check kill会杀掉 NetworkManager、wpa_supplicant 等可能干扰的进程。如果跳过这步后续抓包经常出现信道跳变或抓不到管理帧的情况。airmon-ng start创建的监听接口名称取决于驱动有的显示为 wlan0mon有的直接复用 wlan0。2.3 捕获四次握手报文抓包分两步先扫描目标 AP 的信息再针对特定信道抓取握手包。# 扫描周围 AP记录目标 AP 的 BSSID 和信道 sudo airodump-ng wlan0mon # 锁定目标 AP 抓包-c 指定信道--bssid 指定 AP MAC-w 指定输出文件前缀 sudo airodump-ng -c 6 --bssid AA:BB:CC:DD:EE:FF -w capture wlan0mon此时如果正好有客户端连接或重连就能抓到四次握手。但现实中不可能一直等所以需要主动触发。常见做法是发送去认证帧强制客户端重新连接# 向目标 AP 下的某个客户端发送去认证帧-0 表示去认证攻击2 表示发送 2 个帧 sudo aireplay-ng -0 2 -a AA:BB:CC:DD:EE:FF -c 11:22:33:44:55:66 wlan0mon参数说明-0 2中的 2 是发送去认证帧的数量发太多容易引起注意且没必要。-a后跟 AP 的 BSSID-c后跟客户端的 MAC。如果不指定-c则向所有客户端广播去认证帧。抓到握手后airodump-ng 界面右上角会显示 “WPA handshake: AA:BB:CC:DD:EE:FF”。此时可以停止抓包用aircrack-ng验证握手包是否完整# 检查抓包文件中是否包含完整的四次握手 aircrack-ng capture-01.cap如果输出中显示 “1 handshake”说明握手包可用。如果显示 “0 handshakes”说明抓到的报文不完整需要重新抓。2.4 用字典做离线口令比对握手包到手后接下来就是离线计算。aircrack-ng 自带字典攻击功能# 使用字典文件对抓包文件进行 WPA-PSK 口令比对 aircrack-ng -w /usr/share/wordlists/rockyou.txt -b AA:BB:CC:DD:EE:FF capture-01.cap参数说明-w指定字典路径-b指定目标 AP 的 BSSID当抓包文件中有多个 AP 的握手时需要指定。aircrack-ng 会自动从握手包中提取 SSID、ANonce、SNonce、MAC 地址和 MIC然后对字典中每个口令计算 PMK → PTK → MIC 并比对。如果想用 GPU 加速可以用 hashcat。首先需要把 cap 文件转成 hashcat 能识别的 hccapx 格式# 将 cap 文件转换为 hccapx 格式 cap2hccapx capture-01.cap capture.hccapx # 使用 hashcat 进行字典攻击-m 2500 表示 WPA-PSK 模式 hashcat -m 2500 -a 0 capture.hccapx /usr/share/wordlists/rockyou.txt参数说明-m 2500是 hashcat 中 WPA-PSK 的哈希模式编号-a 0表示字典攻击模式。GPU 跑 WPA-PSK 的速度远超 CPU一张中端显卡每秒能算几十万个候选口令而 CPU 通常只有几千。做实验时如果字典较大建议用 hashcat。3. 实验中的参数陷阱与性能调优3.1 信道与频段对抓包成功率的影响2.4GHz 和 5GHz 频段的抓包策略完全不同。2.4GHz 只有 14 个信道且互相重叠airodump-ng 默认会跳信道扫描但锁定目标后必须用-c参数固定信道否则会漏掉握手报文。5GHz 频段信道多且不重叠但需要网卡支持 802.11a/n/ac 才能监听。另一个容易忽略的点是信道宽度。如果 AP 使用了 40MHz 或 80MHz 频宽而网卡只监听 20MHz可能抓不到完整的握手帧。检查方式# 查看 AP 的信道宽度信息 sudo iw dev wlan0mon scan | grep -E DS Parameter set|HT operation|VHT operation如果发现 AP 使用了 HT40 或 VHT80需要确认网卡监听模式是否覆盖了对应频宽。部分驱动在监听模式下会自动降为 20MHz导致抓包不全。3.2 PMK 计算中的 SSID 隐藏问题如果目标 AP 隐藏了 SSID抓包文件中不会直接包含 SSID 字段。但 PMK 计算必须用到 SSID没有它就无法验证口令。解决办法是从握手报文中提取 SSID——即使 AP 不广播 SSID在客户端关联请求和握手报文中仍然会携带 SSID 信息。用 tshark 从抓包文件中提取 SSID# 从 cap 文件中提取 SSID包括隐藏 SSID 的探测响应 tshark -r capture-01.cap -Y wlan.ssid -T fields -e wlan.ssid | sort -u如果提取不到可以尝试从客户端探测请求中获取# 提取客户端探测请求中的 SSID tshark -r capture-01.cap -Y wlan.fc.type_subtype 0x04 -T fields -e wlan.ssid | sort -u参数说明-Y是显示过滤器wlan.fc.type_subtype 0x04表示探测请求帧。隐藏 SSID 的 AP 虽然不广播但客户端在连接时会主动发送探测请求其中包含 SSID 明文。3.3 字典质量决定实验成败离线攻击的速度再快字典里没有正确口令也是白搭。做实验时老师通常会提供一个包含正确口令的字典但实际场景中字典的选择直接决定攻击是否可行。常见字典来源和适用场景字典名称大小适用场景命中率特点rockyou.txt约 130MB通用弱口令对简单密码命中率高8位纯数字约 800MB手机号/生日针对特定人群有效常见 WiFi 密码字典约 50MB国内场景包含常见拼音组合自定义规则生成可变针对性攻击依赖信息收集质量用 hashcat 的规则引擎可以基于基础字典生成变体# 使用 best64 规则对基础字典进行变形 hashcat -m 2500 -a 0 capture.hccapx base_wordlist.txt -r /usr/share/hashcat/rules/best64.rule参数说明-r指定规则文件best64.rule 包含 64 条常见变形规则大小写转换、追加数字、替换字符等。规则攻击可以在不增加字典体积的情况下大幅提升命中率。4. 避坑与常见问题排查4.1 抓到握手包但 aircrack-ng 显示 0 handshakes现象airodump-ng 界面提示抓到了 WPA handshake但用 aircrack-ng 检查时显示 “0 handshakes”。原因最常见的原因是抓包文件中只包含四次握手的一部分报文。WPA 四次握手需要至少抓到 Message 1 Message 2 或 Message 2 Message 3 才能计算出 MIC。如果只抓到了 Message 1 和 Message 3缺少 SNonce 或 MIC就无法完成验证。解决重新触发握手确保抓包过程中客户端完整走完四次握手。可以增加去认证帧的发送次数或者等待客户端自然重连。用 tshark 检查抓包文件中的 EAPOL 报文数量# 统计抓包文件中的 EAPOL 报文 tshark -r capture-01.cap -Y eapol -T fields -e frame.number -e eapol.type如果 EAPOL 报文少于 4 个说明握手不完整。4.2 hashcat 报错 “No hashes loaded”现象hashcat 运行时提示 “No hashes loaded” 或 “Token length exception”。原因hccapx 文件格式不正确或者 cap 文件转 hccapx 时出错。常见于 cap 文件中包含多个 AP 的握手转换工具无法确定使用哪一个。解决先用 aircrack-ng 确认 cap 文件中包含有效的握手然后用 cap2hccapx 时指定 BSSID# 转换时指定目标 BSSID cap2hccapx capture-01.cap capture.hccapx AA:BB:CC:DD:EE:FF如果仍然报错尝试用 wpaclean 清理 cap 文件中的冗余报文# 清理 cap 文件只保留握手相关报文 wpaclean cleaned.cap capture-01.cap4.3 网卡在监听模式下无法注入去认证帧现象aireplay-ng 发送去认证帧时提示 “No such device” 或注入失败。原因部分网卡驱动在监听模式下不支持注入或者监听接口名称与注入接口不一致。另外如果网卡被 NetworkManager 接管也会导致注入失败。解决确认网卡支持注入检查监听接口状态# 查看接口状态 iwconfig wlan0mon # 测试注入功能 sudo aireplay-ng --test wlan0mon如果测试失败尝试更换网卡或使用外置 USB 无线网卡。另外确认airmon-ng check kill已执行NetworkManager 不会干扰监听接口。4.4 PMK 计算正确但 MIC 比对失败现象明明口令正确但 aircrack-ng 或 hashcat 就是跑不出来。原因SSID 不匹配是最常见的原因。如果抓包时 AP 隐藏了 SSID或者抓包文件中包含多个 SSID 的报文工具可能提取了错误的 SSID 参与 PMK 计算。另一个原因是抓包文件中的 MAC 地址顺序问题——PTK 计算中 AP MAC 和 STA MAC 的顺序不能颠倒。解决手动确认 SSID 和 MAC 地址# 提取抓包文件中的 SSID 和 MAC 地址 tshark -r capture-01.cap -Y wlan.fc.type_subtype 0x08 -T fields -e wlan.ssid -e wlan.ra -e wlan.ta参数说明wlan.fc.type_subtype 0x08表示信标帧wlan.ra是接收地址wlan.ta是发送地址。确认 SSID 与目标一致AP MAC 和 STA MAC 的顺序正确。4.5 实验环境中的信道干扰导致抓包不稳定现象airodump-ng 抓包时频繁跳信道或者抓到的报文大量丢失。原因2.4GHz 频段拥挤周围 AP 多导致信道干扰严重。另外如果监听接口同时被其他进程使用也会导致抓包不稳定。解决锁定目标信道后关闭信道扫描使用-c参数固定信道。同时确认没有其他进程占用监听接口# 查看监听接口是否被占用 sudo lsof | grep wlan0mon # 如果被占用杀掉相关进程 sudo airmon-ng check kill如果干扰仍然严重尝试在夜间或无线环境较干净的地方做实验。5GHz 频段干扰少但需要网卡支持。5. 从实验到实战WPA-PSK 安全性验证的进阶思路做完基础的口令比对实验后可以进一步验证 WPA-PSK 的安全边界。一个值得做的进阶练习是自己搭建一个 WPA-PSK 的 AP设置不同强度的口令然后用相同的字典跑一遍记录命中时间。这样能直观感受到口令熵对攻击成本的影响。搭建测试 AP 可以用 hostapd# hostapd 最小配置文件示例 cat /tmp/hostapd.conf EOF interfacewlan1 drivernl80211 ssidTestWPA hw_modeg channel6 wpa2 wpa_passphrase12345678 wpa_key_mgmtWPA-PSK rsn_pairwiseCCMP EOF # 启动 hostapd sudo hostapd /tmp/hostapd.conf参数说明wpa_passphrase是预共享密钥最少 8 位最多 63 位。wpa_key_mgmtWPA-PSK指定使用预共享密钥模式。rsn_pairwiseCCMP指定使用 AES-CCMP 加密。用这个测试 AP 抓一次握手然后分别用包含正确口令和不包含正确口令的字典跑一遍记录时间差异。你会发现8 位纯数字口令在 GPU 面前几乎瞬间被攻破而 12 位以上包含大小写字母、数字和符号的口令即使字典中有正确口令跑完整个字典也需要相当长的时间。另一个进阶方向是验证 WPA3 的 SAE 握手对离线攻击的抵抗能力。WPA3 的 Dragonfly 握手在设计上就是为了防止离线字典攻击——每次握手都涉及交互式的密码认证攻击者无法仅凭抓包就离线计算。如果有支持 WPA3 的路由器和网卡可以对比 WPA2 和 WPA3 在相同口令强度下的抗攻击表现。我自己做这个实验最大的教训是不要迷信工具的输出。aircrack-ng 显示 “0 handshakes” 不代表真的没抓到可能是抓包文件格式问题hashcat 跑不出结果也不代表口令不在字典里可能是 SSID 或 MAC 地址提取错误。每次遇到问题先用 tshark 把抓包文件里的 EAPOL 报文和 SSID 信息手动确认一遍比反复重抓效率高得多。希望帮到你。本文还有配套的精品资源点击获取
返回列表