IoT 設備通訊安全討論

IoT 設備通訊安全討論

 

做者：360CERT

0x00 序言

IoT 設備日益增多的今天，以及智能家居這一話題愈發火熱，智能家居市場正在飛速的壯大和發展，無數 IoT 設備正在從影片中不斷的走向用戶的身邊。可是這其中卻擁有着大量的安全問題和隱患。

這次以結合實際案例的方式來談一談目前國內 IoT 市場中廣泛存在的安全問題。

0x01 歷史回顧

在過去的一段時間內也曾暴露出了不少不少的 IoT 設備的安全問題。

能夠看到自15年開始就頻繁受到廣大的黑/白帽子的關注了：

Mirai

而在去年2016年9月-10月期間Mirai在全球範圍內爆發。

Mirai 的感染模式

• 感染初始設備
• 初始設備在網段內進行掃描，並作嘗試，將有漏洞的設備 IP，PORT 等信息上傳至 Loader 服務器
• Loader 服務器對新的設備進行控制並下發控制程序
• 循環往復
• 受控設備足夠多後，控制設備對 Victim 發起 DDoS

直到2016年10月26日，咱們經過 Mirai 特徵搜索 shodan 發現，當前全球感染 Mirai 的設備已經超過100萬臺，其中美國感染設備有418,592臺，中國大陸有145,778臺，澳大利亞94,912臺，日本和中國香港分別爲47,198和44,386臺。

IoT reaper

而最近則是 IoT reaper，從2017-09-13開始，360NetLab捕獲到了一個新型的針對 IoT 設備的惡意樣本

樣本中集成了9個 IoT 漏洞 IoT_reaper 徹底放棄了 mirai 中利用弱口令猜想的方式，轉爲利用 IoT 設備的漏洞植入，當前樣本中集成了了9個 IoT 設備漏洞。最近十天以來，攻擊者正在積極的將漏洞利用集成進入樣本中，其中一個漏洞在公開後僅2天就被集成。

IoT_reaper 感染流程圖

IoTroop 是 IoT_reaper Botnet 在網絡攻擊活動中第一階段使用的主要 payloads，該惡意軟件借用了 mirai 的源代碼，可是在幾個關鍵行爲上顯著區別於 mirai，包括：

1. C&C 服務器已經徹底被從新設計，並使用了新的後臺。 另外，IoTroop 的 C&C 服務器是用PHP編寫的，而原來的 Mirai C&C 服務器是用 GO 編寫的。
2. 隨着 C&C 後臺的變化，C&C 通訊協議也發生了變化，IoTroop 惡意軟件使用了全新的 C&C 通訊方式。
3. IoTroop 惡意軟件再也不使用弱口令猜想、而是使用 IoT 設備漏洞，掃描效率大大提升。
4. IoTroop 惡意軟件不包含任何 DDoS 功能，實際上咱們也沒有觀察到與該惡意軟件有關的任何 DDoS 攻擊，但全部與 DDoS 相關的功能都由 C&C 後臺進行協調和管理，並做爲單獨的模塊下載。

IoT_reaper 包含的一些漏洞

能夠看到的是，IoT 設備的安全問題正在日益突出，並日益嚴重。

雖然廠商心中已經有了必定的警惕，並採起了必定的措施可是還遠遠不夠。

0x02 現狀

攻擊中最複雜的部分是取得與相關設備的鏈接問題，只要可以鏈接上可以與之通訊,能夠說被控制被劫持都只是一些相對較小的問題了。

在鏈接上的安全措施每每是難以作到盡善盡美的，那麼咱們就着重來看看目前國內市場上IoT設備在鏈接上存在的諸多問題。

在 iot 設備領域存在一個是否致命的問題，就是產品更迭週期，在此領域由於涵蓋着硬件設備，在升級上每每難以針對某些領域的問題進行修復。

目前在國內的形式大多數是採用的多方合做，而雜合而成的一個十分混亂的 iot 生態。

1. A廠商從B廠商處採購主控芯片和開發套件，而後本身由這個主控芯片和開發套件對一些傳感器進行集成鏈接，進行一些簡單的包裝。
2. A廠商和C廠商進行深度合做在A廠商的APP中集成C廠商的控制程序，從而實現A廠商具備更爲廣大的智能家居生態。
3. A廠商完成了硬件上的設計生產，而APP方面則採起外包方式獲取。
4. 爲了照顧設備的網絡狀況以及性能狀況做出的妥協。

在國內上述三種狀況是十分廣泛的，這種樹狀甚至是叉裝的生態環境勢必會產生無數的安全問題。

反過來回顧世界前列的互聯網公司裏 Apple，是惟一的一家最接近垂直生態公司，即便是這樣，每一年也有大量的漏洞被發現，就更況且國內的這些公司了。

0x03 分析

與上面的點一一對應

1.因爲採用採購和使用開發套件的方式,勢必會有大部分的邏輯是和供應商所提供的運行模式和設計理念是一致的,從這裏入手就很容易看到對應的A廠商的設備的大體工做模式

實例：

根據上面的文檔能夠看出這裏設計出了一種工做模式，在智能硬件中會有一份主體固件 user1.bin，而後在後期能夠經過 user2.bin 的方式對設備進行必定程度的更新。

爲何要說必定程度呢？首先，這裏採用這種模式就確定是爲了減小更新完整固件包所帶來的更新時間和下載內容大小，也從而被得到後直接逆向出完整設備工做流程的危害。

• iot設備大多采用低成本的處理控制單元和極小的板載存儲flash芯片,已經極小的內存容量,若是採起互聯網全量更新,首先是機器自己沒法存儲,處理器,和內存也沒法勝任此工做
• iot設備爲了長期穩定的工做,確定沒法去更新核心部分的工做,只會以修復一些細小的功能性問題而更新

那這裏從實際的案例出發對這個現象的論證就是

在2015年的A廠商在通訊過程當中使用的AES加密,但在APK中因爲開發沒有良好的安全意識,致使被輕易的提取出了AES的密鑰,而在咱們進行分析的今天,該廠商的密鑰也沒有更換,亦能夠在網上搜索獲得這串長期沒有更換的密鑰進行通訊消息的解密

而在今天廠商也僅僅只是將其放在了一個動態連接庫中稍加混淆

就這樣一個問題,在一個廠商長髮2年都沒有一個良好的解決方案足以說明問題的嚴重性

2.在廠商與廠商的合做之間勢必會相互開放sdk或者api接口以及通訊密鑰,一系列相關資源,這就致使了,但凡是有一家合做廠商的安全作的不夠出色這就會致使短板效應的出現而致使拉低了衆多廠商的安全等級

A廠商和C廠商的合做使得A廠商幾乎只承擔的了集成SDK的成本就得到了一項智能家居產品，而C廠商也僅僅是提供了SDK就拓寬了本身的銷售渠道，這樣的合做模式確定受到雙方歡迎的，可是這之間的安全問題是值得關注的。

• 通訊的密鑰
• 身份TOKEN
• 完整的設備信息
• 完整的控制請求

根據上述的問題,再結合必定的分析每每就能很容易的得出一份使人滿意的漏洞

實例:

能夠很清晰的看到,擁有SDK的TOKEN,完整的控制函數

能夠看到通訊的地址,以及通信認證的詳細過程

能夠看到另外一家合做廠商的密鑰位置

3. APP的編寫,這明顯不是傳統的硬件廠商所擅長的,而外包基本成了主要解決辦法

然而廠商也自身沒有過高的安全意識在驗收成果的時候,主要着力於功能的完善狀況,以及界面交互是否有效上面這就會致使許多隱患

• 通訊模型設計不當
• 驗證認證流程存在繞過,或極不完善
• 查詢接口權限認證粗糙
• 涉及服務器敏感信息泄露

這諸多問題都是一個個良好的突破口和值得關注的點

實例:

從這裏能夠看到從 apk 中加載了通訊使用的證書，故能夠從 apk 中提取出來，也涉及了服務器的通訊地址和端口

能夠看到另外一處TCP直接通訊的地址和端口

這裏能夠看到，單憑一個手機號就獲取了大量設備關鍵信息,包括密碼等

這裏能夠看到，以任意設備mac來獲取對應的用戶手機號的操做

再根據已掌握的信息，進行設備控制指令的生成也是十分簡單

4. 在結合國內的平均網絡質量在全球排名處於中下游水平的狀況下,而且要照顧多地區的複雜網絡環境

在與智能硬件的通訊過程當中勢必會有不少的妥協,由於產品的第一點是務必知足有良好的用戶體驗

進而就會產生

• 與服務器通訊認證手段單一
• 身份識別過程簡單
• 消息內容格式化程度高
• 分兩套通訊手段,一套局域網,一套互聯網
• 服務器通訊內容不認證用戶身份

實例:

A廠商在爲了解決遠程控制這一問題上

互聯網層面遠程控制由XMPP協議進行通訊

但國內的廠商在使用上僅僅着手於XMPP協議的及時性和開放性,對於一些必要的安全措施並無進行良好的設計

A廠商的XMPP的設計模式下,受控端設備,以及控制端設備全憑MAC地址或是UUID做爲登陸憑據,而且在密碼設計上採用與用戶名同樣的方式.這就致使可使用遍歷MAC地址的方式將該廠商全部設備踢下線,使其沒法正常通訊或是響應命令.或是在APP端註冊一個帳號,而後得到UUID即可以向任意在網設備發送控制指令,這對於智能產品來講危害是巨大的,也會致使用戶沒法得到正常的體驗

A廠商該特地設計了一個控制服務器,來接受和記錄設備的綁定以及設備狀態查詢的服務,該服務器沒有任何權限設置,亦無token之類的校驗,能夠抓包後任意重放,來得到任意設備mac所綁定的用戶手機號,同時,還有一個邏輯錯誤,以及一個重大的安全錯誤

• 在服務器上存儲用戶設備控制密碼
• 對設備控制權限變動無校驗,任何人能夠在任何狀況下對設備進行從新綁定,解綁,添加信任用戶等危險操做
• 並在特殊的構造下,能夠直接獲取到任意設備的控制密碼

在通訊過程當中消息內容採用固定格式wan_phone%015bee58-xxxx-xxxx-xxxx-31598127xxxx%password%open%relay

能夠看到中間的uuid做爲標識password是控制密碼open是控制指令

那麼其實很好類推關閉之類的指令

在APP的登陸過程當中,用戶名爲手機號

局域網內採用UDP無鏈接通訊,經過向設備發送連續的UDP包來得到設備信息,同時爲了更快的感同一局域網內的設備狀態,採用廣播心跳包的形式對全部在網內設備進行查詢,同時全部設備收到此包後會回覆本身的狀態,以及控制密碼的值,來確保用戶能完成良好的控制

其次在標識上僅使用mac地址做爲標識,這就致使,若是在相同包體裏改變mac地址便可完成對設備的控制。

能夠經過分析流量翻譯出大量的操做指令

可看到流量中連續的廣播包在發送

廣播後,設備響應,解密後就能直接獲得設備的控制密碼

用腳本直接解密XMPP流量

[破解案例] : http://bobao.360.cn/learning/detail/163.html

而局域網和互聯網通訊內容又截然不同,即便設計了一個良好的互聯網通訊模型，也會被找到破綻。

0x04 總結

根據這次分析，IoT生態混亂，經過實例分析驗證了不少安全問題，以及潛在隱患，對現有用戶會產生用戶敏感信息泄露和IoT設備爲攻擊者大開方便之門的安全問題。最終甚至危害到廣大用戶的人生以及財務安全。

已有的改進

• 儘可能避免了將設備直接暴露在公網中
• 已有一些通訊上的加密措施,再也不是任何人均可以向設備發送消息
• 避免IoT設備的固件開發下載

尚存或演進的問題

• 以CS模式通訊,可是通訊結構和驗證過程過於簡單或沒有,致使一旦攻破即可危害全部在網設備
• APP的安全開發意識十分薄弱
• 廠商合做之間的信任鏈單一,信任關係簡單
• 多模式設計下,短板效應明顯,在某一模式安全性的缺失則致使整套安全系統崩潰
• 對用戶信息,設備的存儲和查詢,存在致命的缺陷,對用戶信息無任何保護手段,很容易得到設備用戶的對應關係

這些存在漏洞的點都很廣泛並容易被探測和發現,而形成的危害和損失倒是巨大的

而拋開技術上的問題，在實際的物理世界中，核心的問題在於廠商不夠重視安全，沒有一個很好的統一解決方案，對應漏洞反應平平，甚至予以忽視，致使IoT安全漏洞和事件頻發，各類黑天鵝事件告急。

過去的事件都以在公網上的設備受到攻擊而需求感染設備去掃描發現新的設備，而如今只要一攻破上述任一一條，則能夠在存在RCE等高危漏洞狀況下迅速感染全部在網設備，攻擊的成本大爲下降。對於IoT安全社會各界應該予以更爲重複的重視。

0x05 參考

1. http://bobao.360.cn/learning/detail/3143.html
2. https://paper.seebug.org/142/
3. http://www.freebuf.com/articles/terminal/117927.html
4. http://blog.netlab.360.com/iot-reaper-a-quick-summary-of-a-rapid-spreading-new-iot-botnet/
5. http://bobao.360.cn/learning/detail/4635.html