作者：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.#/learning/detail/163.html

而局域網和互聯網通信內容又大相徑庭,即使設計了一個良好的互聯網通信模型，也會被找到破綻。

0x04 總結

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

已有的改進

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

尚存或演進的問題

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

這些存在漏洞的點都很普遍并容易被探測和發現,而造成的危害和損失卻是巨大的

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

過去的事件都以在公網上的設備受到攻擊而需求感染設備去掃描發現新的設備，而現在只要一攻破上述任一一條，則可以在存在RCE等高危漏洞情況下迅速感染所有在網設備，攻擊的成本大為降低。對于IoT安全社會各界應該予以更為重復的重視。

0x05 參考

  1. http://bobao.#/learning/detail/3143.html
  2. http://www.bjnorthway.com/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.#/learning/detail/4635.html

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