IOT安全:Logitech Harmony Hub安全性分析
一、前言
FireEye的Mandiant Red Team最近在Logitech Harmony Hub物聯網(IoT)裝置上發現了一些漏洞,這些漏洞可以被攻擊者利用,透過SSH渠道獲得目標裝置的root訪問許可權。Harmony Hub是一款家庭控制系統,用來連線並控制使用者家庭環境中的各種裝置。在本地網路中利用這些漏洞後,攻擊者可以控制連線到Hub的裝置,也可以利用Hub做為執行節點,攻擊本地網路中的其他裝置。由於Harmony Hub所支援的裝置較多,包括智慧門鎖、智慧恆溫器以及其他智慧家居裝置等,因此這些漏洞會給使用者帶來極高的風險。
FireEye在2018年1月向Logitech披露了這些漏洞,Logitech積極響應,與FireEye一起溝通協作,釋出韌體更新(4.15.96)解決了這些問題。
Red Team發現瞭如下幾個漏洞:
1、未驗證證書有效性;
2、不安全的更新過程;
3、生產韌體映象中遺留開發者(developer)除錯符號;
4、空的root使用者密碼。
Red Team組合使用了這幾個漏洞,最終獲得了Harmony Hub的管理員訪問許可權。在本文中我們介紹了這些漏洞的發現及分析過程,與大家分享了對消費者裝置進行嚴格安全測試的必要性:現如今公眾對裝置越來越信任,而這些裝置不僅連線到家庭網路中,也會透露關於公眾日常生活的各種細節,此時安全形勢也更加嚴峻。
二、裝置分析
裝置準備
已公開的一些研究報告表明,Harmony Hub的測試點上存在一個UART(universal asynchronous receiver/transmitter,通用非同步收發傳輸器)介面。我們將跳線連線到這些測試點上,這樣就能使用TTL轉USB序列線路連線到Harmony Hub。初步分析啟動過程後,我們發現Harmony Hub會透過U-Boot 1.1.4啟動,執行一個Linux核心,如圖1所示。
從UART介面獲得的啟動日誌
在啟動過程後續階段中,控制檯不再輸出任何資訊,因為核心並沒有配備任何控制檯介面。我們在U-Boot中重新配置了核心啟動引數,想檢視完整的啟動過程,但並沒有恢復出有用的資訊。此外,由於裝置將UART介面配置成僅傳輸模式,因此我們不能透過該介面與Harmony Hub進一步互動,因此我們將研究重點轉移到了Harmony Hub所執行的Linux作業系統上,想進一步瞭解整個系統以及其上執行的相關軟體。
韌體恢復及提取
Harmony Hub可以使用配套的Android或者iOS應用透過藍芽來進行初始化配置。我們使用hostapd建立了一個無線網路,在Android測試裝置上安裝了Burp Suite Pro CA證書,以捕捉Harmony移動應用發往網際網路以及發往Harmony Hub的通訊流量。一旦初始化配對完成,Harmony應用就會搜尋本地網路中的Harmony Hub,使用基於HTTP的API與Harmony Hub通訊。
一旦成功連線,Harmony應用就會向Harmony Hub的API傳送兩個不同的請求,以便Harmony Hub檢查是否存在更新,如:2所示。
圖2:使Harmony Hub檢查更新的請求報文
Harmony Hub會向Logitech伺服器傳送當前的韌體版本,以確定是否存在更新(如圖3所示)。如果需要更新,Logitech會傳送一個響應包,其中包含新韌體版本所對應的一個URL(如圖4所示)。由於我們使用了自簽名的證書來捕捉Harmony Hub傳送的HTTPS流量,因此我們可以順利觀察到這個過程(Harmony Hub會忽略無效的SSL證書)。
Harmony Hub檢查韌體更新
圖4. 伺服器返回的響應包中包含更新韌體的URL
我們獲取了這個韌體並檢查了相關檔案。剝離好幾個壓縮層後,我們可以在harmony-image.squashfs檔案中找到韌體。韌體所使用的檔案系統映象為SquashFS檔案系統,採用lzma壓縮演算法(這是嵌入式裝置常用的壓縮格式)。然而,廠商經常使用老版本的squashfstools,這些版本與最新的squashfstools並不相容。我們使用了firmware-mod-kit中的unsqashfs_all.sh指令碼,自動化探測unsquashfs的正確版本,以便提取檔案系統映象,如圖5所示。
圖5. 使用firmware-mod-kit提取檔案系統
提取檔案系統內容後,我們檢查了Harmony Hub搭載的的某些詳細配置資訊。經過檢查後,我們發現這個生產映象中包含大量的除錯資訊,比如沒有刪掉的核心模組等,如圖6所示。
圖6. 檔案系統中未刪掉的Linux核心物件
檢查/etc/passwd後,我們發現root使用者並沒有設定密碼(如圖7所示)。因此,如果我們可以啟用dropbear SSH伺服器,我們就能透過SSH介面獲取Harmony Hub的root訪問許可權,無需使用密碼。
圖7. /etc/passwd檔案顯示root使用者未設定密碼
我們發現,如果檔案系統中存在/etc/tdeenable檔案,則會在初始化階段中啟用dropbear SSH伺服器,如圖8所示。
圖8. 如果存在/etc/tdeenable,/etc/init.d/rcS指令碼則會啟用dropbear SSH伺服器
劫持更新過程
在初始化過程中,Harmony Hub會在Logitech API上查詢GetJson2Uris地址,獲取各種過程所需的一個URL列表(如圖9所示),其中包括檢查韌體更新所使用的URL以及獲取更新所需的額外軟體包資訊的URL。
圖9. 傳送請求獲取各種過程所需的URL地址
我們攔截並修改了伺服器返回的響應資料包中的JSON物件,將其中的GetUpdates成員指向我們自己的IP地址,如圖10所示。
圖10. 修改過的JSON物件
與韌體更新過程類似,Harmony Hub會向GetUpdates所指定的端點傳送一個POST請求,請求中包含裝置內部軟體包的當前版本資訊。HEOS軟體包對應的請求如圖11所示。
圖11. 包含系統中“HEOS”軟體包當前版本資訊的JSON請求物件
如果POST請求正文中的sysBuild引數與伺服器已知的當前版本不匹配,伺服器就會響應一個初始資料包,其中包含新軟體包版本資訊。由於某些不知名的原因,Harmony Hub忽略了這個初始響應包,傳送了第二個請求。第二個響應包中包含多個URL地址,這些地址指向了新的軟體包,如圖12所示。
圖12. 包含軟體更新包的JSON響應資料
我們下載了響應資料包中列出的.pkg檔案,檢查後發現這些檔案其實是ZIP壓縮檔案。壓縮檔案的檔案結果比較簡單,如圖13所示。
圖13. .pkg壓縮文件結構
其中,manifest.json檔案可以告訴Harmony Hub在更新過程中如何處理壓縮文件的內容,如圖14所示。
圖14. manifest.json檔案內容
manifest檔案中installer引數所指定了一個指令碼,如果壓縮檔案中存在該指令碼,那麼Harmony Hub在更新過程中就會執行這個指令碼。我們修改了這個指令碼,如圖15所示,修改後該指令碼會建立/etc/tdeenable檔案,前面提到過,這樣啟動過程就會啟用SSH介面。
圖15. 修改後的update.sh檔案
我們建立了帶有.pkg副檔名的一個惡意壓縮文件,使用本地web伺服器託管該文件。當下一次Harmony Hub根據被篡改的GetJson2URIs響應包中給出的URL地址來檢查更新時,我們返回經過修改的響應包,指向這個更新檔案。Harmony Hub會接收我們提供的惡意軟體更新包,重啟Harmony Hub後就會啟用SSH介面。這樣我們就可以使用root使用者名稱以及空密碼來訪問該裝置,如圖16所示。
圖16. 重啟後裝置啟用了SSH介面
三、總結
隨著科技逐步融入我們的日常生活中,我們也在不知不覺中越來越信任各種裝置。Harmony Hub與許多物聯網裝置一樣,採用了通用處理器架構,因此攻擊者可以輕鬆將惡意工具新增到被攻破的Harmony Hub上,進一步擴大攻擊活動的影響力。Logitech與我們的團隊積極合作,釋出了4.15.96韌體解決了這些漏洞。如果使用者對某些裝置非常信任,那麼這些裝置的開發者就應該保持警惕,移除讓使用者處於危險境地的潛在攻擊因素。Logitech在與Red Team的研究工作中發表過一則宣告,在此我們也想與大家一起分享:
“Logitech非常重視客戶的安全及隱私。2018年1月下旬,FireEye發現了可能影響Logitech Harmony Hub產品的一些漏洞,如果某個惡意駭客已經獲取Hub使用者網路的訪問許可權,就可以利用這些漏洞。我們非常感謝FireEye等專業安全研究公司在挖掘探索IoT裝置上這類漏洞所付出的努力。
在FireEye將這些研究成果告知我們後,我們第一時間啟動了內部調查,並且馬上開始研發韌體以解決這些問題。4月10日,我們釋出了韌體更新,全部解決了這些漏洞。如果還有客戶沒有將韌體更新到4.15.96版,我們建議您檢查MyHarmony軟體,同步基於Hub的遠端裝置並接收該韌體。使用者可以檢視此連結瞭解關於韌體更新的完整說明。
基於Hub的產品包括: Harmony Elite、Harmony Home Hub、Harmony Ultimate Hub、harmony Hub, Harmony Home Control、Harmony Pro、Harmony Smart Control、Harmony Companion、Harmony Smart Keyboard、Harmony Ultimate以及Ultimate Home”。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31510736/viewspace-2154490/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 4A安全性分析
- HackPwn2015:IoT智慧硬體安全威脅分析
- 微信安全嗎?微信MMTLS加密協議安全性分析TLS加密協議
- 物聯網作業系統安全性分析作業系統
- 架構安全性設計、部分示例及原理分析架構
- 新的Soracom服務可加速IoT資料流,提高安全性並降低成本Sora
- 利用ELK協助安全性攻擊的資料分析
- 抖音與TikTok的安全性和隱私分析 - citizenlab
- API的安全性API
- IT安全性如何提高
- 對 Chamberlain MyQ 車庫門智慧開關的安全性分析AI
- STARTTLS在電子郵件環境中的安全性分析TLS
- Android P 安全性更新Android
- Web安全性測試Web
- 安全性偏好設定
- 執行緒安全性執行緒
- 資料庫安全性資料庫
- PHP安全性漫談PHP
- 智慧合約安全性
- Harmony_認證
- Java++:安全|API介面安全性設計JavaAPI
- 二、執行緒安全性執行緒
- 終端機的安全性
- jenkins 禁用指令碼安全性Jenkins指令碼
- SATA如何提高安全性?
- 在Kibana中配置安全性
- [原始碼分析] 訊息佇列 Kombu 之 Hub原始碼佇列
- 騰訊安全正式釋出《IoT安全能力圖譜》
- ArkWeb高階安全模式 - 提升應用安全性Web模式
- OS + hongmeng / harmony os / ArkTS
- Splunk為歐洲汽車製造商提供安全性分析解決方案
- 如何保證MongoDB的安全性?MongoDB
- API介面安全性設計思路API
- Spring Boot 安全性最佳實踐Spring Boot
- mORMot 1.18 第19章 安全性ORM
- 電商網站的安全性網站
- 反向代理的安全性高嗎?
- 02. 執行緒安全性執行緒