一枚“野生”UEFI rootkit的分析報告
前言
安全廠商ESET的研究人員公佈了一枚“野生”UEFI rootkit的分析報告。 UEFI rootkit 該允許黑客在目標計算機上植入長期存在的惡意軟體，即使使用者對硬碟驅動器全盤格式化後依然不能解決問題。
UEFI rootkit並不是新鮮事，例如曾經出現過的rkloader或面向macOS EFI/UEFI啟動植入的DerStarke。但這些惡意軟體均處於理論研究的階段，沒有在現實世界中大規模部署和傳播過。此外相關資訊基本上都是隻言片語，也沒有真實案例可以參考。ESET發現的這枚UEFI rootkit是從現實世界中首次獲得的，Sednit團隊“出品”，具備相當的傳播能力和實用性。
接下來就讓我們看看究竟是怎麼回事。
背景
Sednit團隊
Sednit團隊從2004年組建以來就一直活躍在暗處，它還有幾個名字：APT28、Sofacy、Strontium和Fancy Bear。它在過去幾年中進行過多次大型攻擊活動而聲名鵲起， 例如， 2016年美國大選之前對民主黨全國委員會（DNC）進行黑客攻擊以及被認為是全球電視網路TV5Monde、世界反興奮劑機構（WADA）電子郵件洩密等黑客攻擊的幕後推手。 本次發現的UEFI rootkit也是該團隊的第一款。
切入點/載體
一款名叫LoJack的筆記本防盜軟體是該UEFI rootkit的切入點/載體，這款軟體以前叫Computrace，由Absolute Software出品。使用者安裝該軟體並激活服務後，計算機就可以回傳資訊到其C＆C伺服器，如果計算機丟失或被盜，使用者就可以通過回傳的資訊得到其地理位置。
解構
軟體架構
LoJack/Computrace成為UEFI rootkit惡意軟體的推手，主要是因為它通過寫入系統的UEFI / BIOS韌體來避免因重灌系統或擦除/更換硬碟而導致裝置不可追溯。來自多家OEM製造商的膝上型電腦UEFI / BIOS模組中都預裝了該軟體，使用者只要更改BIOS選項即可啟用功能，如圖1所示：
圖1 LoJack/Computrace 功能BIOS啟用
下圖為該產品的全域性架構（來自2009年釋出的資訊），描繪了UEFI/BIOS模組如何工作並連線到Absolute Software控制的Web伺服器。
圖2 LoJack持久化機制
以下計算機啟動時該軟體開始執行的步驟說明：
1、計算機啟動時，如果BIOS選項處於“Enabled”的狀態，則執行UEFI/BIOS模組中的預置功能。軟體將嘗試查詢FAT/FAT32/NTFS分割槽，然後使用NTFS驅動程式建立 autochk.exe 檔案，並覆寫系統中原有 autochk.exe 檔案的內容。 autochk.exe 是一個Windows可執行檔案，在Windows初始化早期執行，用於檢查硬碟驅動器是否損壞。
2、系統載入並執行修改後的 autochk.exe ，其主要目的是釋放 rpcnetp.exe 並將其新增到系統服務，以便在每次系統重啟時啟動。 操作完成後還原 autochk.exe 為原始版本。
3、 rpcnetp.exe 的作用是確保主代理程式能夠正常執行。如果主代理程式失效，它會連線到Absolute Software的C＆C伺服器來下載代理程式並執行。 rpcnetp.exe 的第一步是複製自身並修改PE頭，變成動態連結庫（DLL）。 然後將此DLL載入到記憶體中，生成一個 svchost.exe 程序並注入DLL。然後它將產生一個Internet Explorer iexplore.exe 程序並再次將其DLL注入。 最後一個過程是通過網際網路與廠家的伺服器進行通訊。 rpcnetp.exe 將程式碼注入外部程序的行為常見於惡意軟體，合法、信譽良好的軟體極少採用這種方式。
4、全功能代理軟體在系統上執行，並實現LoJack的整套跟蹤和恢復功能。
2014年，LoJack/Computrace軟體的完整執行過程以及代理軟體與C＆C伺服器之間使用的網路協議才得以詳細披露。其中最大的問題在於代理軟體與伺服器之間的通訊沒有身份驗證機制，如果攻擊者可以控制代理軟體與伺服器之間的通訊鏈路，則可以在目標計算機上下載任意程式碼並執行。
能夠讓攻擊者直接與代理軟體進行通訊的方法有很多，這裡是以代理如何檢索C＆C伺服器的地址為突破點。伺服器地址資訊包含在 rpcnetp.exe 的配置資訊，經過加密。
圖3 左側為加密資訊，右側有部分解密
圖3顯示了加密和解密的 rpcnetp.exe 配置檔案。使用的“加密”方法是基於單位元組金鑰的簡單XOR操作。這個金鑰0xB5對於所有 rpcnetp.exe 都有效。如圖3所示，C＆C域名清晰可見。前面的四個位元組構成C＆C伺服器IP地址。由於整個過程中沒有對配置檔案內容進行驗證環節，對％WINDIR％具有寫訪問許可權的攻擊者即可更改檔案內容，讓 rpcnetp.exe 連線到攻擊者控制的C＆C伺服器而不是合法伺服器。只要知道網路協議用的是那種，就可以實現使用 rpcnetp.exe 下載並執行任意程式碼。
儘管這種風險已經存在很多年了，但直到最近針對性的惡意活動才出現在人們的視野裡。
LoJack變成了LoJax
2018年5月，Arbor Networks釋出的一篇部落格文章描述了木馬化LoJack解決方案中 rpcnetp.exe 的幾個木馬化樣本。這些惡意樣本使用了經過修改的配置資訊，與攻擊者的C＆C伺服器進行通訊。 配置資訊中改為了Sednit團隊使用的C＆C域名。 圖4顯示了修改過的 rpcnetp.exe 例項。
圖4 左邊為正常的配置檔案，右邊是修改後的配置檔案
“李鬼” rpcnetp.exe 與正版之間的差異非常小，上方的這個圖基本就反映了全貌。它們的編譯時間戳一致，並且內容只有幾十個位元組的區別。除了對配置檔案的修改外，其他更改還包括指定C＆C伺服器連線間隔的計時器值。
在5月的部落格釋出後，ESET還發現了針對巴爾幹、中歐以及東歐不同地區的LoJax惡意活動，安裝方式目前沒有明確的解釋。有可能動用了Sednit團隊掌握的一些後門。
元件探究
ESET實驗室分析了所有從巴爾幹半島、中歐和東歐地區收集到的LoJax惡意軟體樣本，均包含Sednit團隊的一些活動特徵，如：
SedUploader，一階後門。
XAgent，Sednit掌握的高階後門。
Xtunnel，一款網路代理工具，可以通過網際網路中繼C＆C伺服器和本地網路內端點計算機之間的網路流量。
受攻擊的計算機中大部分都存在Sednit團隊專用工具的痕跡，但一小部分系統只有LoJax。也就是說，在某些情況下LoJax被用作一個單獨的工具，以備其他工具失效情況下的不時之需。
而XAgent通常用於在系統上刪除其他模組，和LoJack解決方案中的部分功能一樣，也就是說如果在系統上發現XAgent存在的話，LoJax樣本可能只用到了 rpcnetp.exe 代理軟體的部分。
先保留這個猜測，繼續對LoJax樣本進行分析。
RWEverything驅動程式（RwDrv）和 info_efi.exe
第一條線索來自攻擊者建立的自定義工具，該工具在執行時會將底層系統設定資訊轉儲到文字檔案中。部分裝置上LoJax樣本和該工具同時存在。下圖展示了該工具生成的日誌檔案的片段，名稱為 info_efi.exe 。
圖5 由info_efi .exe生成的日誌檔案摘錄
此外，該工具釋放了 RwDrv.sys 用於讀取上述資訊。該核心驅動屬於RWEverything，後者是一個正常的免費程式，用於讀取計算機底層配置的資訊，包括PCI Express、記憶體、PCI Option ROM等。該核心驅動包含RWEverything的簽名，因此在系統上可以暢行無阻。
圖6 RwDrv .sys簽名證書
RWEverything軟體提供GUI介面可供使用者訪問所有資料。
圖7 RWEverything GUI截圖
info_efi工具是判斷LoJax UEFI模組是否存在的第一個條件。獲取系統硬體資訊時攻擊的第一部人，然後允許使用者程序訪問和修改儲存UEFI模組SPI快閃記憶體的內容。
第二條判斷該UEFI rootkit是Sednit團隊“出品”的線索是用於SPI記憶體轉儲和寫入的兩個不同工具。
SPI快閃記憶體轉儲
第一個是 ReWriter_read.exe 檔案，包含使用RWEverything驅動程式 RwDrv.sys 轉儲系統SPI快閃記憶體所需的所有程式碼。為了讓裝置驅動程式執行所需操作，轉儲工具必須傳送正確的I/O控制（IOCTL）程式碼。雖然 RwDrv.sys 支援許多不同的IOCTL程式碼，但此處轉儲器和編寫器工具僅使用四個即可滿足需求。
ReWriter_read首先使用嵌入式核心驅動程式 RwDrv.sys 建立服務，並記錄有關UEFI/BIOS配置的資訊，即BIOS 控制暫存器（BIOS_CNTL）中包含的三個欄位的值：BIOS鎖定啟用（BLE），BIOS寫入啟用（BIOSWE）和SMM BIOS防寫禁用（SMM_BWP）。雖然ReWrite_read沒有利用這些值，但以下部分將重點介紹為什麼需要該資訊。
ReWriter_read的下一步操作是檢索SPI快閃記憶體上的BIOS區域基地址及其大小。該資訊包含在SPI主機介面暫存器“BIOS Flash Primary Region”中。所有SPI主機介面暫存器都在根複合暫存器塊（RCRB）中進行儲存器對映，其基址可以通過讀取正確的PCI配置暫存器來檢索。ReWriter_read使用RwDrv IOCTL 0×22840並讀取正確的偏移量（在我們的例子中為0xF0）來獲取此地址。一旦獲得BIOS區域基址和大小資訊後，轉儲工具就會讀取SPI快閃記憶體的相關內容並將其寫入磁碟上的檔案。SPI快閃記憶體的讀取過程如圖8所示。
圖8 讀取SPI快閃記憶體的操作順序
這些操作將重複執行直到從SPI快閃記憶體讀取所有資料為止。然後，ReWriter_read驗證轉儲映象的大小。它將解析映象Flash描述符以獲取BIOS、千兆乙太網（GbE）和管理引擎（ME）區域的記憶體範圍。新增這三個區域的大小允許轉儲工具計算SPI快閃記憶體中完整內容的大小。如果映象尺寸等於通過讀取BIOS Flash主區域暫存器獲得的尺寸資訊，映象被認為有效。
注入UEFI韌體
第二個是 ReWriter_binary.exe 檔案。該檔案包含注入轉儲的UEFI映象檔案的程式碼，並將木馬化的映象覆寫SPI快閃記憶體。本節將詳細介紹此二進位制檔案的內部工作原理。
一旦快閃記憶體中的內容被上述轉儲器工具轉儲併成功驗證，惡意UEFI模組就被新增到映象中。 因此攻擊者首先需要解析UEFI映象來提取攻擊所需的資訊。
UEFI映象中的資料使用韌體檔案系統（FFS）以卷的形式儲存。顧名思義，它是專門為儲存韌體映象而定製的檔案系統。捲包含由GUID標識檔案。每個檔案通常由多個部分組成，其中一個部分包含真實的PE/COFF可執行檔案，即UEFI映象。使用UEFITool可以看到相關資訊。
圖9 使用UEFITool載入UEFI映象檔案
ReWriter_binary解析在SPI快閃記憶體的BIOS區域中找到的所有韌體卷，搜尋特定檔案：
Ip4Dxe（8f92960f-2880-4659-b857-915a8901bdc8） NtfsDxe（768bedfd-7b4b-4c9f-b2ff-6377e3387243） SmiFlash（bc327dbd-b982-4f55-9f79-056ad7e987c5） DXECore
圖10 解析韌體卷的例程的Hex-Rays反編譯器輸出
Ip4Dxe和NtfsDxe是DXE驅動程式。在UEFI韌體中，DXE驅動程式是PE / COFF映象，用於硬體抽象或生成可供其他DXE驅動程式或UEFI應用程式使用的服務。這些驅動程式由DXE Foundation在早期引導過程中通過DXE Dispatcher（DXE Core）載入。這個步驟完成後，UEFI應用程式（例如OS載入程式）可以使用的所有服務均已齊備。通常情況下，所有DXE驅動程式都儲存在同一個卷中，但是DXE排程程式可能存在別的地方。
ReWriter_binary僅用於查詢Ip4Dxe，表示正在解析的捲包含DXE驅動程式，該卷將用於安裝的攻擊者的惡意DXE驅動程式。它還會查詢DXE Core並將其所在的卷新增為另一個候選卷，以便編寫rootkit。每個捲上的可用空間在後續步驟中用於新增惡意驅動程式。
NtfsDxe是AMI NTFS DXE驅動程式。如果韌體卷存在，則用於稍後從卷中刪除檔案。在之後的UEFI rootkit分析章節可以看到該工具為何刪除此驅動程式。
而針對SmiFlash映象，有關資訊僅用於儲存，不用於任何惡意活動。有趣的是，這個映象本身問題也很多。ESET專家認為Sednit團隊按兵不動的原因很有可能正在開發一些該映象相關的漏洞，如果成功，哪怕是比較新的裝置都可以被覆寫SPI快閃記憶體。目前的工具只能寫入配置錯誤或相當老舊BIOS系統中（2008年左右推出的晶片組的對應主機板）。
在提取所需元資料之後，ReWriter_binary的下一步是注入和轉儲UEFI映象，新增惡意DXE驅動程式。
首先，它會建立一個檔案頭部結構（EFI_FFS_FILE_HEADER）。
然後，根據Ip4Dxe和DXE Core的位置以及這些捲上的可用空間選擇目標卷。 ReWriter_binary嵌入包含PE映象的壓縮部分和使用者介面部分，用於指定檔案的可讀名稱：SecDxe。 壓縮部分將附加到檔案頭，並寫入包含可用空間的卷尾。 圖11展示了使用UEFITool檢視的檔案結構。
圖11 SecDxe檔案的UEFITool檢視
最後，如果映象中存在NtfsDxe驅動程式，則會將其刪除。由於韌體檔案系統按順序儲存檔案及其內容，因此這是一個相當簡單的過程：
ReWriter_binary找到卷末尾的自由空間的偏移量；
NtfsDxe映象被0xFF位元組覆蓋；
從NtfsDxe所在的偏移點開始複製韌體卷的尾部；
檔案系統的其餘部分填充0xFF位元組。
將修改的韌體寫回SPI快閃記憶體
成功修改轉儲的韌體映象後，下一步就是將其寫回SPI快閃記憶體。在深入研究這個過程之前，需要先介紹一些與此案例相關的BIOS防寫機制。
BIOS系統包含多種保護機制，用於阻止未經授權的BIOS韌體寫入嘗試。 但是，預設情況下這些機制並沒有被啟用。這些配置通過BIOS控制暫存器（BIOS_CNTL）啟用或關閉。該暫存器包含BIOS Write Enable（BIOSWE）位，需要將其設定為1才能寫入SPI快閃記憶體。IOS控制暫存器（BIOS_CNTL）還有另一個可用於保護BIOS的功能：BIOS鎖定啟用（BLE），該功能啟用時會將BIOSWE位鎖定為0。 但是，在現實情況中這種保護機制非常脆弱，當有請求將BIOSWE位設定為1時，BIOSWE先會被設定為1，然後系統發出系統管理中斷（SMI），指令將BIOSWE位設定回0。
這種方式問題很大。 首先，需要韌體開發人員專門構建一個SMI處理程式，如果沒有，則BLE位無用。 其次，存在競態條件漏洞時，即使SMI處理程式正常執行，也可能允許完全繞過此機制。要利用此漏洞，攻擊者需要啟動一個執行緒，該執行緒將BIOSWE連續設定為1，而另一個執行緒將資料寫入SPI快閃記憶體。
為了解決此問題，通過BIOS_CNTL配置的新保護機制已經得到應用。它是在英特爾晶片組的平臺控制器中心（PCH）系列中引入的。如果其配置位已設定，則僅當所有核心在系統管理模式（SMM）中執行且BIOSWE設定為1時，SMM BIOS防寫禁用（SMM_BWP）才能允許BIOS韌體是可寫的。這種機制能夠有效保護系統免受競態條件漏洞的影響。但是，與BLE的情況一樣，SMM_BWP需由韌體啟用。因此，未能正確配置這些機制的韌體會使系統面臨未經授權寫入BIOS區域的風險。
ReWriter_binary讀取BIOS控制暫存器的內容以選擇正確的路徑。它首先檢查BIOSWE是否已設定。如果是，則進入寫入階段。如果禁用BIOSWE，它將檢查BLE位的值。如果未設定，則會翻轉BIOSWE位並開始覆寫已修改的韌體。如果設定了BLE，則確保禁用SMM_BWP並利用上述競態條件。如果SMM_BWP位置1，則失敗。 圖12說明了這個過程。
圖12 寫入過程的決策樹
假設這裡分析的ReWriter_binary的版本和用於部署UEFI rootkit的一致，我們可以得出結論，韌體沒有正確配置BIOS防寫機制，或者目標裝置的晶片組比平臺控制器中心更老舊。
ReWriter_binary無法在正確配置的新一代BIOS系統中覆寫UEFI韌體。但是，在解析UEFI韌體空間時尋找易受攻擊的SmiFlash UEFI映象，這一舉動表明攻擊者可能在尋求更先進的技術繞過BIOS防寫。
與上述讀操作非常相似，寫入SPI快閃記憶體的順序：
圖13 寫入SPI快閃記憶體的順序
這些操作將迴圈重複，直到所有資料都寫入SPI快閃記憶體。
寫入過程完成後，SPI快閃記憶體的內容將再次轉儲到檔案 image.bin 中。在新的轉儲映象上執行同ReWriter_read操作過的相同完整性檢查。然後，將從SPI快閃記憶體讀取的映象與記憶體中的修改映象進行比較。如果某些位元組不同，則會記錄不同的地址，不同之處不會對惡意軟體的執行有任何影響，只作記錄用。
最後的步驟時設定此登錄檔項：
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ BootExecute =“autocheck autochk *”
然後，停止並解除安裝RwDrv服務。 設定Windows登錄檔值非常重要，因為UEFI Rootkit查詢該字串從而在Windows啟動期間執行惡意軟體。
LOJAX技術分析
雖然轉儲、修改和寫入SPI快閃記憶體的工具是針對特定韌體映象定製的，並且無法在任何給定系統上輕鬆重複使用，但可以從中提取完整的UEFI模組。研究人員在提取到該模組後做的第一事是通過遙測來檢視之前是否錄入過這個模組的洗腦洗。使用新新一代ESET UEFI掃描器受發現有記錄，表明Sednit團隊的UEFI模組安裝曾經安裝在現實世界中的系統上，也就是說這款UEFI Rootkit是正經“野生”的，不僅停留在理論研究層面。
以下是研究人員對該“野生”樣本的技術分析。
圖14給出了在OS之前UEFI rootkit工作流的概述。 首先，DXD排程程式載入SecDxe DXE驅動程式。 它在 EFI_EVENT_GROUP_READY_TO_BOOT 事件組上設定Notify函式回撥。 當韌體即將選擇引導裝置並執行OS載入程式時呼叫Notify功能。回撥做了三件事：
載入嵌入式NTFS DXE驅動程式，以便能夠訪問和寫入NTFS分割槽；
將兩個檔案寫入Windows NTFS分割槽： rpcnetp.exe 和 autoche.exe ；
修改此登錄檔項 'HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ BootExecute' ：
之前： 'autocheck autochk *'
之後： 'autocheck autoche *' 。
圖14 被UEFI rootkit感染的系統的引導過程
SecDxe：惡意DXE驅動程式
上文已經介紹了UEFI rootkit的元件部署細節，本章的重點是介紹在目標裝置上發生的事件詳情。這裡採用自下而上的方法，首先描述UEFI rootkit本身，然後跟蹤事件鏈直到在作業系統級別部署的最終有效負載。
Sednit的UEFI rootkit是一個DXE驅動程式，由GUID 682894B5-6B70-4EBA-9E90-A607E5676297標識。該檔案沒有簽名，因此無法在啟用了安全啟動的系統上執行。 一旦部署在一個韌體卷中，DXE Foundation就會在每次系統引導時載入它。
SecDxe是一個小型DXE驅動程式，主要做兩件事：安裝一個從未使用過的GUID 832d9b4d-d8d5-425f-bd52-5c5afb2c85dc標識的協議；建立一個與Notify功能相關的事件。通知函式設定為在發訊號通知 EFI_EVENT_GROUP_READY_TO_BOOT 事件組時呼叫。引導管理器通知事件組要啟動的裝置。
圖15 建立事件的程序的Hex-Rays反編譯輸出
Notify功能實現了Sednit的UEFI rootkit的惡意行為。它將有效負載寫入Windows的NTFS檔案系統。由於UEFI韌體通常僅處理EFI系統分割槽，通常不包括NTFS驅動程式，僅支援基於FAT的檔案系統作為啟動分割槽。因此，UEFI韌體不必與NTFS驅動程式一起提供。所以SecDxe嵌入了自己的NTFS驅動程式。首先載入此驅動程式並將其連線到磁碟裝置。這樣一來它就能在NTFS分割槽的磁碟裝置上安裝EFI_SIMPLE_ FILE_SYSTEM_PROTOCOL，從而實現基於檔案的訪問。
圖16 用於將檔案寫入磁碟的程序的Hex-Rays反編譯輸出
然後SecDxe開啟 ％WINDIR％\ System32 \ config \ SYSTEM ，這是支援HKLM \ SYSTEM登錄檔配置單元的檔案。然後解析檔案，找到’autocheck autochk *’並用’e'替換’autochk’的’k'。將 'HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ BootExecute' 設定為 'autocheck autoche *' 。下次Windows啟動時，將啟動autoche .exe而不是 autochk.exe 。
黑客團隊的NTFS驅動程式
如上文所述，SecDxe模組嵌入了NTFS驅動程式，表明Sednit團隊很有可能自己編寫驅動程式，而是直接集成了Hacking Team洩露的NTFS DXE驅動程式。
Hacking Team的NTFS驅動程式的核心是ntfs-3g開源專案，只是加了一個外殼作為UEFI DXE驅動程式。因此，Hacking Team的驅動程式的INF檔案構建資訊列出了來自ntfs-3g專案的檔名。SecDxe的NTFS驅動程式字串還列出了許多這些檔名：
c:\edk2\NtfsPkg\NtfsDxe\ntfs\inode.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\volume.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\bootsect.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\unistr.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\attrib.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\mft.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\index.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\cache.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\misc.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\dir.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\runlist.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\logfile.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\uefi_io.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\ntfsinternal.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\mst.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\lcnalloc.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\compress.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\bitmap.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\collate.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\security.c
另一個有意思的點是專案路徑與Hacking Team的EFI開發專案中找到的路徑相同，即Vector-edk。在vector-edk中，有一個子專案NtfsPkg具有完全相同的目錄佈局。ntfs-3g原始碼檔案位於同一路徑中。雖然這些路徑是通用的，但研究人員認為這不是巧合。
將洩漏的原始碼與Hex-Rays反編譯器輸出進行比較，很明顯它是同一個專案。圖17是比較NtfsDriverBindingStart從vector-edk / NtfsPkg / NtfsDxe / Ntfs.c獲取的函式的示例。為清楚起見，已從原始HT的原始碼中刪除了註釋。函式呼叫的邏輯和順序是相同的。兩個專案甚至使用相同的變數（LockedByMe）來保持鎖住的狀態。
圖17 Sednit的NTFS驅動程式（左）和HT的NTFS驅動程式（右）的Hex-Rays反編譯器輸出之間的比較
上面的比較顯示了Hacking Team開發人員的程式碼，並沒有出現在ntfs-3g開原始碼中。
如ReWriter_binary部分所述，在解析韌體檔案系統時，可執行檔案會嘗試刪除AMI NTFS驅動程式。研究人員想了解為什麼刪除它而不是使用它。
研究人員分析了驅動程式，發現它只能執行讀操作。由於不支援寫入檔案系統，因此無法將其用於攻擊目的。當韌體中已經存在另一個NTFS驅動程式時，Sednit團隊可能也遇到了一些問題，因此他們只是決定將其刪除。除了實現讀寫操作外，Hacking Team的驅動程式不會強制執行檔案許可權，例如，覆蓋只讀檔案而不會引發任何錯誤。
本文已經描述了UEFI rootkit為破壞主機作業系統而執行的各種操作，還討論了為什麼研究人員認為Sednit團隊使用Hacking Team的vector-edk的原始碼來構建他們的NTFS驅動程式來編寫檔案的原因。
下文將對SecDxe刪除的有效負載進行分析。
autoche.exe與autochk.exe
惡意 autoche.exe 檔案用於為 rpcnetp.exe 代理軟體賦予長久存在的能力。如圖18所示，它使用本機Windows API呼叫來建立此服務。
圖18 惡意autoche .exe設定rpcnetp .exe永續性
服務名稱與合法Computrace代理程式使用的名稱相同。建立服務後，它會將BootExecute登錄檔項還原為其先前的值。
圖19 惡意autoche .exe恢復BootExecute的原始登錄檔值
由於此過程在Windows啟動時發生，因此使用者幾乎不會注意到BootExecute登錄檔項值修改。應該注意的是，autoche .exe與Compu-trace的autochk.exe模組有一些相似之處，例如使用的API呼叫和服務註冊，但其餘的則完全不同。Computrace的模組更大，而是恢復原始的autochk .exe可執行檔案而不會更改登錄檔項，它還負責將代理程式置於磁碟中。
總結
修復基於UEFI韌體的攻擊是一個難題。沒有簡單的方法來保障系統免受這種威脅，也沒有任何安全產品能夠完全防禦。如果發生本文中描述的情況，需要重新重新整理SPI快閃記憶體以刪除rootkit。對於普通計算使用者來說，如果重刷UEFI韌體不太可行或者壓根找不到可用的BIOS韌體，還是建議將主機板換成新一點的。
*參考來源： ofollow" rel="nofollow,noindex" target="_blank">thehackernews ，Freddy編譯整理，轉載請註明來自 FreeBuf.COM。