本文原载于我的个人博客： Tsinghua-Secure - 802.1X 并非牢不可破，如需阅读完整内容（包括图片、代码块等），请前往我的博客阅读。
在一段时间之前, Portal 认证方式是 HTTP 的, 没有加密. 加之 Tsinghua 啥的这一坨的网络也是开放的 (Open), 这直接导致了可以 Monitor Mode 侦听直接抓到明文校园网用户名密码.
后来学校强制启用了对登录接口的 HTTP -> HTTPS 跳转, 一定程度上解决了开放 Portal 带来的问题. 但是要想让 Open System 的安全性进一步提高, 看上去 WPA3 OWE 是一个很好的解决方案 (AOSP Docs).
后面就是 Tsinghua-Secure 横空出世了. 作为 802.1X PEAP MSCHAPv2 的企业级热点, 它的安全性比 Portal 模式的好不少. 但是其依然存在不少问题.
802.1X PEAP
首先我们观察 PEAP 架构整体的认证过程:
在 STA 发现 AP 后, 首先以 "Open" 方式进行认证和关联. 之后, AP 向 Client 发起 EAP Authentication Request, 要求给出 Anonymous Identity. 然后, AP 发起 PEAP 请求, 建立 TLS 连接握手, 进入第二阶段.
在第二阶段中, 我们使用了 MSCHAPv2 的方式进行了认证. 若认证成功, 则 TLS Session Key 会进行运算后成为用于握手的 PMK.
在协议中, 客户端会对服务器的 TLS 证书进行验证, 以确保 AP 的真实性. 之后, TLS 握手保证了里面所有内容对窃听者保密. 匿名身份可以不填, 这使得用户名和密码都不会明文传输.在这样的情况下, WPA2-Enterprise 是安全的.
既然说了在这样的情况下, 那么必然有但是了: Tsinghua-Secure 的证书并没有以任何官方的方式传递给用户; 官方的连接教程也引导用户 "不校验证书".
MSCHAPv2
这使得 "伪基站" 的攻击成为了可能: 既然客户端不校验证书, 那么我随便造一个证书, 不就可以欺骗 STA 建立连接, 从而获取 TLS 隧道里面的信息了嘛? 那么 TLS 隧道里面是什么呢? 是 MSCHAPv2 协议. 这是一个 已知的不太安全的协议, Aruba Community. 其可以通过 Challenge 和 Response 解析得到用户密码的 MD4 Hash (此时即可通过此 Hash 进行认证从而仿冒用户的身份), 进而通过字典爆破的方式得到用户的明文密码.
伪基站
从而我们可以通过伪基站的方式, 自己设置一个 AP 和 RADIUS Server, 进而获取 ID 和密码 Hash. 我首先尝试了 hostapd, 通过把它的 Log Level 打到最高并使用-K参数要求其在 log 里面打印密码, 我成功拿到了一些 Hex String 但并不知道如何解析. 我还抓了 802.11 Raw 包, 试图通过已知的 Server Key 解析 TLS 连接, 但是由于 Wireshark 的原生支持太差而倒闭了 (懒, 其实也是因为在搜索的过程中找到了更好的解决方案).
之后我在查如何解析这些 Hex String 的时候找到了 hostapd-wpe 这个仓库, 它完美符合我的想象: 通过 patching hostapd 可以伪造一个 RADIUS server, 其作用就是在用户连接到它的时候把 Challenge 和 Response 给打出来. 不过在编译的时候我遇到了亿点问题, 主要是对openssl-1.0-dev这个老掉牙现在在仓库里找不着了的库的引用导致的. 后来了解到 Kali 源上面有这个玩意的 Binary (不愧是 Kali), 我就小小用了一下. 他还支持另一个很有潜力 (x) 的功能: 它允许在用户给任何密码的时候都接受, 这样就可以监控连进来的用户的流量了.
折腾了半天 (literally), 感觉还行, 故作此 ()
在 Arch 上的安装与调试
Update 2025-02-09: 由于我的笔记本电脑疑似有些太新了 (Ultra 200V), 需要 Linux Kernel 6.12 才能用, 所以我实际使用了 Arch Linux.
Arch Linux 上面的 hostapd-wpe 作为一个 AUR 出现, 但是这个 AUR 安装之后并不像 Arch 一样带有全套的配置, 这些配置啥的需要自己生成. 简单地说:
配置文件 hostapd-wpe.conf
这有一份示例文件:
interface=wlo1 logger_syslog=0 logger_stdout=-1 logger_stdout_level=2 country_code=CN ieee80211d=1 ssid=PKU Secure hw_mode=g channel=11 beacon_int=90 #rts_threshold=2048 #fragm_threshold=2048 supported_rates=10 20 55 110 60 90 120 180 240 360 480 540 basic_rates=20 55 110 preamble=1 wmm_enabled=1 ieee80211n=1 ht_capab=[SHORT-GI-20] require_ht=0 auth_algs=1 ap_isolate=1 ieee8021x=1 eapol_version=1 wpa=2 wpa_key_mgmt=WPA-EAP wpa_pairwise=CCMP rsn_pairwise=CCMP pac_key_lifetime=604800 pac_key_refresh_time=86400 pac_opaque_encr_key=000102030405060708090a0b0c0d0e0f eap_server=1 eap_fast_a_id=8485454491921910bcb70b0a01020000 eap_fast_a_id_info=Huawei eap_fast_prov=3 eap_user_file=eap_user ca_cert=ca.pem server_cert=server.pem private_key=server.prv private_key_passwd=whatever我们需要做的主要是修改这个文件以做到两件事:
其一是让客户端能正常尝试连接以获取 Hash; 这件事较为简单, 这份配置文件就能用.
其二是如何伪装自己使得客户端觉得你比真正的 AP 更好, 而优先选择连接你. 这件事就比较麻烦了, 为了这事我又折腾了半天 (然后还没成功).
在这份配置文件里面 (配置文件的具体格式见 官方文档 ), 我们设置了使用内建的 RADIUS Server, 设置了使用的证书文件 (都是自签名的), 配置了 AP 的信道为 2.4GHz CH11, 把该开的东西都开了. 里面有两行注释掉的内容, 这两个是为了...理论上是在干扰较严重的情况下用短帧提高 Wi-Fi 传输成功率; 但实际上如果压到太低, 会导致 PEAP 握手包 (尤其是 TLS Handshake 里面要传输证书) 被分片, 最后导致 Association Failure.应该限制 A-MPDU 长度来提高成功率.
而客户端常常 Prefer 更高级的热点- 也就是说如果你能用 Wi-Fi 7 发射信号 (打开 HT, VHT, EHT 啥的) 并打开 80MHz 频宽, 那么客户端就很喜欢你 (x). 如果能用 5GHz 频段发射信号, 那就比 2.4GHz 优先级高得多. 因此我尝试在我的电脑上开 5GHz 热点 ~~然后大败而归~~, 这个后面说.
这个文件里面引用了好几个文件.
eap_user
这个文件是用来配置内置 RADIUS Server 的凭据的. 由于 Patch 了这个 Server, 我们只需要一个 Dummy One 就行:
# WPE - DO NOT REMOVE - These entries are specifically in here * PEAP,TTLS,TLS,FAST "t" TTLS-PAP,TTLS-CHAP,TTLS-MSCHAP,MSCHAPV2,MD5,GTC,TTLS,TTLS-MSCHAPV2 "t" [2]允许任何用户用 PEAP 认证, 随便塞点能用的就行.
一堆私钥和证书
使用以下方式来生成这一坨证书:
# 私钥 openssl genpkey -algorithm RSA -out /etc/hostapd/server.prv -aes256 # 服务器证书 openssl req -new -x509 -key /etc/hostapd/server.prv -out /etc/hostapd/server.pem -days 3650 # CA 签名请求 openssl req -new -newkey rsa:2048 -days 3650 -nodes -keyout /etc/hostapd/ca.key -out /etc/hostapd/ca.csr # CA 自签名证书 openssl x509 -req -in /etc/hostapd/ca.csr -signkey /etc/hostapd/ca.key -out /etc/hostapd/ca.pem -days 3650这样就完活了.
5G AP?
这之后我尝试发射 5G 信号, 然后发现所有信道都是No-IR状态, 用不了. 我上网查了半天, 最后决定看来只能先 Patch 一下iwlwifimodule, 把No-IR给删了 ( 比如 这个 Patch ). 在折腾了一番之后完全失败, 即便删掉了 No-IR 还是没法发射信号, 遂暂时作罢, 下单了 MTK 的 USB免驱网卡, 择日再战 (x)
TUNA 的群友对 "有人用过 intel 网卡的热点吗" 评论道:
不存在的, 建议换 mtk
Hostapd 的一些坑
我在调试 hostapd 的时候被坑惨了, 主要原因是 hostapd 的不少设置项的文档都写着
If this field is not included in hostapd.conf, hostapd will not control RTS threshold and 'iwconfig wlan# rts <val>' can be used to set it.
这句话有一个隐含的意思: 如果 hostapd 更改了这个配置, 在停止的时候他不会帮你改回去. 我尝试通过注释掉一些设置来 Debug 的时候, 这个行为实际导致了某个设置项一旦写上去, 那么就半永久地生效了, 注释掉也没用... 直到我打开另一台电脑的 Monitor Mode 抓包看到了异常的 Fragmented Frame 才反应过来.
MSCHAPv2 (2)
UPDATE 2025-02-12:我的新 WiFi 网卡到了, 我又研究了一下:
首先是关于 MSCHAPv2 哈希解密有关的, 我们研究 MSCHAPv2 的流程:
(Mermaid diagram omitted - please read the original post)
具体使用 Server Challenge, Peer Challenge 和 username, password 计算 NT-Response 的方式如下:
(Mermaid flowchart omitted - please read the original post)
(这些图花了我 20 min) 可以看出来的是这里从 Response 可以直接逆向得到各个 DES 块的 Plaintext 和 Ciphertext, 进而可以利用 Known Plaintext Attack 得到 PWHASH; 不过更好的方式还是得到大量的 Hash 然后爆破弱密码.
此外, 由于 Client Challenge 的缘故, 我们没办法把盐 (这里的 DES 明文) 固定, 所以比较可惜.
5G AP (2)
新网卡是 MTK 的, 但是默认情况下依然是大量信道 No-IR. 还得 Patch 驱动 (). 不过我用 36 信道的 HT40+ 试过了, 确实是可以用并获得哈希的.
5G AP (3)
UPDATE 2025-02-17:开学了, 终于可以实地实验了! 我又研究了一下究竟如何才能正确发射 5GHz 信号, 外加得到了一些短期的成果. 首先是关于 No-IR 的问题: 我终于是看懂了到底是怎么一回事.
是否 PASSIVE-SCAN 取决于 Regulatory DB 怎么说. 对于内嵌的这张 Intel 的网卡, 其 RegDB 是写死在固件里面的 (iw reg get显示self-managed, 不由系统统一管理), 是 "CN, DFS-UNSET", 且同时在所有信道都要求 Passive Scan. 因此, Linux Driver 也遵照这个固件指引的 RegDB 去执行. 之前 Patch Driver 的时候虽然删掉了这段逻辑, 但是网卡的固件没变, 不 Passive Scan 就尝试发射信号进入 AP 模式的命令会被固件直接 Reject 掉 (太安全了!).
而 MTK 的卡确实没有这个问题, 其 Regulatory Domain 就是系统的. 然而, Arch 默认没有安装 RegDB (crda), 系统 Fallback 到了00Domain, 此时只允许大部分国家都有的那些 channel, 且都要 Passive Scan.
我在一圈搜索之后终于意识到了这一点, 安装了 CRDA 并修改了 Config 文件, 将地区设置为 CN. 重启之后的默认地区就是 CN 了, 这时的符合中国无线电标准的那些频率就不需要 Passive-Scan 了, 可以直接发射信号.
我这张卡支持的规格不高, 只有 802.11ac, 40MHz 频宽. 在教学楼里面竞争不过校园网 AP (没办法喽), 不过在户外没有 Tsinghua-Secure 信号的地方还是很有效的.
