● 虹科Vdoo安全研究團隊不斷研究領先的嵌入式設備及其供應鏈,在RAUC 嵌入式固件更新框架中發現的重大漏洞——
● CVE-2020-25860是一個潛在的嚴重漏洞,其在RAUC中的 CVSSv3 得分為 8.8。此漏洞存在于 RAUC 的所有版本中,直到 1.5,其中包含補丁。
該漏洞是一個 Time-of-Check-Time-of-Use ( CWE-367 ) 問題允許有權限的攻擊者在固件更新文件被驗證后(但在安裝完成前)覆蓋它,從而允許安裝一個任意的固件更新,繞過加密簽名檢查機制。
● 與供應鏈漏洞一樣,很難準確估計有多少設備受其影響。鑒于RAUC這是一個開源工具,而且許多與供應商沒有關系的不同公司都可以使用它,因此這種估計更加復雜。
RAUC背景
RAUC—Robust Auto-Update Controller,該項目始于 2015 年,被開發為輕量級工具,可為基于 Linux 的嵌入式設備執行故障安全的圖像更新。 RAUC 允許嵌入式 Linux 開發人員在他們的嵌入式設備上集成一個強大的更新客戶端,只需最少的努力,同時避免編寫任何更新代碼。RAUC框架支持許多常見的引導程序(U-Boot、grub等)和存儲技術(ext4、UBIFS等),因此,它試圖盡可能地接近嵌入式設備固件更新的 “統包”解決方案。 RAUC 的主要特性是安全性(原子性、故障安全更新操作)、保障性(加密簽名檢查)和可定制性(在安裝過程中添加用戶掛鉤)。
技術深究
RAUC 使用捆綁文件作為保存新固件的存檔。我們發現在固件升級過程中,此文件可以被攻擊者替換(在初始驗證步驟之后),并且通過這樣做會安裝惡意固件,從而有效地允許攻擊者控制系統。運行rauc install bundle.raucb時RAUC 會運行以下內部函數:
check_bundle() – 使用 openssl 庫調用驗證包
mount_bundle() – 使用“mount”shell 調用掛載包
在這些步驟之后,安裝的包被提取并覆蓋當前固件。關鍵問題在于一旦 check_bundle() 完成運行,捆綁文件就會關閉,并且不會以任何方式保留已驗證的數據。當 mount_bundle()開始運行時,mountshell 調用會導致重新讀取包數據:
gboolean mount_bundle(RaucBundle *bundle, GError **error){...g_message(“Mounting bundle ‘%s’ to ‘%s’”, bundle-》path, mount_point);
res = r_mount_loop(bundle-》path, mount_point, bundle-》size,...gboolean r_mount_full(const gchar *source, const gchar *mountpoint, const gchar* t
gboolean r_mount_full(const gchar *source, const gchar *mountpoint, const gchar* type, goffset size, const gchar* extra_options, GError **error){...if (getuid() != 0) { g_ptr_array_add(args, g_strdup(“sudo”));
g_ptr_array_add(args, g_strdup(“--non-interactive”)); } g_ptr_array_add(args, g_strdup(“mount”));...g_ptr_array_add(args, g_strdup(source));...sproc = r_subprocess_newv(args, G_SUBPROCESS_FLAGS_NONE, &ierror);...
因此——攻擊者可以在調用 check_bundle() 和mount_bundle() 之間切換包文件。這讓攻擊者可以部署任意惡意固件,基本上可以在設備上提供root權限。
圖 :攻擊流程,當進程到達 mount_bundle() 時,攻擊者可以替換包文件,因此 RAUC 將掛載未經授權的包
贏得競爭條件(在檢查/掛載包調用之間替換包文件)的機會非常高,因為在包括shell 調用(“mount”命令)在內的兩個操作之間存在不可忽略的代碼量,這是一個非常緩慢的操作。
觀察到的遠程攻擊場景
盡管在大多數情況下,虹科認為該漏洞可作為本地權限升級加以利用,但我們觀察到一個真實場景,即遠程攻擊者可利用一組默認硬編碼憑據利用該漏洞。目標設備使用了一組默認的硬編碼憑據(用戶名和密碼設置為“admin”),首次登錄時不需要更改這些憑據。這些憑證可以被能夠訪問設備固件的攻擊者輕易提取,或者通過簡單的暴力攻擊來猜測。
查看設備的攻擊面:
目標設備暴露了一個經過認證的 CGI 端點upload.cgi,它允許將任意文件上傳到硬編碼的文件路徑 -/tmp/rauc/bundle.raucb
目標設備暴露了一個經過認證的 CGI 端點install.cgi,該端點運行硬編碼的 shell 命令 -rauc install /tmp/rauc/bundle.raucb
兩個 CGI 端點之間沒有適當的鎖定機制
在這種情況下,攻擊者可以遠程接管設備,只需調用:
upload.cgi 帶有正確簽名的固件
install.cgi
(很快)upload.cgi帶有惡意固件
本地攻擊場景和PoC
假設本地用戶有調用 RAUC 的權限(例如,通過只允許rauc命令的 sudo 配置),但沒有簽署RAUC捆綁包所需的私鑰,利用是沒有價值的:將正確簽名的固件復制到某個路徑,例如: 。/bundle.raucb Invoke RAUC –sudo rauc install./bundle.raucb迅速用惡意的固件替換。/bundle.raucb
如果本地用戶無法調用 RAUC 命令,假設調用 RAUC 命令的特權用戶使用攻擊者可以寫入的路徑,則這種情況也可以被利用。我們開發了一個概念驗證,它利用了這個確切的場景:
PoC 接受要替換的包文件的完整路徑
PoC通過監控一個默認目錄(/mnt/rauc)來等待另一個用戶運行rauc安裝,該目錄在驗證步驟之后但在安裝步驟之前被創建。
一旦驗證結束(目錄被創建),PoC 就會用任意的輸入覆蓋包文件。
攻擊的bundle文件可以被移到正確簽名的bundle文件上(這比在正確的位置寫一個新文件要快)。
作為設備供應商
如何知道設備是否受此漏洞的影響?
可以通過在您的設備上運行此命令來檢查您的RAUC 版本是否存在漏洞:
rauc --version
如果報告的版本低于1.5,則您的設備包含有漏洞的代碼。實際上,只有當本地或遠程攻擊者有可能在安裝捆綁包時修改該文件,該設備才會有漏洞。例如,這可能發生在以下情況:
非特權用戶可以通過sudo機制、setuid機制或任何其他專有機制,以root權限調用rauc命令。例如,/etc/sudoers文件中的以下行將允許“vdoo”用戶以 root 身份調用RAUC:
vdoo ALL=(root) /usr/bin/rauc
rauc install可以由非特權用戶修改的捆綁路徑隨時調用。例如:
/usr/bin/rauc install /tmp/mybundle.raucb
由于/tmp默認情況下是全局可寫的,因此通常任何用戶都可以修改其下的文件。
虹科Vdoo 在其Vision平臺中添加了一個適用性掃描器,可以通過檢測所有RAUC 調用并檢查相關安裝路徑的權限來自動驗證是否發生這種情況,為您的設備保駕護航。
作為資產所有者
如何知道部署的設備是否存在漏洞?
不幸的是,似乎很難判斷此漏洞是否存在,更重要的是,僅僅使用網絡工具或不實際查看設備代碼,就很難適用。
如果您的設備供應商為設備提供了軟件物料清單 (SBOM),請查看是否使用了 RAUC,如果使用了,那么理論上您很可能容易受到攻擊(除非版本明確列為 1.5),因為有漏洞代碼存在。但這并不意味著該漏洞是可利用的。如有需要,請隨時聯系虹科Vdoo為您提供幫助。
如果無法升級RAUC
如何降低風險?
如上所述,這是一個經典的Time-of-Check-Time-of-Use 漏洞,其中攻擊利用非原子性的動作,涉及到對資源的檢查和資源的使用。在這種情況下,進行簽名檢查,用法為安裝/升級。
通過確保安裝是原子性的并且從安全路徑發生,可以減輕攻擊。在運行rauc install之前,將捆綁文件從全局可寫位置復制到安全位置(僅限 root 可寫)并從該路徑運行安裝。使用安全位置的存在作為鎖定機制。這將確保未經授權的用戶(無論是本地還是遠程)無法插手安裝過程。
這可以通過這個示例 shell 腳本來完成:
# Assuming firmware is uploaded to /tmp/uploads/bundle.bin# Assuming /data/fw_upgrade can be written to only by rootif [ ! -e /data/fw_upgrade/bundle.bin ];
then cp /tmp/uploads/bundle.bin /data/fw_upgrade/bundle.bin /usr/bin/rauc install /data/fw_upgrade/bundle.bin rm /data/fw_upgrade/bundle.binfi
請注意,在使用像Yocto這樣的構建系統時,更改安裝腳本可能并不比切換到固定的RAUC版本容易得多。
﹀
﹀
﹀
附錄-虹科Vdoo安全性防護平臺
虹科Vdoo是端到端的產品安全分析平臺,在整個產品生命周期中自動化所以軟件安全任務,確保所有安全問題得到優先處理、溝通和緩解。垂直無關的平臺使各種行業的設備制造商和部署者能夠跨多個業務線擴展其產品安全功能。虹科Vdoo自動保護連接產品的方法使客戶大大縮短了上市時間,減少了資源需求,增加了銷售量,降低了總體風險。
責任編輯:haq
-
嵌入式
+關注
關注
5082文章
19111瀏覽量
304856 -
虹科電子
+關注
關注
0文章
601瀏覽量
14340
原文標題:虹科方案 | 虹科Vdoo安全平臺-在 RAUC 嵌入式固件更新框架中發現的重大漏洞
文章出處:【微信號:OPPOOIA,微信公眾號:OPPOstory】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論