0x00前言

---

目前市面上有不少缺乏輸入裝置但需要連線雲端的智慧裝置，這些裝置在加入Wi-Fi前需要得到相關的認證資訊，為了便於使用者使用，廠商通常在配套的移動端應用中透過類似下方的介面引導使用者將Wi-Fi認證資訊傳輸給智慧裝置。

但在僅藉助於已經加密的Wi-Fi通道的條件下，處在Wi-Fi網路內的移動應用端和在網路之外的智慧裝置間是如何傳遞這些資訊的？各個廠商透過此類快速配置協議繞過這個相悖問題的同時，是否存在協議實現上的安全問題？

0x01 風險評估

---

設想一個場景：某房主和相識的人之間約定將鑰匙放在某個地點，但是這一過程被三方知曉並隨便複製了鑰匙。如果應用和裝置之間的傳輸是三方可以獲取並看到明文內容的，那麼就面臨Wi-Fi認證資訊洩露的風險。完整的加密過程需要包含有效的金鑰交換，如果所用的金鑰為固定或可預測，則演算法本身不能保護資料的私密性，所以風險評估需要了解快速配置協議的具體實現。此外這類問題由於藉助Wi-Fi路由器傳遞資訊，受影響的攻擊範圍限定在能夠接受Wi-Fi訊號的範圍內(寫字樓或者住宅區)，而時間點定於等待進行配置的過程。

0x02 背景IEEE 802.2/802.11

---

要了解快速配置協議的工作原理，首先需要了解一些相關底層協議IEEE 802.2 與IEEE 802.11的簡要資訊，這兩種標準對應在OSI網路模型層級關係如下：

802.11協議簇是IEEE為無線區域網路制定的標準。802.11之上以802.2的邏輯鏈路控制(LLC)封裝來攜帶IP封包。當裝置開啟Wi-Fi晶片的混雜模式監聽無線訊號，並以802.2 SNAP格式從資料鏈路層擷取資料時，就會得到如下圖所示的資料包：

802.2 SNAP 格式資料包

紅色部分為Data Link結構，其中DA是目標MAC地址，SA是源MAC地址，Length為包長度。藍色部分就是802.2 LLC的結構內容，之後跟著SNAP欄位，DATA為加密後的IP封包內容，FCS為校驗欄位。除DATA欄位為加密後的資料，其他欄位為明文可見，快速配置協議可以透過這些明文可見的欄位傳輸Wi-Fi認證資訊。但是現在有一個問題：出於安全的考慮，在IOS和安卓上執行的普通移動端應用並沒有許可權去直接控制802.2 SNAP包頭當中的資料。

0x03 資料載體方式一：包長度

---

既然不能直接控制底層包頭中的內容，開發人員便想到可以透過傳送不同長度的資料包，使包的長度本身作為一種資訊載體（限於MTU的大小，每次傳送~8Bit的資料），之後再將各個包長度攜帶資訊重新組合成各家快速配置協議中定義的資料結構。從德州儀器的Ti CC3000晶片支援的第一種快速配置協議SmartConfig開始，到近期騰訊推廣的Air Kiss協議來看，多是透過此種方法。可以在網上找到這些協議的詳細分析或官方文件，例如SmartConfig協議：

http://depletionregion.blogspot.com/2013/10/cc3000-smart-config-transmitting-ssid.html

這裡就不再詳細描述以長度為載體的協議實現方式了。

0x04 資料載體方式二：目標MAC地址

---

透過長度本身作為資料載體是個非常不錯的思路，是否有其他的方式？在測試中嘗試了小米智慧攝像頭，抓取到配置過程中的網路報文如下：

發現從開始到配置成功，之間每個報文的長度都是4位元組，並且內容固定為miio。

看來不是以長度為載體傳遞資訊。細看這些傳送的報文，似乎另有玄機。

0x04.1IP-MAC轉換與組播

如之前提到，普通應用因為許可權原因無法直接控制底層包頭中的資料，那能否有迂迴的方式能夠更改其中DA的值(目標MAC地址)？一般情況下，上層應用在使用類似Socket程式設計時填入目標IP進行網路通訊，之後作業系統會查詢維護的路由表和ARP表，並確定底層網路包中需要填入的MAC地址。如果是同區域網目標將直接填入查詢到的MAC地址，如果需要路由轉發的則填入路由的MAC地址。要將DA(MAC地址)作為資訊傳遞的載體就需要確定某種形式的IP-MAC的對映，但ARP表的變更也同樣需要許可權。是否還存在某種可行的方式進行IP-MAC間的對映？

單播(Unicast)，組播(Multicast)和廣播(Broadcast)是IP網路傳輸的三種模式。其中組播在傳送者和每一接收者之間實現單點對多點網路連線，該模式的出發點是節約網路傳輸頻寬。組播有一個重要的特性就是IP地址和MAC地址是存在固定對映關係的：

從上面的圖我們可以看到組播模式下IP-MAC之間可以完成23bits的資料對映。舉一個簡單的例子：如果應用向IP地址224.126.0.1發包，那麼系統會自動將對應的MAC地址01:00:5e:7e:00:01填入底層包頭結構中。

0x04.2 小米快速配置協議傳輸

回到擷取到的在配置Wi-Fi認證給攝像頭過程中的資料包，可以看到移動裝置所傳送網路報文的目標IP地址都是224.126開頭的。其中IP-MAC的對映只使用了後16bit的內容，以224.126.X.Y為例，X位元組被用作編號，而Y位元組則是載入的資料。

使用底層包頭DA欄位(MAC地址)作為資料載體，並透過組播定義的IP-MAC地址對映實現應用層的資料控制就是小米系智慧裝置所使用快連協議的實現基礎，這種實現方式相當的簡潔清晰。

0x04.3 小米快速配置協議加密方式

小米所採用的協議和其他快速配置協議一樣，沒有直接明文傳輸認證資訊。要解出明文傳遞的Wi-Fi認證資訊，就需要逆向應用得到具體的加密方式。這裡給出在完成逆向後得到的資料加密方式（簡略版）：

1. 將SSID，Wi-Fi密碼，MAC地址和無線網路加密型別四個資料變形聚合(MiioLocalAPI)
2. 透過System. currentTimeMillis()獲取當前時間作為seed值，和上一步獲取的聚合資料一起作為兩個引數傳入libmiio.so下的smencrypt函式

3. 在smencrypt函式中，用seed值對一個固定16位元組長的magic陣列做一個位元組的變形，之後連同聚合資料一同傳入AES_cbc_encrypt函式進行AES128加密。AES演算法所使用的Key和IV都來源於這個magic陣列：

   Key = MD5_hash(magic_data, 16)
   IV = MD5_hash(Key + magic_data, 32)
   

   magic_data的內容為：

   0x20, 0x59, 0x5C, 0xD3, 0x24, 0x10, 0x5D, 0x54, 
   0x14, 0xC6, 0xD4, 0xE3, 0xC8, 0x80, 0xC6, 0xF0
   

這樣就得到了加密後的資料，解密需要反向操作。由此可以看到，在金鑰和時間已知的情況下，如果使用預設的傳輸方式，三方可以獲取明文的Wi-Fi認證資訊。

0x05 應對

---

對於此類快速配置協議，在金鑰的選擇上最好做到每個裝置有不同的金鑰。交換金鑰的方式可以是將金鑰以二維碼的方式貼上在裝置上(裝置內已儲存有一份)，配置時用移動端應用去掃描獲取，完成金鑰交換。或者直接使用範圍更小的通訊方式交換Wi-Fi認證資訊。

0xFF 版權

---

本文獨家首發於烏雲知識庫(drops.wooyun.org)。本文並沒有對任何單位和個人授權轉載。如本文被轉載，一定是屬於未經授權轉載，屬於嚴重的侵犯智慧財產權，本單位將追究法律責任。