每天資訊虹科案例|BusyBox Wget漏洞:一個早就應該解決的問題

菜單

虹科案例|BusyBox Wget漏洞:一個早就應該解決的問題

虹科案例|BusyBox Wget漏洞:一個早就應該解決的問題

前言

最近,虹科工業物聯網團隊在調查客戶裝置韌體出現的常規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 Wget漏洞:一個早就應該解決的問題

事實上,BusyBox的 TLS 庫並不支援證書驗證。原始的 Wget 可以支援,並且必須使用一個明顯的命令列開關(—— no-check-certificate)來進行啟動,以防跳過證書驗證。

這就是BusyBox的漏洞所在。攻擊者可以透過模擬伺服器來攔截 Wget的 HTTPS 請求,或者使用 DNS/ARP 病毒將請求重定向到攻擊者控制的伺服器,或者直接進行網路流量攔截。因為攻擊者並不需要有效的 TLS 證書,所以他們可以用任意檔案來替換請求的下載。

如果被替代的下載包中含有軟體模組或更新項,這可能會直接導致惡意程式碼執行。如果下載包含配置或資料,攻擊者可能惡意影響裝置的功能。即使客戶端在安裝或執行之前檢查了下載檔案的完整性和真實性,攻擊者仍然可能會透過讓客戶端下載無效的多GB檔案或者連線非法伺服器而導致拒絕服務。

虹科案例|BusyBox Wget漏洞:一個早就應該解決的問題

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 Wget漏洞:一個早就應該解決的問題

虹科總結

在這個時代,使用嵌入式裝置時我們都應該明白,為了功能而犧牲裝置安全並向欄位釋出不安全的程式碼是不可行的。

這種做法在很大程度直接導致了物聯網裝置市場安全狀況不佳。當然,高等級、多層次、硬體支援的安全性並不適用於每個產品,因為這涉及到成本和上市時間。但供應商應該期望他們的上游元件,比如像BusyBox的開原始碼維護者,實施建立第一道防線所需的合理安全措施。

虹科案例|BusyBox Wget漏洞:一個早就應該解決的問題

虹科 Vdoo 物聯網裝置安全防護與加固平臺

具有自動安全掃描產品可以幫助客戶建立裝置的安全配置檔案,包括第三方元件可能引入的任何漏洞。從而慎重選擇其元件供應商,而不需要過多的測試人員和團隊。