作者：曲樂煒&柯懂湘@百度AIoT安全團隊
原文鏈接：https://mp.weixin.qq.com/s/GUab_Cz-PlEUJXNuyiVTLQ

近年來，隨著萬物互聯技術的發展，Mesh技術逐漸興起，Mesh技術是一種組網技術，可將多個接入點組成同一個網絡來提供服務，相比于傳統的WiFi組網技術，Mesh組網更穩定，更快，擴展性更強。而WiFi Mesh也憑借著自組織，自管理，自治愈的特性，在未來萬物互聯的場景中占據重要的地位。

針對WiFi Mesh的新興場景，百度安全的研究員曲樂煒和柯懂湘在北京時間11月11日晚上以線上的形式分享了議題《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

從圖 4中可看出，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所示。

*Message type* *Protocol* *Value*
1905 Topology Notification message STA capability 0x0001
Multi-AP Policy Config Request message Multi-AP configuration 0x8003
Unassociated STA Link Metrics Response message Link metric collection 0x8010
Backhaul Steering Request message Backhaul optimizatio 0x8019
Client Disassociation Stats message Data Element 0x8022
...... …… ……

表 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，并給出相應的修復建議

Paper 本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/1762/