Group-IB：UEFI 的攻擊與狩獵

0x00 摘要

大型黑客組織在bootkits的使用上有著長期的成功經驗。bootkits是BIOS/UEFI中隱藏的特殊惡意代碼，能夠實現長期隱藏而不被發現，甚至在重新安裝操作系統和更換硬盤驅動器后仍然存在。由于bootkits具有天然的隱蔽性，極難被檢測發現，目前bootkits正被一些與經濟動機相關的黑客組織（如Trickbot）所青睞。

本文描述了如何在本地網絡中捕獲此類威脅，以及如何使用最新的Mosaic Regressor UEFI bootkit搭建測試平臺。

0x01 bootkit進化史

• 在2013年，QuarksLab的Sébastien Kaczmarek創建了一個名為Dreamboot的bootkit PoC，它利用UEFI攻擊操作系統的引導加載程序，但是該攻擊只有禁用安全引導機制后才能實現。之后，同年的黑帽大會上提出了“一種繞過Windows 8安全引導的方法”。自此，安全引導繞過機制被第一次公開提出。

• 在2014年，Rafal Wojtczuk和Corey Kallenberg發布了S3恢復機制中存在的Darth Venamis漏洞信息。計算機在從睡眠模式喚醒后可以使用這種機制繼續工作。研究表明，存儲S3 BootScript（計算機從睡眠模式被喚醒后初始化設備的一系列命令）的內存區域沒有修改保護，引發了各種漏洞。

• 在2015年，Corey Kallenberg和另一位研究人員Xeno Kovah提出了LightEater。這是一種rootkit，可通過直接訪問物理內存，使用簽名進行逐頁搜索來獲取加密密鑰等關鍵數據。同年，從HackingTeam泄漏的數據中發現了Vector-EDK框架。這種惡意軟件可以向基于UEFI的固件中注入程序。該框架曾被用于開發Mosaic Regressor。

• 在2016年，Dmytro Oleksiuk開發了PeiBackdoor，這是第一個公開可用的UEFI Rootkit，它在PEI（即Pre-EFI初始化）階段被加載。同年，黑客組織Equation Group泄漏的數據中出現了BANANABALLOT BIOS模塊，該模塊植入了某種特定程序以與CISCO路由器進行交互。

• 在2017年，WikiLeaks發布了有關DerStarke的信息，DerStarke是一種針對macOS平臺的Triton后門的UEFI版本。

• 在2018年，ESET檢測到并分析了LoJax UEFI Rootkit，這是信息安全公司首次發現的UEFI Bootkit。

• 在2020年10月，卡巴斯基實驗室在調查攻擊時發現了Mosaic Regressor，這是一種UEFI bootkit，由HackingTeam數據泄漏中獲得的工具所創建。同年12月，一種新型的TrickBot版本被發現，其中嵌入了UEFI代碼。

  上面的介紹雖然并不完整，但也顯示了UEFI相關攻擊的流行趨勢和危險性。近年來，固件中公開披露的漏洞數量每年都會翻倍。由此可見，網絡犯罪分子對于此類攻擊方法的興趣不斷上升。

0x02 UEFI bootkit 測試平臺搭建

Mosaic Regressor包含的幾個模塊如下表所述。

創建測試平臺需要感染QEMU虛擬機的固件。該虛擬機使用OVMF（開放虛擬機固件）來對固件進行仿真模擬。固件存儲在OVMF_CODE.fd文件中。

因此，要修改虛擬機固件，必須先更改OVMF_CODE.fd文件。這里需要用到跨平臺開源工具 - UEFITool。它能夠分析固件，從固件中提取模塊。

要感染固件，必須向其中添加兩個DXE驅動程序和兩個UEFI應用程序。首先，需要找到包含所有被使用的DXE驅動程序的節（如下圖所示，該節是GUID為8C8CE578-8A3D-4F1C-9935-896185C32DD3的部分）

在寫入之前，每個現存的EFI文件都必須以FFS（固件文件系統）文件的格式顯示。FFS格式的每個文件都包含多個節（在當前案例中，每個FFS文件有兩個節）。第一個節包含可執行代碼，第二個節包含模塊名稱。所有的驅動程序均被匯編為EFI_FV_FILETYPE_DRIVER文件。

所有應用程序都被匯編為EFI_FV_FILETYPE_APPLICATION文件。

為了進行匯編，需要用到EDK II GenSec和GenFfs組件。

可執行代碼節的創建如下：

GenSec.exe -o pe32.sec .\Ntfs.efi -S EFI_SECTION_PE32

帶有名稱的節創建如下：

GenSec.exe -o name.sec -S EFI_SECTION_USER_INTERFACE -n "NTFS"

FFS格式的文件創建如下：

GenFfs-g "F50258A9-2F4D-4DE9-86AE-BDA84D07A41C" -ontfs_driver.ffs-ipe32.sec-iname.sec-tEFI_FV_FILETYPE_DRIVER

當創建帶有名稱的節時，必須更改-n參數后的文件名。

當創建可執行代碼節時，需更改EFI文件的路徑。

當創建FFS文件時，必須更改GUID（-g參數）、文件類型（-t參數：驅動程序為EFI_FV_FILETYPE_DRIVER，應用程序為EFI_FV_FILETYPE_APPLICATION）以及輸出文件的名稱（-o參數）。

最后獲得四個FFS格式的文件，可以使用UEFITool將其添加到固件中。

添加時必須確保該節具有足夠的空余空間。修改后的固件應如下所示：

在替換固件文件并啟動虛擬機后，Mosaic Regressor開始創建文件；

該過程表明固件已被成功修改。這些文件包括％WINDIR％\setupinf.log以及％PROGRAMDATA％\Microsoft\Windows\開始菜單\Programs\Startup\IntelUpdate.exe。

第一個文件可以作為IOC，因為只有當setupinf.log文件不存在時才會創建IntelUpdate.exe文件；第二個文件從服務器下載攻擊載荷：

雖然在當前案例中只是虛擬機被感染，但是攻擊者可以利用此技術在現實中感染配置錯誤的計算機。

0x03 捕獲Mosaic Regressor

有幾種檢測Mosaic Regressor的方法：

• 在固件中搜索指示器或與UEFI引用鏡像進行比較

• 在操作系統級別搜索指示器

• 分析網絡活動

  接下來將對每種方法進行詳細介紹。

搜索固件中的指示器

通過對EFI文件SmmReset的分析，可以獲得一個固件IOC。該可執行文件將創建一個名為“ fTA”的NVRAM變量。而在HackingTeam開發的rkloader中發現了具有相同名稱和功能的變量，因此搜索該IOC指標可以找到基于rkloader的Mosaic Regressor，rkloader以及其他bootkits。

由英特爾發布和支持的多功能Chipsec應用可以檢測此威脅。該應用執行固件安全性測試，獲取固件轉儲。Chipsec也可以從操作系統中執行或引導到UEFI Shell后進行執行。本案例中選擇了后一項。要創建可啟動的閃存驅動器以啟動Chipsec，應遵循以下步驟：

• 將閃存驅動器格式化為FAT-32文件系統。

• 保存計算機啟動后在閃存驅動器上將要執行的UEFI Shell。為此，需要下載UEFI Shell，并將其命名為“Bootx64.efi”并保存至 /efi/boot。

• 下載Chipsec倉庫。

• 將instal /UEFI/chipsec_uefi_x64.zip中的內容提取到閃存驅動器的根目錄下。

• 將Chipsec倉庫的其余內容復制到閃存驅動器的根目錄下。

  當引導進入到UEFI Shell后，mount命令將被執行，該命令可以顯示可用設備列表。

  在下圖的這種情況下，閃存驅動器將被指定為FS0：

訪問Chipsec目錄后，可以使用如下命令檢查固件中是否存在具有該名稱的變量：

python chipsec_util.py uefi var-find fTA

若存在，其轉儲將被保存到文件中：

若需要對固件進行更深入的分析，可以用Chipsec獲取轉儲。為此，需要執行以下命令：

python chipsec_util.py spi dump rom.bin

前面提到的UEFITool可用于打開轉儲并提取可疑模塊，使用方法如下圖所示：

若存在引用固件映像，Chipsec可以使用它來檢測固件修改。為此，必須使用如下命令生成參考圖像模塊的列表：

python chipsec_main.py -i -m tools.uefi.scan_image -a generate,list_of_variables.json,firmware.bin

其中list_of_variables.json是保存執行結果的文件。下圖的例子中，firmware.bin文件屬于引用固件轉儲：

在接收到有關引用映像數據后，可以使用如下命令進行比較：

python chipsec_main.py -i -m tools.uefi.scan_image -a check，list_of_variables.json，suspected_firmware.bi

其中suspended_firmware.bin文件是被測固件的轉儲文件名稱。

如上所述，可以從操作系統中使用Chipsec。為此，必須先安裝Chipsec驅動程序，并且要用到python解釋器運行相關py文件。通過這種方式，才能對收集到的固件映像進行進一步分析。

在操作系統級別搜索IOC

本節將介紹如何在操作系統級別上檢測Mosaic Regressor固件感染。

當操作系統啟動后，Mosaic Regressor攻擊負載（IntelUpdate.exe文件）的行為與常見的惡意軟件類似。可以利用分析EFI文件獲得的數據、保存在％PROGRAMDATA％\Microsoft\Windows\StartMenu\Programs\Startup中的文件哈希、文件名稱以及其他IOC來實現檢測。但是，應該指出的是，文件創建事件的搜索將不會成功，因為文件是在加載操作系統之前創建的，這意味著使用EDR或類似解決方案將不會檢測到該事件（唯一的解決方法：

可以在關閉計算機或使其進入休眠狀態之前保存有關文件系統狀態的信息，并將保存的狀態與引導操作系統后的狀態進行比較）。

％WINDIR％\setupinf.log文件也會發生類似情況，Mosaic Regressor將該文件用作UEFI變量的補充IOC。IntelUpdate.exe文件只會在setupinf.log文件不存在的情況下保存。

使用Huntbox中的以下查詢字段，可以找到攻擊載荷的痕跡，該痕跡由Mosaic Regressor EFI模塊產生：

event_type: "Process creation" AND Payload.CommandLine: "Microsoft\Windows\Start Menu\Programs\Startup\IntelUpdate.exe"

IntelUpdate.exe文件是使用未修改的時間屬性創建。若一個自啟動文件開始運行但是沒有產生對應的事件，這將是一種潛在的威脅暗示。

在啟動時創建的所有文件都應在沙箱或惡意軟件執行平臺中進行檢查。在本例中，Huntpoint將文件發送到Polygon進行分析，從而識別惡意文件。結果顯示，該類文件的啟動在所有主機上均被阻止。

使用EDR和惡意軟件系統是一種通用解決方案，但在所有工作站上安裝客戶端并不一定可行。在這種情況下，使用已知的惡意主機分析網絡流量連接可能會有所幫助。

這樣可以檢測發送攻擊負載的服務器是否存在網絡連接：

event_type: "Networkconnectionopening"  ANDPayload.RemoteAddress: "103.56.115.69"

dns_query: "myfirewall.org"

0x03 潛在的攻擊媒介

涉及UEFI感染的情況通常有以下三種：

• 遠程感染

• 物理訪問感染

• 通過供應鏈感染

  要進行遠程感染，攻擊者必須提升權限才能安裝將在操作系統內核級別運行的攻擊負載。提升權限之后，攻擊者需要利用SMM漏洞。這樣就可以在SMM模式下執行代碼，從而繞過各種固件保護機制（閃存寫保護），并直接訪問固件內存。

  在涉及物理訪問感染的情況中，攻擊者可以利用UEFI配置或固件更新機制中的錯誤。

  如果供應鏈被感染，攻擊者可以將代碼注入到固件中或對其進行更新，并繞過現有的保護方法。對于此類攻擊，需要獲得對固件源代碼的訪問權。

  Chipsec也可以用于基本UEFI配置檢查或漏洞掃描。為此，需要使用下列python命令運行主模塊：

python chipsec_main.py

該命令將運行各種安全檢查，例如重寫保護檢查。

需要注意的是，因為Chipsec僅提供一組基本的安全檢查，所以成功通過此測試并不表示系統未受到感染。但是，未通過測試意味著必須安裝最新的UEFI更新，或者找到違反固件基本安全機制的原因。

0x04 總結

UEFI威脅是最嚴重的安全威脅之一，想要更加安全、可靠地加載操作系統，就不能僅依靠內置的保護機制。為了保護基礎設備并有效地應對此類威脅，必須重視網絡威脅情報數據的使用。此外，除了實現了相關安全策略的商業產品外，還可以使用開源工具（Chipsec）進行防護，該工具通過檢測IOC，在一定程度上提供了捕獲威脅的可能性，并有助于檢查UEFI配置是否正確。

• End -

原文標題：Hunting bootkits on a local network and building your own test bench

原文鏈接：www.group-ib.com/blog/bootkits

本文為CNTIC編譯，不代表本公眾號觀點，轉載請保留出處與鏈接。