論文題目：Discovering and Understanding the Security Hazards in the Interactions between IoT Devices， Mobile Apps， and Clouds on Smart Home Platforms

論文作者： Wei Zhou， Yan Jia， Yao Yao， Lipeng Zhu， Le Guan， Yuhang Mao， Peng Liu and Yuqing Zhang

作者單位：中國科學院大學國家入侵防范中心，西安電子科技大學，美國佐治亞大學，美國賓夕法尼亞州立大學

論文地址：https://www.usenix.org/system/files/sec19-zhou.pdf

一、物聯網云平臺架構

現階段隨著物聯網技術的發展，智能家居也得到了廣泛應用。為了方便集中管理眾多的智能家居設備，國內外許多知名的IT廠商如三星、阿里巴巴、京東和小米等均推出了自己的智能家居云平臺。雖然各家廠商在實現上有細節上的差別，但整體架構基本相似。如圖1所示，云平臺主要包括三大交互實體(云服務，移動端APP，物聯網設備)。云服務作為整個智能家居云平臺的核心主要負責設備管理，遠程指令轉發以及設備聯動服務等；物聯網設備常見有兩種連接云的方式，對于有具備互聯網功能的設備大多可以直接和云服務建立連接，而對于只能通過zigbee或者藍牙的連接的小型設備需要通過一個中間路由(Gateway/Hub)來和云進行交互；最后，移動APP端為用戶提供操作設備的接口如連接、斷開和注銷設備等。

另一方面為了方便對大量的物聯網設備進行部署，這些智能家居平臺往往會開發設備端交互SDKs包括一些常用的交互指令和協議實現，這樣物聯網設備應用開發的時候只需要將這些SDK和特定的設備功能進行結合即可，大大縮短了設備開發周期。

圖1 云平臺整體架構

二、常見物聯網云平臺交互過程

通過進一步對云平臺三方交互過程的進一步分析，論文總結常見設備使用周期(從設備首次連接到設備注銷)過程中涉及的基本交互步驟。注：由于在設備注冊和綁定步驟實現上的差別本文將云平臺分為了兩類，但其原理相似，本文只介紹其中的Type1，另一種詳見論文。

1.設備發現：APP 一般通過廣播的方式和設備進行識別和連接。

2.提供WIFI證書：為了使設備可以通過互聯網和云服務進行交互，APP需要向設備提供Wi-Fi證書，其主要方法包括自建熱點、Wi-Fi直連和 SmartConfig。

3.設備注冊：設備通過向云發送其獨一無二的物理信息如MAC地址來完成設備注冊，并從云端獲取設備標識碼device ID。云端也會記錄此ID作為此設備的標識用于后續交互。

4.設備綁定：為了保證只有設備所有者有控制對應設備的權限，用戶需要通過APP申請設備綁定。從而云將此用戶信息和設備device ID進行一一綁定。后續云平臺只允許此用戶才可以控制對應ID的設備，拒絕其他用戶對用戶對此ID設備的控制命令。

5.設備登錄：完成設備綁定后，設備申請和云建立并維持一個長連接，同時，如果發現長時間和云沒有交互會自動重新進行連接。

6.設備使用：完成1-5步驟后，設備處于正常工作狀態可以接受并執行云和用戶的遠程操作指令。

7.設備注銷：當用戶不想再使用此設備如轉讓給他人，其可以用APP向云發送申請解綁設備的操作從而云平臺解除其與設備的綁定關系，并重置設備使三方實體均回到初始狀態。

通過分析每個步驟中智能家居平臺三方實體的交互過程，從而得到三方實體各自交互過程中導致的正常工作狀態的轉換模型如圖2所示，注意：三方實體的工作狀態并不是相互獨立而是通過交互存在一定的對應關系。

圖2 轉換模型

注:紅色代表Type1智能家居平臺特有的交互請求和狀態，藍色代表Type2智能家居平臺特有的交互請求和狀態，黑色代表共有的交互請求和狀態。

三、云平臺安全分析方法

首先為了分析三方交互的細節，論文采用逆向、中間人和其他證書繞過等方法解密了三方通信。然后為了檢查云平臺三方交互過程中是否存在異常請求和工作狀態，需要發送非正常的設備請求。為了實現此目的，論文通過利用和修改原有通信SDK，構建一個模擬真實設備交互的“幽靈”設備，從而實現無論云和APP處于任何狀態，都可以發送任意設備請求。

四、漏洞總結與分析

通過對云平臺認證、授權和狀態管理的實驗，論文在五大知名智能家居平臺發現了如下四種常見的安全漏洞，如圖3所示。

圖3 四種常見的安全漏洞

F1不充分的狀態防護：通過實驗發現，云平臺在接受設備請求的時候，并不檢查此時設備以及自身的工作狀態。例如當云處于綁定后的正常工作的狀態，其仍然可以接受相同設備的申請注冊的請求(F1.1)，并返回相同的device ID。相似的云也可以接受F1.2設備綁定(Only in Type 2 platform)和F1.3設備登錄請求。

F2異常工作狀態組合：在背景中介紹的，在正常工作狀態時，三方實體的工作狀態并不是相互獨立的而是存在一定的對應關系。例如待設備完成綁定登錄后，三方實體均應維持在其Running狀態。但通過實驗測試，論文發現在某些條件下，三方的工作狀態并總是這樣的規律。如果在用戶在APP段發送解綁設備請求到云以后，但未重置設備。此時，某些云平臺雖然解除了用戶和設備的綁定關系，但仍然和設備處于連接關系，也就是此時設備仍然處于running狀態，仍然可以接受遠程指令，但云和APP已經回到了初始工作狀態。

F3未授權用戶登錄：通過實驗發現，某些云平臺只對于敏感操作對設備請求進行授權驗證，而對于其他的設備操作并不會對其進行授權驗證。

F4未授權用戶解綁：論文還發現某些平臺不僅支持從APP端發送解綁設備的請求，同時設備端也可以發送解綁請求，而對于設備端的解綁請求往往也并不會驗證用戶信息。

五、漏洞組合利用

論文通過巧妙的組合利用這些漏洞可以實現一系列的遠程攻擊如表1所示，本文這里選取其中Type1平臺上最具代表性和嚴重的設備劫持和設備“替換攻擊”進行介紹。對于其他攻擊，感興趣的讀者可以查看原文。

表1 遠程攻擊

1. 設備身份“替換”攻擊

如圖4所示從左到右依次代表的實體為攻擊目標的真實設備，使用此設備的用戶Alice、云服務、攻擊者Trudy， 受攻擊者控制可以發送任意設備請求的“幽靈設備”。

攻擊步驟：T.1：首先在用戶完成A.1 到A.3正常用戶的初始化操作后，此時攻擊者利用幽靈設備發送相同的設備注冊請求到云，由于漏洞F1.1，云會接受此請求并返回和真實一樣的device ID到幽靈設備。

T.2：幽靈設備利用此設備ID頻繁的去和云建立和維持鏈接(F3和F1.3)，由于幽靈設備和真實設備的ID一樣，而相同的device ID云只維持一條鏈接，從而攻擊者利用幽靈設備“擠掉”了原來的真實設備。此時，用戶在APP端雖然看見設備仍然保持在線，但此時和云建立連接的已經從真實設備被替換為被攻擊者控制的幽靈設備。

攻擊影響：1)由于此時用戶實際控制的設備變成了幽靈設備，攻擊者可以利用此漏洞去收集用戶發送給設備的任何請求，從而竊取和分析用戶的一些生活習慣。比如用戶每次大概在什么時間去打開和關閉家中的智能插銷，從而判斷用戶的在家時間。

2)攻擊進一步可以利用偽造的幽靈設備來上傳虛假設備信息從而產生更為嚴重的危害。現在許多云平臺均支持一些設備聯動的自動化控制，比如當煙霧器報警后自動打開屋內的門窗。而攻擊者通過幽靈設備替換真的煙霧報警器并和云建立連接后，上傳一個超過報警閾值的濃度，云會根據用戶設定的聯動規則自動打開門窗。

圖4 實體為攻擊目標的真實設備

2. 設備劫持攻擊

如果此云平臺還存在F4和F2的漏洞，攻擊者可以在上一個設備身份替換攻擊的基礎上進一步實施設備劫持攻擊。

攻擊步驟：T3：當幽靈設備和云建立連接后，其可以向云發送解綁請求。由于F4，云會無條件接受此請求， 從而解綁了原始用戶但仍然保持著和幽靈設備的連接(F2)。

T4：由于此時云回到了初始狀態處于未有用戶綁定的狀態，攻擊者可以發送設備綁定請求，云會將此設備ID的所有權轉為攻擊者所有。然后攻擊者只需要斷開幽靈設備，真實設備會自動重新連接云。此時，攻擊者就可以遠程控制用戶的真實設備，完成設備劫持。

攻擊危害：攻擊者可以通過遠程劫持用戶的敏感設備如攝像頭等從而直接竊取用戶隱私。同時，雖然用戶可以發覺自身設備的異常操作，但在APP端并沒有任何攻擊痕跡，所以用戶一般認為是設備或者云故障，很難察覺設備已經被攻擊者控制。

六、緩解方案

論文最后簡單提及一些有效的緩解方案，如在設備注冊和登錄階段增加隨機數以及證書來加強認證。同時，設備狀態的同步和管理往往被智能家居平臺所忽略，因此論文建議在三方交互過程中也應傳遞各自的此時工作狀態的信息，然后云作為中心對三方的工作狀態進行實時的監控和管理，從而防止攻擊利用非正常的工作狀態來實施非法操作。

作者簡介：周威，中科院大學國家網絡入侵防范中心在讀博士生。研究領域包括物聯網安全、嵌入式系統安全、可信計算等，在Usenix、ESORICS等國際學術會議和期刊發表論文近10篇。

相關閱讀：

【InForSec通訊】證書透明化CT機制的Monitor可靠性研究 | CCS 2019

點擊，查看論文原文！

總結

以上是生活随笔為你收集整理的华为智能家居app未能连接上远程云服务_【InForSec通讯】智能家居云平台实体间交互状态安全分析 | Usenix2019...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。