近年来，随着万物互联技术的发展，Mesh 技术逐渐兴起，Mesh 技术是一种组网技术，可将多个接入点组成同一个网络来提供服务，相比于传统的 WiFi 组网技术，Mesh 组网更稳定，更快，扩展性更强。而 WiFi Mesh 也凭借着自组织，自管理，自治愈的特性，在未来万物互联的场景中占据重要的地位。

针对 WiFi Mesh 的新兴场景，在本次 Black Hat Europe 2021 大会上，百度安全以线上的形式分享了议题《BadMesher: New Attack Surfaces of Wi-Fi Mesh Network》，该议题主要讨论了 WiFi Mesh 中的安全攻击面，设计并实现了一套自动化漏洞挖掘工具 MeshFuzzer，并展示了其在实际漏洞挖掘过程中的效果。

议题解读

基本概念

EasyMesh 概念

EasyMesh 是 WiFi 联盟推出的一项标准化认证方案，其经历了三个发展阶段：

图 1 EasyMesh 发展流程

2018 年，Mesh 技术为厂商各自实现，缺乏统一的标准，因此不同厂商的设备之间无法互联互通。

2019 年，WiFi 联盟推出 EasyMesh V1 版本，引入了 Onboarding 流程和 Auto-Config 流程，并使用 1905 控制协议来实现 Mesh 中大部分的控制功能。

2020 年，WiFi 联盟推出 EasyMesh V2 和 V3 版本，V3 版本丰富了更多的控制特性，尤其增加了安全特性，为控制消息添加了授权和完整性校验。

目前通过 EasyMesh 认证的厂商已经有数十家，其中包括 Mediatek、Huawei、ZTE 等。

EasyMesh 架构

EasyMesh 的架构如图 2 所示，其中包含两个关键链路，两个关键角色。

图 2 EasyMesh 架构图

关键链路

1、Fronthaul 链路：指的是暴露的 WiFi 链路，也就是我们手机能够正常连接的 SSID

2、Backhual 链路：指的是隐藏的 WiFi 链路，即为是无法搜索到的 SSID，是专门为 Mesh 提供的链路

关键角色

1、Controller 角色：Mesh 网络的管理者，可向 Agent 发送控制指令，来完成 Mesh 网络的管理，达到自组织，自管理，自治愈的效果

2、Agent 角色：Mesh 网络的执行者，通过接受 Controller 的控制指令来执行任务，并向 Controller 反馈执行结果

这里的角色并不针对具体的设备，是逻辑实体，一个设备既可以作为 Controller 也可以作为 Agent，或者同时作为 Contrller 和 Agent。

Mesh 网络构建过程

整个 Mesh 网络构建过程分为如下 2 步：

1、Onboarding

2、Discovery 和 Configuration

Onboarding 过程

Onboarding 过程是帮助一个未加入 Mesh 网络的设备加入 Mesh 网络，我们将未加入网络的设备称为 Enrollee 设备，整个过程是通过 1905 Push Button Configueration 协议（后面简称 1905 PBC）来实现的，1905 PBC 包含了如下 3 个特性：

1、特性 1：入网双方需要进行 push button

2、特性 2：基于 WiFi Protected Setup 实现

3、特性 3：基于 TLV

从图 3 中可看出，1905 PBC 在 Multi-AP Extension 部分进行了专门的标记，也就是标记获取的是 Backhaul 的 SSID。因此 Entollee 设备可通过 1905 PBC 来获得 Mesh 链路的入网凭证。

图 3 Multi-AP Extension

整个 Onboarding 的流程如图 4 所示：

图 4 Onboarding 流程

首先将两个设备进行 Push Button，让两个设备进入配网状态。

其次 Enrollee 设备通过 1905 PBC 来与 Fronthaul SSID 交互，经过 M1-M8 的过程后，最终 Existing Agent 将 Backhual 的 SSID 和 password 返回给 Enrollee 设备，之后 Enrollee 设备便能够连接 Backhaul SSID，加入 Mesh 网络。

至此 Onboarding 流程完成了。

Discovery 和 Configuration 过程

整体流程如图 5 所示：

图 5 Discovery 和 Configuration 流程

在完成 Onborading 流程后，Enrollee 设备需要找到 Mesh 网络中的 Controller 来获得当前 Mesh 网络的基本配置，这里则使用 IEEE1905.1a 控制协议，Enrollee 设备通过“AP Autoconfig Search”广播包来探测 Controller 是否存在，若网络中存在 Controller, 则 Controller 会回复“AP Autoconfig Response”， Enrollee 设备成功找到了 Controller，至此，Discovery 过程完成。

Configuration 过程则是将当前 Mesh 网络的配置信息同步给 Enrollee 设备，如 Mesh 网络的用户名密码，通信 Channel 的选择，网络稳定性的维持参数等，是通过“AP Autoconfig Wifi Sample Configuration”来实现的，Enrollee 设备获取了 Mesh 网络的基本配置，可真正的 Agent 的身份加入 Mesh 大家庭里，至此整个 Mesh 网络构建完成。

Mesh 网络控制过程

Mesh 网络的维护与管理是一项重要的工程，通过 IEEE1905.1a 来实现，IEEE1905.1a 本质上是介于物理层和网络层的协议，是定义了家庭网络中的有线或无线的控制技术。在 Mesh 场景中，IEEE1905.1a 是载体，提供了多种控制协议如设备发现、设备配置、设备管理等，其整个实现都是基于 Type-Length-Value，部分 EasyMesh 控制协议如表 1 所示：

表 1 部分 EasyMesh 控制协议

这里选择“Multi-AP Policy Config Request Message”来作为例子，可以看到图 6 对应的命令字为 0x8003，具体的 Streeing Policy 则满足基本的 TLV，可以看到图 6 中 Type 为 0x89，len 为 21，而 value 则为对应的 payload。

图 6 Multi-AP Policy Config Message

攻击面分析

分析完了整个 Mesh 网络的组网和控制过程，我们来看看实际的攻击面，攻击的载体是两个关键协议：

1、1905 Push Button Configuration Protocol

2、IEEE 1905.1a Control Protocol

对应的是两个关键的攻击面：

1、攻击网络构建过程

2、攻击网络控制过程

攻击 Mesh 网络构建过程

攻击 Existing Agent

攻击者：“Bad“ Enrollee Agent

受害者：Exixting Agent

攻击载体：1905 Push Button Configuration Protocol（M1、M3、M5、M7）

整个攻击流程如图 7 所示

图 7 攻击 Existing Agent

攻击者构造恶意的 Enrollee 设备来攻击 Existing Agent，具体则是基于 1905 PBC 发送畸形的 M1、M3、M5、M7 包来进行攻击，可触发 Existing Agent 在 M1、M3、M5、M7 过程中的 TLV 的解析漏洞。

攻击 Enrollee Agent

攻击者：“Bad” Existing Agent

受害者：Enrollee Agent

攻击载体：1905 Push Button Configuration Protocol（M2、M4、M6、M8）

整个攻击流程如图 8 所示

图 8 攻击 Enrollee Agent

攻击者构造恶意的 Existing Agent 设备来攻击 Enrollee 设备，具体则是基于 1905 PBC 回复畸形的 M2、M4、M6、M8 包来进行攻击，可触发 Enrollee 设备在 M2、M4、M6、M8 过程中的 TLV 解析漏洞。

攻击 Mesh 网络控制过程

分析完 Mesh 构建的攻击面，再看 Mesh 网络控制的攻击面。

攻击者：“Bad” Existing Agent

受害者：Controller 和其他 Existing Agent

攻击载体：IEEE 1905.1a Control Protocol

攻击者可发送畸形的 1905 包来触发 Controller 和 Existing Agent 中 1905 TLV 的解析漏洞，图 9 是我们针对“AP_AUTOCONFIGURATION_WSC_MESSAGE”设计的恶意包，可以看到，我们在 SSID 的 len 部分填入了 0xFF，而实际的 SSID 最长为 64，并在 SSID 的 payload 部分中全部填入 0xFF，从图 10 实际获取的数据包中可以看到，实际的 SSID 部分充满了我们填充的 0xFF 的 Payload，这是不符合 SSID 解析的预期。

图 9 模拟发送畸形的 IEEE 1905.1a 控制包

图 10 实际的 IEEE 1905.1a 控制包

自动化工具 MeshFuzzer

MeshFuzzer 架构

我们的 Meshfuzzer 包含两个 Fuzzing 子系统，分别是针对 1905 PBC 的 Fuzzing 以及针对 1905.1a 的 Fuzzing，整体架构如图 11 所示。

图 11 MeshFuzzer 架构

上半部分是我们设计的针对 1905 PBC 的 Fuzzing 子系统，我们采用实际设备间的 WPS 交互数据作为输入，经过我们的 TLV 变异系统，最终使用我们的 802.1 的发包器来进行发包，与此同时对设备进行串口连接，实时监控 crash 的状态。

下半部分是我们设计的针对 IEEE 1905.1a 的 Fuzzing 子系统，我们实现了大部分 EasyMesh 中的控制协议字段，同样经过我们的 TLV 变异系统，最终使用我们的 1905 发包器来进行发包，通过独有的 1905 数据包来监控 crash 的状态。

变异策略

由于两个目标协议均是基于 TLV 实现的，我们可以用统一的变异策略来高效的辅助 Fuzzing 的进行。

变异策略 1：变异长度字段，通过过长或者过短的长度来触发 TLV 解析的一些常规内存破坏漏洞，比如长度过短会导致越界读，或者整数溢出，过长会导致越界写等问题，图 12 是我们实际测试中将长度字段变异为过短的效果。

变异策略 2：对现有的 TLV 块进行随机的增删改，这可能会导致的内存破坏相关的逻辑漏洞，如 Double-Free、UAF 等，图 13 是我们实际测试中随机增加 TLV 块的效果。

图 12 过短的长度字段

图 13 随机对 TLV 块进行增加

Fuzzing 网络构建过程

软硬件选择

硬件部分：选择 Ubuntu 或者树莓派 4，配合无线的 USB 网卡来进行发包操作。

软件部分：选择了对 wpa_supplicant 进行改造来定制化我们的 Fuzzer，具体原因则是 wpa_supplicant 本身支持 1905 PBC 协议，因此我们可以在其不同的阶段中加入我们的变异策略，可高效稳定的实现 Mesh 网络构建阶段的 Fuzzing 工作。

图 14 wpa_supplicant 实现代码

实际 Fuzzing Existing Agent

我们使用以上的定制化的 Fuzzing 工具，便可模拟整个 1905 PBC 过程，并对 M1、M3、M5、M7 阶段注入 Fuzzing Payload，图 15 是我们在 Fuzzing 过程中，捕获到的的 M7 阶段的 TLV 解析导致的越界写入漏洞的崩溃日志，图 16 是我们捕获的实际的数据包。

图 15 M7 阶段越界写问题

图 16 M7 阶段越界写实际数据包

我们监控崩溃的方式则是通过对目标设备进行 Ping 探测以及串口实时捕获崩溃日志。

实际 Fuzzing “Existing” Agent

Network 构建过程另一个受害角色，则是未配网的“Enrollee”，我们模拟一个恶意的“Existing” Agent 来 fuzzing “Enrollee”。这里为了保证让 Enrollee 持续保持加入 Mesh 网络的状态，我们编写了一个脚本，如图 17 所示。

图 17 Enrollee 保持加入 Mesh 网络脚本

我们在 M2、M4、M6、M8 阶段注入了 Fuzzing Payload，图 18 是我们 Fuzzing 过程中，触发的 M6 阶段的 TLV 解析导致的越界写入漏洞。图 19 是我们捕获的实际的数据包。

图 18 M8 阶段越界写问题

图 19 M8 阶段越界写实际数据包

这里我们监控崩溃的方式仍然是通过对目标设备进行 Ping 探测以及串口实时捕获崩溃日志。

Fuzzing 网络控制过程

软硬件选择

硬件部分：选择了 Macbook Pro，因为 Macbook Pro 可以较好的支持 1905 数据包的发。

软件部分：选择了现有的开源库 pyieee1905，因此我们可以基于 pyieee1905 来开发自定义的协议字段，这将大大减少我们 Fuzzer 的开发工作量，我们只需要实现 EasyMesh 里的控制协议便可对网络控制部分进行 Fuzzing 测试。

图 20 pyieee1905

监控模块

由于 1905 的处理模块大多是单独的进程，我们无法直接通过串口捕获崩溃，也无法通过对设备发送 Ping 探测包来监控 1905 进程的运行状态，这里我们选择 EasyMesh 里提供的 1905 Topology Query Message，该数据包是用于设备 1905 进程间探测互相支持的能力，因此通过设备对该包的回复与否，我们便可容易的知道，设备上的 1905 进程是否存活，或者是否在正常工作。

图 21 Topology Query Message

每当我们发出一个 Fuzzing Payload，便会发送一次 1905 Topology Query，若得到回复，说明 1905 Daemon 正常工作，若未得到回复，说明 1905 Daemon 可能出现了问题，此时我们会记录此次发送的 Fuzzing Payload 到本地保存，并等待进程的重启。

图 22 1905 崩溃监控与保存

图 23 实际崩溃

实际效果

我们使用 MeshFuzzer 在 Mediatek MT7915 的 EasyMesh 解决方案中发现了多处 TLV 解析导致的内存破坏漏洞，并发现了 1 处违背安全设计准则的安全问题，累计获得了 19 个 CVE，问题列表如图 24 所示，目前 Mediatek 已经修复了所有问题并输出了安全补丁。

图 24 MT7915 安全问题

安全建议

对于处理 TLV 解析导致的内存破坏漏洞，我们建议对数据包进行完整解析，然后一一检查类型和长度，最后进行处理，当长度和类型检查失败时对数据包进行丢弃。

一个很好的例子是 wpa_supplicant，图 25 中显示了 wpa_supplicant 处理 TLV 包的过程，遵循解析->分发->验证->处理的过程。

图 25 正确的 TLV 处理例子

针对违背安全设计准则的问题，EasyMesh V3 标准中有一节专门描述了 1905 协议的安全能力。例如，要隔离 Backhaul 和 FrontHaul 链路，需要增加消息的完整性校验并 1905 包进行加密，建议厂商在实现 EasyMesh 时，遵守 EasyMesh 标准，实现 1905 协议的安全能力。

总结

对整个议题总结如下：

1、我们发现了 WiFi Mesh 中的多个安全攻击面，攻击者可以在 Mesh 网络构建阶段和网络控制阶段对 Mesh 网络中的设备发起攻击；

2、我们开发了一款自动化漏洞挖掘工具 MeshFuzzer，可以自动挖掘厂商在实现 EasyMesh 时引入的安全漏洞；

3、在实践中，我们在 MT7915 芯片的 EasyMesh 解决方案中发现了多处安全问题，获得了 19 个 CVE，并给出相应的修复建议。