最近,虹科工業物聯網團隊在調查客戶設備固件出現的常規CVE(CVE-2018-1000500)時發現了一個問題:通常情況下,當檢測到一個會對設備產生嚴重破壞的CVE時,我們會建議客戶對該組件進行升級或使用補丁。但是CVE早在2018年就已經發布,盡管具有8.1的高評分,卻一直沒有被修復,這引起了虹科研究人員的注意。
深入研究后,我們發現最初發布 CVE 的研究人員向維護人員提交過一個代碼補丁,但是由于補丁存在破壞現有的功能的風險,該補丁被拒絕了。下面虹科工業物聯網團隊將會對這個問題進行詳細闡述,首先讓我們簡要回顧一下 BusyBox和受影響的組件BusyBox Wget。
漏洞介紹
BusyBox 工具包在單個可執行文件中實現了大量 Linux 性能,甚至可以替代 Linux init 系統。體積小且具有靈活性的特點使得它在嵌入式設備中很受歡迎。最初的 Wget 是一個應用廣泛的 GNU 實用程序,用于使用命令從Internet服務器中檢索文件,經常用于系統腳本,包括用于軟件更新等。
BusyBox 因為其緊湊的特點取代了 Wget,但它并不支持所有的安全功能和選項。特別是當與不具備有效 TLS 證書的服務器連接時,BusyBox 版本的 Wget 不會對其進行中止,而只會打印錯誤消息并繼續下載。下面是對常規 Wget 和 BusyBox Wget 會產生不同行為的舉例說明:
事實上,BusyBox的 TLS 庫并不支持證書驗證。原始的 Wget 可以支持,并且必須使用一個明顯的命令行開關(-- no-check-certificate)來進行啟動,以防跳過證書驗證。
這就是BusyBox的漏洞所在。攻擊者可以通過模擬服務器來攔截 Wget的 HTTPS 請求,或者使用 DNS/ARP 病毒將請求重定向到攻擊者控制的服務器,或者直接進行網絡流量攔截。因為攻擊者并不需要有效的 TLS 證書,所以他們可以用任意文件來替換請求的下載。
如果被替代的下載包中含有軟件模塊或更新項,這可能會直接導致惡意代碼執行。如果下載包含配置或數據,攻擊者可能惡意影響設備的功能。即使客戶端在安裝或執行之前檢查了下載文件的完整性和真實性,攻擊者仍然可能會通過讓客戶端下載無效的多GB文件或者連接非法服務器而導致拒絕服務。
BusyBox團隊處理方式
BusyBox的維護人員認為,修復Wget并讓設備維持不具備有效TLS證書的情況會堿壞設備的重要功能。這是安全員和工程師之間的常見沖突:安全研究人員將更加愿意為了保障設備安全性而犧牲一些設備現有功能的發揮,而工程師則更傾向于維持設備的功能運作,特別是替代方案會對已經部署在現場的設備功能造成堿壞的情況。
唯一的變化是當檢測到無效的 TLS 證書時,1.29.0版本會添加一條錯誤信息。該錯誤信息會被打印到標準輸出中,但不會在系統日志中留下長久的痕跡,這意味著錯誤可能隨時發生,攻擊者可以利用該設備,而不會被管理員發現。
虹科建議
到目前為止,BusyBox Wget 支持在子進程中啟動 OpenSSL 客戶機來執行 TLS 操作。此客戶端完全支持證書驗證邏輯,該邏輯由命令行選項來控制。因此,虹科建議應用下面的補丁,以便明確地將證書檢查添加到 BusyBox Wget 中。首先,確保設置以下配置標志,這將使BusyBox 使用OpenSSL 的TLS/SSL 客戶端。
CONFIG_FEATURE_WGET_OPENSSL=y
然后應用以下補丁:
index f2fc9e215..6bcc24421 100644--- a/networking/wget.c+++ b/networking/wget.c@@ -662,7 +662,7 @@ static int spawn_https_helper_openssl(const char *host, unsigned port) pid = xvfork(); if (pid == 0) { /* Child */- char *argv[8];+ char *argv[11]; close(sp[0]); xmove_fd(sp[1], 0);
@@ -690,6 +690,11 @@ static int spawn_https_helper_openssl(const char *host, unsigned port) argv[6] = (char*)servername;
} + /* Abort on bad server certificate */+ argv[7] = (char*)“-verify”;+ argv[8] = (char*)“100”;+ argv[9] = (char*)“-verify_return_error”;+ BB_EXECVP(argv[0], argv); xmove_fd(3, 2); # if ENABLE_FEATURE_WGET_HTTPS
應用該補丁后,BusyBox Wget 目前展示正確,在一個無效的證書上停止(盡管帶有一個通用的錯誤消息) :
虹科總結
在這個時代,使用嵌入式設備時我們都應該明白,為了功能而犧牲設備安全并向字段發布不安全的代碼是不可行的。
這種做法在很大程度直接導致了物聯網設備市場安全狀況不佳。當然,高等級、多層次、硬件支持的安全性并不適用于每個產品,因為這涉及到成本和上市時間。但供應商應該期望他們的上游組件,比如像BusyBox的開源代碼維護者,實施建立第一道防線所需的合理安全措施。
虹科 Vdoo 物聯網設備安全防護與加固平臺具有自動安全掃描產品可以幫助客戶建立設備的安全配置文件,包括第三方組件可能引入的任何漏洞。從而慎重選擇其組件供應商,而不需要過多的測試人員和團隊。
責任編輯:haq
-
物聯網
+關注
關注
2909文章
44578瀏覽量
372859 -
虹科電子
+關注
關注
0文章
601瀏覽量
14340
原文標題:虹科案例 | BusyBox Wget漏洞:一個早就應該解決的問題
文章出處:【微信號:Hongketeam,微信公眾號:廣州虹科電子科技有限公司】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論