![]()
近年來，隨着萬物互聯技術的發展，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步：
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鏈路的入網憑證。
首先將兩個設備進行Push Button，讓兩個設備進入配網狀態。
其次Enrollee設備通過1905 PBC來與Fronthaul SSID交互，經過M1-M8的過程後，最終Existing Agent將Backhual的SSID和password返回給Enrollee設備，之後Enrollee設備便能夠連接Backhaul SSID，加入Mesh網絡。
Discovery和Configuration過程
圖 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所示：
|
|
|
|
|
1905 Topology Notification message
|
|
|
|
Multi-AP Policy Config Request message
|
|
|
|
Unassociated STA Link Metrics Response message
|
|
|
|
Backhaul Steering Request message
|
|
|
|
Client Disassociation Stats message
|
|
|
|
|
|
|
這裏選擇“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
攻擊載體：1905 Push Button Configuration Protocol（M1、M3、M5、M7）
攻擊者構造惡意的Enrollee設備來攻擊Existing Agent，具體則是基於1905 PBC發送畸形的M1、M3、M5、M7包來進行攻擊，可觸發Existing Agent在M1、M3、M5、M7過程中的TLV的解析漏洞。
攻擊Enrollee Agent
攻擊載體：1905 Push Button Configuration Protocol（M2、M4、M6、M8）
攻擊者構造惡意的Existing Agent設備來攻擊Enrollee設備，具體則是基於1905 PBC回覆畸形的M2、M4、M6、M8包來進行攻擊，可觸發Enrollee設備在M2、M4、M6、M8過程中的TLV解析漏洞。
攻擊Mesh網絡控制過程
分析完Mesh構建的攻擊面，再看Mesh網絡控制的攻擊面。
受害者：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控制包
自動化工具MeshFuzzer
MeshFuzzer架構
我們的Meshfuzzer包含兩個Fuzzing子系統，分別是針對1905 PBC的Fuzzing以及針對1905.1a的Fuzzing，整體架構如圖 11所示。
上半部分是我們設計的針對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塊的效果。
Fuzzing網絡構建過程
軟硬件選擇
硬件部分：選擇Ubuntu或者樹莓派4，配合無線的USB網卡來進行發包操作。
軟件部分：選擇了對wpa_supplicant進行改造來定製化我們的Fuzzer，具體原因則是wpa_supplicant本身支持1905 PBC協議，因此我們可以在其不同的階段中加入我們的變異策略，可高效穩定的實現Mesh網絡構建階段的Fuzzing工作。
實際Fuzzing Existing Agent
我們使用以上的定製化的Fuzzing工具，便可模擬整個1905 PBC過程，並對M1、M3、M5、M7階段注入Fuzzing Payload，圖 15是我們在Fuzzing過程中，捕獲到的的M7階段的TLV解析導致的越界寫入漏洞的崩潰日誌，圖 16是我們捕獲的實際的數據包。
我們監控崩潰的方式則是通過對目標設備進行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是我們捕獲的實際的數據包。
這裏我們監控崩潰的方式仍然是通過對目標設備進行Ping探測以及串口實時捕獲崩潰日誌。
Fuzzing網絡控制過程
軟硬件選擇
硬件部分：選擇了Macbook Pro，因爲Macbook Pro可以較好的支持1905數據包的發。
軟件部分：選擇了現有的開源庫pyieee1905，因此我們可以基於pyieee1905來開發自定義的協議字段，這將大大減少我們Fuzzer的開發工作量，我們只需要實現EasyMesh裏的控制協議便可對網絡控制部分進行Fuzzing測試。
監控模塊
由於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到本地保存，並等待進程的重啓。
實際效果
我們使用MeshFuzzer在Mediatek MT7915的EasyMesh解決方案中發現了多處TLV解析導致的內存破壞漏洞，並發現了1處違背安全設計準則的安全問題，累計獲得了19個CVE，問題列表如圖 24所示，目前Mediatek已經修復了所有問題並輸出了安全補丁。
安全建議
對於處理TLV解析導致的內存破壞漏洞，我們建議對數據包進行完整解析，然後一一檢查類型和長度，最後進行處理，當長度和類型檢查失敗時對數據包進行丟棄。
一個很好的例子是wpa_supplicant，圖 25中顯示了wpa_supplicant處理TLV包的過程，遵循解析->分發->驗證->處理的過程。
針對違背安全設計準則的問題，EasyMesh V3標準中有一節專門描述了1905協議的安全能力。例如，要隔離 Backhaul 和 FrontHaul 鏈路，需要增加消息的完整性校驗並1905包進行加密，建議廠商在實現EasyMesh時，遵守EasyMesh標準，實現1905協議的安全能力。
總結
1、我們發現了WiFi Mesh中的多個安全攻擊面，攻擊者可以在Mesh網絡構建階段和網絡控制階段對Mesh網絡中的設備發起攻擊
2、我們開發了一款自動化漏洞挖掘工具MeshFuzzer，可以自動挖掘廠商在實現EasyMesh時引入的安全漏洞
3、在實踐中，我們在MT7915芯片的EasyMesh解決方案中發現了多處安全問題，獲得了19個CVE，並給出相應的修復建議
![]()
