这是2024年的第50篇文章
（ 本文阅读时间：15分钟 ）
01
背景介绍
微软在六月的安全更新中，修复了一个WiFi驱动的漏洞。漏洞描述的攻击场景吸引了很多人的注意：在近源的场景下，攻击者通过发送WiFi数据包来发动攻击。
这篇漏洞公告一石激起千层浪：
有人声称以5000美元出售漏洞的PoC
国内技术论坛上对漏洞的讨论和猜测
以及github上流传的各种假PoC。
它一开始声称漏洞原因是SSID溢出，直到广大网友在issues中质疑无法复现，才承认自己只是在尝试复现漏洞，并删光了之前所谓对漏洞原理的描述。
从直觉上讲，这个漏洞危害不会很大。漏洞作者是赛博昆仑@XiaoWei___，如果特别好用在这个时间点可能就不会提交了。至于出售PoC可信度也不高，5000美元也过于便宜了。
漏洞作者的推特上有一些公开的信息，表明这是一个越界写漏洞。漏洞的发现受到了古河2023年blackhat议题的启发。这个议题是关于windows对各种底层网络协议处理上的漏洞。
考虑要过去出现过类似场景下的漏洞，例如p0团队从苹果的AWDL协议（基于WiFi）中发现的漏洞，可以做到0click通过WiFi黑掉iphone。因此我们希望弄清楚，漏洞的影响具体如何，是否有大家猜测的那样危害巨大。
02
静态分析
2.1 定位补丁
首先需要定位到patch的位置。在打上win10的6月更新补丁后，我们发现win10的C:\Windows\System32\Drivers\目录下有以下文件的更新：
从文件名上看，nwifi.sys和wdiwifi.sys比较可疑
经过bindiff的处理，wdiwifi.sys新旧版本没有明显的差异，而nwifi.sys有个疑似打过补丁的函数，Dot11Translate80211ToEthernetNdisPacket
后续漏洞作者也在回复中确认，漏洞位于nwifi.sys
2.2 什么是系统
从函数的名称Dt11Translate80211ToEthernetNdisPacket可以推测，这个函数用于处理802.11数据包。802.11是一种无线局域网的标准，而WiFi是802.11标准的一种产品实现。用IDA反编译函数，发现补丁是增加了一处对数值的比较，如果不满足条件则返回NDIS_STATUS_INVALID_PACKET（0xc001000），即数据包非法。
调用层次图表明，函数会在接收到802.11数据包时被调用。上层函数的名称中，STA即Station，AP即Access Point。Station是无线网络中的客户端设备，而Access Point则是提供无线接入服务的网络基础设施设备。用户通过Station设备连接到Access Point，进而访问网络资源。
我们预期受害者应该作为Station，进而关注上层的ExtSTAReceivePacket函数。在其中可以看到对多种类型802.11数据包的处理，包括DataPacket、ProbeRequest和Beacon
Beacon和ProbeRequest都属于802.11的管理帧：
Beacon是WiFi服务端AP定期广播的数据包，其主要目的是宣告该AP的存在以及网络的基本信息。WiFi客户端会监听这些Beacon帧，来发现可用的网络；
ProbeRequest是由WiFi客户端Station发起的，用于主动搜索特定的无线网络。如果存在匹配的网络，则该AP将回应一个Probe Response帧，包含网络的具体配置信息。
在802.11的header中，管理帧的Type值为00，控制帧的Type值为01，数据帧的Type值为10。观察函数ExtSTAReceiveDataPacket所在分支的进入条件 v19 & 0xC == 0x8，即 v19 & 0b1100 == 0b1000。所以想要进入Patch的代码，需要数据包为数据帧，而非管理帧。因此一些假PoC所谓Beacon中SSID溢出，明显是错误的。
接下来的部分难以通过静态分析看出来，需要进行动态调试。
03
动态调试
3.1 环境搭建
准备一个usb无线网卡，以及两台windows虚拟机
在vmware中设置debugee连接usb网卡
为两台虚拟机设置同一个host-only网络，以进行双机内核调试，具体可参考教程。
3.2 主要问题
根据patch的代码，现在有两个需要解决的问题：
满足v14==0x81，才能进入补丁的逻辑，那么v14是数据包中的哪个字段，0x81又是什么含义；
patch处比较的两个值又是什么，注意这是一个纯数值上的比较，v27 - *(a+12) >= 12。
3.3 问题1. 0x81是什么
对于加密的WiFi，其数据帧中的数据是被加密的。
不过在进入ExtSTAReceiveDataPacket函数时，Data的内容已经被解密。动态调试发现，v8指向解密后的数据包，v7为802.11数据头的长度，因此&v8[v7]即跳过了header，指向解密后Data数据。
将数据从内存中导出，放到wireshark中进行分析。可以看出v14就是取出Logical-Link Control层中，Type的值。
LLC是数据链路层的网络协议，通常占用8个字节。
实际调试时，v14的值不是0x8就是0xdd86
如果类型标识是VLAN的话，LLC的8字节后还要带上一个4字节的802.1Q Header，用来标识VLAN ID。
而v14 == 0x81后的代码，就是在处理这4 个字节 （&v8[v7+8], &v8[v7+10]）。
其实这里已经可以看出问题了，先卖个关子，不知道读者能不能反应过来。提示：不要被“越界写漏洞”这个概念先入为主。
3.4 问题2. 比较双方的值是什么
回顾patch的内容，大概逻辑是判断x < y+12
其实在patch之前，还有一处比较，比较逻辑是 x < y+8
经过测试，我们发现y是802.11 header的长度，而x是整个数据包的大小 （包括802.11 header）。现在答案已经呼之欲出了：正常来说LLC的大小为8字节，但是如果LLC中Type为VLAN，后面还要跟上4字节的内容。然而如果整个数据包只有802.11 header和LLC，且LLC长度为8、Type为VLAN，则在未打补丁的版本上会越界读4个字节！
这么看来两处比较就非常合理：
接下来要处理8字节的LLC数据，所以这8个字节必须存在
接下来要处理12字节的LLC数据，所以这12个字节必须存在
3.5 越界写
漏洞的直接原因清楚后，既然漏洞作者表明这是一个越界写，则在后续的代码中自然有越界写的位置。这个Patch函数的名字是Dot11Translate80211ToEthernetNdisPacket，说明它是一个转换函数。但问题是这个转换的过程没有发生在新的buffer，而是直接修改原buffer。注意变量v15，最终指向了802.11header的倒数第6个字节。在line113/114/115发生了对原buffer的修改。
直接说结论，在最理想的情况下，会在原buffer中写12字节的数据，分别是802.11header中，帧接收端mac地址以及帧发送端的mac地址。为了节约空间，正常就是覆盖802.11header结尾的6个字节，以及LLC的6个字节。至于为什么保留了2个字节，因为要保留EtherType的信息。
但是如果LLC类型为VLAN，程序就会默认LLC有12字节，给v15加上4。于是便覆盖LLC开始的6+4=10个字节。但是在上述恶意的数据包中，LLC长度只有8，这样就会在堆上越界写2个字节，且这两个字节为发送端mac地址的后两位，是可控的。
例如图中数据包原长度为0x22，经过函数处理后，越界写了2个字节。22:0b即发送者mac地址的后两位（c2:38:97:bd:22:0b）。
但是有一个限制，越界写的触发并不稳定，需要缓冲区后的4个字节满足一定的条件：
这些使得整个漏洞更难以利用。
3.6 动态复现
购买一个kali linux上可以开启monitor mode的无线网卡，有一个简单进行动态复现的方式：
1）开启1个未加密的WIFI，比如手机热点；
2）debugee连上这个WIFI；
3）kali进入monitor mode抓包，抓取一个从WIFI AP到debugee的数据包（data frame）；
4）将这个数据包修改成期望的数据，在kali上使用scapy（python三方库）重放修改后的数据。
注意：保证开启monitor mode的无线网卡，和WIFI AP位于同一channel下
04
总体回顾
4.1 漏洞效果
攻击者发送恶意的WiFi数据包；受害者在处理这个数据包时，在一定的条件下会触发一个堆上的越界写，写入的两个字节攻击者可控。
4.2 利用场景
1）攻击者作为AP，诱导受害者连上该WiFi，之后发动攻击
注意：不存在用户仅仅是开启WiFi就被攻击的情况
2）攻击者和受害者连上同一WiFi，之后发动攻击
4.3 局限性
1）内存洞利用在场景2下可能较为困难：
一些路由器可能会直接丢弃这种畸形数据包，或是丢弃未知源mac的数据包；
连上WiFi的设备普遍会有大量的数据包交互，可能会影响漏洞利用时对堆的控制；场景1下实战RCE的可能更大，因为作为AP可以严格控制发送给受害者的数据包，一定程度上降低对内存布局的干扰。
2）受害者必须要主动连上WiFi，不存在什么都不操作，只要开启wifi功能就会中招的情况：
WiFi客户端会自动忽略来自不同WiFi的数据帧，即使该WiFi没有加密。这是由网卡厂商开发的驱动决定的。如果能自动监听数据帧等于有窃听的功能，有法律上的风险。
除非网卡进入“监视模式”，才会接收和处理周围所有 WiFi 网络中的数据帧，而不是直接过滤掉。但是Windows上网卡驱动一般不支持开启监视模式，即使支持也需要用户主动去切换（netsh wlan show wirelesscapabilities 查看）。
所以正常用户必须要连上WiFi才可能中招；
3）采用较新的WDI驱动模型编写的网卡驱动，不会受到漏洞影响：
无线网卡的驱动都会与ndis.sys交互。ndis.sys是Windows操作系统中的网络驱动接口规范（Network Driver Interface Specification, NDIS）的核心驱动程序。
如果驱动使用的是传统NDIS模型，则ndis.sys最终会调用nwifi.sys驱动模块的功能；而如果驱动是采用WDI驱动模型，则ndis.sys最终会调用wdiwifi.sys驱动模块的功能。nwifi.sys和wdiwifi.sys都有对802.11相关协议的解析，后者只支持win10及以上的版本。
例如我测试的tx-ac88网卡的驱动，采用了WDI驱动模型，不会受到漏洞的影响。
而UGREEN-AX300为了兼容win7使用了传统NDIS模型，才能触发到漏洞位置。
所以这个漏洞确实有一定的危害性，但是没有大家猜测的那么危险。直观的缓解措施就是不要随便连WiFi。同时这个漏洞也能给我们带来很多启发，近源场景下的漏洞值得被关注。
最后，由于笔者水平有限，文章难免有错误或疏漏的地方，欢迎各位大佬交流指正。
参考链接
[01] 漏洞描述
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-30078
[02] 古河2023年blackhat议题
[03] 设置host-only网络进行内核调试教程
[04] P0团队从苹果AWDL协议（基于WiFi）中发现的漏洞
https://googleprojectzero.blogspot.com/2020/12/an-ios-zero-click-radio-proximity.html
欢迎留言一起参与讨论~
