虹科方案 | 虹科Vdoo安全平台:CVE-2020-25860 - 在 RAUC 嵌入式固件更新框架中发现的重大漏洞
虹科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() 完成運行,捆綁文件就會關閉,并且不會以任何方式保留已驗證的數據。
當 mount_bundle() 開始運行時,mountshell 調用會導致重新讀取包數據:
因此——攻擊者可以在調用 check_bundle() 和 mount_bundle() 之間切換包文件。這讓攻擊者可以部署任意惡意固件,基本上可以在設備上提供root權限。
贏得競爭條件(在檢查/掛載包調用之間替換包文件)的機會非常高,因為在包括shell 調用(“mount”命令)在內的兩個操作之間存在不可忽略的代碼量,這是一個非常緩慢的操作。
觀察到的遠程攻擊場景
盡管在大多數情況下,我們認為該漏洞可作為本地權限升級加以利用,但我們觀察到一個真實場景,即遠程攻擊者可利用一組默認硬編碼憑據利用該漏洞。
目標設備使用了一組默認的硬編碼憑據(用戶名和密碼設置為“admin”),首次登錄時不需要更改這些憑據。
這些憑證可以被能夠訪問設備固件的攻擊者輕易提取,或者通過簡單的暴力攻擊來猜測。
查看設備的攻擊面:
在這種情況下,攻擊者可以遠程接管設備,只需調用:
本地攻擊場景和 PoC
假設本地用戶有調用 RAUC 的權限(例如,通過只允許rauc命令的 sudo 配置),但沒有簽署RAUC捆綁包所需的私鑰,利用是沒有價值的:
將正確簽名的固件復制到某個路徑,例如:./bundle.raucb
Invoke RAUC –sudo rauc install ./bundle.raucb
迅速用惡意的固件替換./bundle.raucb
如果本地用戶無法調用 RAUC 命令,假設調用 RAUC 命令的特權用戶使用攻擊者可以寫入的路徑,則這種情況也可以被利用。
我們開發了一個概念驗證,它利用了這個確切的場景:
攻擊的bundle文件可以被移到正確簽名的bundle文件上(這比在正確的位置寫一個新文件要快)。
作為設備供應商,如何知道設備是否受此漏洞影響?
可以通過在您的設備上運行此命令來檢查您的 RAUC 版本是否存在漏洞
rauc --version如果報告的版本低于1.5,則您的設備包含有漏洞的代碼。實際上,只有當本地或遠程攻擊者有可能在安裝捆綁包時修改該文件,該設備才會有漏洞。
例如,這可能發生在以下情況。
vdoo ALL=(root) /usr/bin/rauc
/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 腳本來完成:
請注意,在使用像Yocto這樣的構建系統時,更改安裝腳本可能并不比切換到固定的RAUC版本容易得多。
總結
以上是生活随笔為你收集整理的虹科方案 | 虹科Vdoo安全平台:CVE-2020-25860 - 在 RAUC 嵌入式固件更新框架中发现的重大漏洞的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 电脑报2013年第9期
- 下一篇: “需要Mi crosoft .NET F