ESET 安全研究人員于今年 3 月發(fā)現(xiàn)了 BlackLotus，被認為是首個可以在 Win11 系統(tǒng)上繞過 Secure Boot 的 UEFI bootkit 惡意軟件。

微軟于今天面向 Win10、Win11、Windows Server 發(fā)布了 KB5025885 更新，重點修復了這個追蹤編號為 CVE-2023-24932 的漏洞。

附微軟官方摘要信息如下：

本文介紹如何使用由 CVE-2023-24932 跟蹤的 BlackLotus UEFI bootkit 來防止安全啟動安全功能繞過公開披露，以及如何啟用保護和指南來更新可啟動媒體。

bootkit 是一個惡意程序，旨在盡早在設(shè)備的序列中加載，以便控制操作系統(tǒng)啟動。

安全啟動建議 Microsoft 通過 Windows 內(nèi)核的受信任啟動序列從統(tǒng)一可擴展固件接口 (UEFI) 創(chuàng)建安全且受信任的路徑。

安全啟動有助于防止啟動序列中的 bootkit 惡意軟件。禁用安全啟動會使設(shè)備面臨被 bootkit 惡意軟件感染的風險。

修復 CVE-2023-24932 中所述的安全啟動繞過需要撤銷啟動管理器。這可能會導致某些設(shè)備的啟動配置出現(xiàn)問題。

2023 年 5 月 9 日的安全更新提供了配置選項，用于手動啟用安全啟動繞過保護，但不會自動啟用這些保護。

在啟用這些保護之前，必須驗證設(shè)備和所有可啟動媒體是否已更新并準備好進行此安全強化更改。

使用 Microsoft 基于云的解決方案的客戶應(yīng)遵循 更新可啟動媒體 / Azure 云 中的指南。 

繞過安全啟動并建立持久性

在本部分中，我們將詳細了解BlackLotus如何在啟用UEFI Secure Boot的系統(tǒng)上實現(xiàn)持久性。由于我們將要描述的執(zhí)行鏈非常復雜，我們將首先解釋基本原理，然后深入了解技術(shù)細節(jié)。

簡而言之，該過程包括兩個關(guān)鍵步驟：

利用CVE-2022-21894繞過安全啟動功能并安裝 bootkit。這允許在早期啟動階段任意執(zhí)行代碼，此時平臺仍然由固件擁有，UEFI啟動服務(wù)功能仍然可用。這使得攻擊者可以在沒有物理訪問權(quán)限的情況下，在啟用了UEFI Secure Boot的設(shè)備上做許多不應(yīng)該做的事情，例如修改僅用于啟動服務(wù)的NVRAM變量。這就是攻擊者在下一個步驟中為 bootkit設(shè)置持久性所利用的。通過將自己的MOK寫入MokList來設(shè)置持久性，Boot僅服務(wù)NVRAM變量。這樣，它可以使用合法的 Microsoft-signed shim加載其自簽名（由寫入MokList的密鑰的私鑰簽名）UEFIbootkit，而不是在每次啟動時利用該漏洞。有關(guān)這一點的更多信息，請參閱Bootkit持久性部分。

為了使下面兩部分的分析更容易，研究人員將遵循執(zhí)行圖（下圖）中所示的步驟。

繞過安全啟動并使用MOK設(shè)置持久性

利用CVE-2022-21894

為了繞過安全啟動，BlackLotus使用baton drop漏洞（CVE-2022-21894）：安全啟動安全功能繞過漏洞。盡管這個漏洞對系統(tǒng)安全影響很大，但它并沒有得到應(yīng)有的重視。盡管微軟在2022年1月的更新中修復了該漏洞，但由于受影響的二進制文件仍未添加到UEFI取消列表中，因此攻擊者仍有可能利用該漏洞。因此，攻擊者可以將他們自己的易受攻擊的二進制文件副本帶到受害者的設(shè)備上，以利用此漏洞并繞過最新UEFI系統(tǒng)上的安全啟動。

此外，自2022年8月以來，針對該漏洞的概念證明（PoC）漏洞已公開可用。考慮到第一次BlackLotus VirusTotal提交的日期，惡意軟件開發(fā)人員可能只是根據(jù)他們的需要調(diào)整了可用的PoC，而不需要深入了解此漏洞的工作原理。

讓我們先簡單介紹一下該漏洞，主要是與PoC一起發(fā)布在GitHub上的文章中的關(guān)鍵點：

受影響的Windows啟動應(yīng)用程序（如bootmgr.efi、hvloader.efi、winload.efi…）允許在應(yīng)用程序加載序列化安全啟動策略之前，使用truncatememory BCD啟動選項從內(nèi)存中刪除該策略。

這允許攻擊者使用其他危險的BCD選項，如bootdebug、testsigning或nointegridchecks，從而破壞安全啟動。

有多種方法可以利用此漏洞——其中三種方法已發(fā)布在PoC存儲庫中。

例如，其中一個PoC顯示了如何利用它使合法的hvloader.efi加載任意的自簽名mcupdate_

現(xiàn)在，我們繼續(xù)介紹BlackLotus如何利用此漏洞：

1.安裝程序重新啟動機器后，UEFI固件將繼續(xù)加載第一個啟動選項。對于Windows系統(tǒng)，默認情況下，第一個啟動選項是位于ESP上ESP:/efi/Microsoft/boot文件夾中的bootmgfw.efi。這一次，固件沒有執(zhí)行原始受害者的bootmgfw.efi（安裝程序以前將其重命名為winload.efi），而是執(zhí)行安裝程序部署的易受攻擊的啟動。

2.執(zhí)行bootmgfw.efi后，它將加載BCD啟動選項，該選項先前由安裝程序修改。下圖顯示了合法BCD和修改后BCD的比較。

3.如下圖所示（路徑以綠色劃線），合法的Windows Boot Manager通常會將Windows OS加載程序（\Windows\system32\winload.efi）作為默認啟動應(yīng)用程序加載。但這一次，使用修改后的BCD，它繼續(xù)加載易受攻擊的ESP:\system32\bootmgr.efi，避免內(nèi)存BCD元素設(shè)置為值0x10000000，并且custom:22000023 BCD指向另一個攻擊者存儲在ESP:\system32\BCD中的BCD。

合法BCD存儲（BEFORE）與BlackLotus安裝程序使用的存儲（AFTER）的比較

4.在下一步中，執(zhí)行的ESP:\system32\bootmgr.efi加載位于ESP:\system32\BCD中的附加BCD。這個附加BCD的解析內(nèi)容如下圖所示。

BlackLotus安裝程序釋放的第二個BCD——用于利用CVE-2022-21894

5.由于從上圖所示的BCD文件加載了選項，bootmgr.efi將繼續(xù)加載安裝程序部署的另一個易受攻擊的Windows啟動應(yīng)用程序ESP:\system32\hvloader.efi，即Windows Hypervisor Loader。更重要的是，在同一BCD文件中指定了其他BCD選項：

值設(shè)置為0x10000000的truncatememory；

nointegridchecks設(shè)置為Yes；

testsigning也設(shè)置為Yes；

此時就會發(fā)生意想不到的事情，由于序列化的安全啟動策略應(yīng)該在0x10000000以上的物理地址中加載（因為前面步驟中使用了avoidlowmemory），指定truncatmemory元素將有效地刪除它。因此，中斷安全啟動并允許使用危險的BCD選項，如nointegritychecks或testsigning。通過使用這些選項，攻擊者可以使hvloader.efi執(zhí)行自己的自簽名代碼。

6.為此，使用此PoC中描述的技巧，即在執(zhí)行過程中，合法的hvloader.efi從

從合法的hvloader.efi反編譯BtLoadUpdateDll函數(shù)，負責加載mcupdate_*.dll

7.現(xiàn)在，隨著攻擊者自己的自簽名mcupdate*.dll被加載和執(zhí)行，它將繼續(xù)執(zhí)行這個鏈中的最后一個組件——一個嵌入式MokInstaller （UEFI應(yīng)用程序）——參見圖10了解它是如何完成的。

Hex-Rays反編譯惡意自簽名mcupdate*.dll二進制代碼

Bootkit持久性

現(xiàn)在，MokInstaller可以繼續(xù)設(shè)置持久性，方法是將攻擊者的MOK注冊到NVRAM變量中，并將合法的Microsoft簽名的shim二進制文件設(shè)置為默認啟動加載程序來繼續(xù)設(shè)置持久性。

shim是由Linux開發(fā)人員開發(fā)的第一階段UEFI啟動加載程序，用于使各種Linux發(fā)行版與UEFI Secure Boot一起工作。它是一個簡單的應(yīng)用程序，其目的是加載、驗證和執(zhí)行另一個應(yīng)用程序，在Linux系統(tǒng)中，它通常是GRUB啟動加載程序。它的工作方式是，微軟只簽署一個shim, shim負責其余的工作，它可以通過使用db UEFI變量中的密鑰來驗證第二階段啟動加載器的完整性，還可以嵌入自己的“允許”或“取消”項或哈希列表，以確保平臺和shim開發(fā)人員（例如Canonical, RedHat等）都信任的組件被允許執(zhí)行。除了這些列表之外，shim還允許使用用戶管理的外部密鑰數(shù)據(jù)庫，即MOK列表。該MOK數(shù)據(jù)庫存儲在名為MokList的僅啟動NVRAM變量中。在不利用上述漏洞的情況下，需要物理訪問才能在啟用UEFI Secure Boot的系統(tǒng)上對其進行修改（僅在啟動期間，在系統(tǒng)加載程序調(diào)用UEFI啟動服務(wù)函數(shù)ExitBootServices之前可用）。然而，通過利用此漏洞，攻擊者能夠繞過UEFI Secure Boot并在調(diào)用ExitBootServices之前執(zhí)行自己的自簽名代碼，因此他們可以輕松注冊自己的密鑰（通過修改MokList NVRAM變量），使填充程序執(zhí)行任何應(yīng)用程序（由該注冊密鑰簽名），而不會導致安全違規(guī)。

MOK啟動過程

8.MokInstaller UEFI應(yīng)用程序繼續(xù)為BlackLotus UEFI bootkit設(shè)置持久性，并通過以下方式覆蓋利用痕跡：

8.1 從安裝程序創(chuàng)建的備份中恢復受害者的原始BCD存儲，并將efi替換為合法的microsoft簽名shim，該shim先前由安裝程序放置到ESP:\system32\bootload.efi中。

8.2創(chuàng)建包含攻擊者自簽名公鑰證書的MokList NVRAM變量。請注意，此變量的格式與任何其他UEFI簽名數(shù)據(jù)庫變量（如db或dbx）的格式相同，它可以由零個或多個EFI_signature_LIST類型的簽名列表組成，如UEFI規(guī)范中所定義。

8.3 從攻擊者的ESP:\system32\文件夾中刪除涉及攻擊的所有文件。

最后，它會重新啟動計算機，使部署的shim執(zhí)行安裝程序從\EFI\Microsoft\Boot\grub64.EFI中刪除自簽名bootkit，grub64.EFI通常是x86-64系統(tǒng)上shim執(zhí)行的默認第二階段啟動加載程序。

Hex Rays反編譯代碼——MokInstaller UEFI應(yīng)用程序為BlackLotus bootkit設(shè)置持久性

BlackLotus UEFI bootkit

一旦配置了持久性，就會在每次系統(tǒng)啟動時執(zhí)行BlackLotus bootkit。 bootkit的目標是部署一個內(nèi)核驅(qū)動程序和一個最終的用戶模式組件——HTTP下載器。在執(zhí)行過程中，它試圖禁用其他Windows安全功能——基于虛擬化的安全（VBS）和Windows Defender——以提高成功部署和隱形操作的機會。在詳細介紹如何實現(xiàn)之前，讓我們先了解一下內(nèi)核驅(qū)動程序和HTTP下載器的基本知識：

內(nèi)核驅(qū)動程序負責：

部署鏈的下一個組件—HTTP下載器；

在被終止運行的情況下保持加載器不被關(guān)閉；

防止從ESP中刪除 bootkit文件；

如果HTTP下載器指示的話，執(zhí)行額外的內(nèi)核有效負載；

根據(jù)HTTP下載器的指示，卸載 bootkit。

HTTP下載器負責：

與C&C通信；

執(zhí)行從C&C收到的命令；

下載并執(zhí)行從C&C接收到的有效負載（支持內(nèi)核有效負載和用戶模式有效負載）。

從安裝程序到HTTP下載器的完整執(zhí)行流程（簡化后）如下圖所示。我們將在下一節(jié)中更詳細地描述這些步驟。

BlackLotus UEFIbootkit執(zhí)行示意圖

BlackLotus執(zhí)行流程

執(zhí)行步驟如下（這些步驟如下圖所示）：

1.UEFI固件執(zhí)行默認的Windows啟動選項，該選項通常存儲在\EFI\Microsoft\boot\bootmgfw.EFI中的文件。正上所述，MokInstaller二進制文件用一個合法的簽名shim替換了這個文件。

2.執(zhí)行shim時，它讀取MokList NVRAM變量，并使用攻擊者先前存儲在其中的證書來驗證第二階段啟動加載程序——位于\EFI\Microsoft\Boot\grubx64.efi中的自簽名BlackLotus UEFI啟動程序。

3.驗證后，shim執(zhí)行 bootkit。

4.bootkit從創(chuàng)建僅啟動VbsPolicyDisable NVRAM變量開始。如本文所述，此變量在啟動期間由Windows OS加載程序評估，如果已定義，則不會初始化核心VBS功能，如HVCI和憑據(jù)保護。

5.在以下步驟中，bootkit繼續(xù)使用UEFIbootkit使用的通用模式。它攔截典型Windows啟動流中包含的組件的執(zhí)行，例如Windows啟動管理器、Windows OS加載器和Windows OS內(nèi)核，并將它們的一些功能掛鉤到內(nèi)存中。另外，它還嘗試通過修復某些驅(qū)動程序來禁用Windows Defender。所有這些都是為了在系統(tǒng)啟動過程的早期階段實現(xiàn)有效負載的執(zhí)行，并避免檢測。以下函數(shù)已掛鉤或修復：

5.1 bootmgfw.efi或bootmgr.efi中的ImgArchStartBootApplication：該函數(shù)通常由bootkit掛鉤，以捕捉Windows OS加載程序（winload.efi）加載到內(nèi)存中但尚未執(zhí)行的時刻——這是執(zhí)行更多內(nèi)存修復的正確時刻。

5.2 winload.efi中的BlImgAllocateImageBuffer：用于為惡意內(nèi)核驅(qū)動程序分配額外的內(nèi)存緩沖區(qū)。

5.3 winload.efi中的OslArchTransferToKernel：連接以捕捉系統(tǒng)內(nèi)核和某些系統(tǒng)驅(qū)動程序已加載到內(nèi)存中但尚未執(zhí)行的時刻，這是執(zhí)行更多內(nèi)存修復的最佳時刻。下面提到的驅(qū)動程序在此掛鉤中進行了修復。下圖顯示了這個掛鉤中負責在內(nèi)存中查找適當驅(qū)動程序的代碼。

5.4 WdBoot.sys和WdFilter.sys：BlackLotus修復了WdBoot.sys和WdFilter.sys（分別是Windows Defender ELAM驅(qū)動程序和Windows Defender文件系統(tǒng)篩選器驅(qū)動程序）的入口點，以立即返回。

5.5 disk.sys：bootkit將disk.sys驅(qū)動程序的入口點掛鉤，以便在系統(tǒng)初始化的早期階段執(zhí)行BlackLotus內(nèi)核驅(qū)動程序。

OslArchTransferToKernel掛鉤的反編譯代碼——修復Windows Defender驅(qū)動程序并搜索disk.sys入口點

6.接下來，當系統(tǒng)內(nèi)核執(zhí)行disk.sys驅(qū)動程序的入口點時，已安裝的掛鉤會跳轉(zhuǎn)到惡意內(nèi)核驅(qū)動程序入口點。惡意代碼反過來恢復原始disk.sys以使系統(tǒng)正常運行，并等待winlogon.exe進程啟動。

7.當惡意驅(qū)動程序檢測到winlogon.exe進程已啟動時，它會向其中注入并執(zhí)行最終的用戶模式組件——HTTP下載器。

內(nèi)核驅(qū)動程序

內(nèi)核驅(qū)動程序主要負責四個任務(wù)：

將HTTP下載器注入到winlogon.exe中，并在線程終止時重新注入它；

保護部署在ESP上的 bootkit文件不被刪除；

解除用戶模式Windows Defender進程MsMpEngine.exe；

與HTTP下載器通信，并在必要時執(zhí)行任何命令。

HTTP下載器持久性

內(nèi)核驅(qū)動程序負責部署HTTP下載程序。當驅(qū)動程序啟動時，它會等待名為winlogon.exe的進程啟動，然后再執(zhí)行任何其他操作。進程啟動后，驅(qū)動程序解密HTTP下載程序二進制文件，將其注入winlogon.exe的地址空間，并在新線程中執(zhí)行。然后，驅(qū)動程序會定期檢查線程是否仍在運行，并在必要時重復注入。如果驅(qū)動程序檢測到內(nèi)核調(diào)試器，則不會部署HTTP下載程序。

保護ESP上的bootkit文件不被刪除

為了保護ESP上的bootkit文件，內(nèi)核驅(qū)動程序使用了一個簡單的技巧。它打開所有要保護的文件，復制并保存其句柄，并使用ObSetHandleAttributes內(nèi)核函數(shù)將HandleFlags（OBJECT_HANDLE_flag_INFORMATION）參數(shù)內(nèi)的ProtectFromClose標志指定為1，從而保護句柄不被任何其他進程關(guān)閉。這將阻止任何刪除或修改受保護文件的嘗試。受保護的文件包括：

ESP:\EFI\Microsoft\Boot\winload.efiESP:\EFI\Microsoft\Boot\bootmgfw.efiESP:\EFI\Microsoft\Boot\grubx64.efi
如果用戶試圖刪除這些受保護的文件，就會出現(xiàn)如下圖所示的情況。

試圖刪除受BlackLotus驅(qū)動程序保護的文件

作為另一層保護，如果用戶或安全軟件能夠取消設(shè)置保護標志并關(guān)閉句柄，內(nèi)核驅(qū)動程序?qū)⒊掷m(xù)監(jiān)視它們，如果句柄不再存在，則通過調(diào)用KeBugCheck（INVALID_kernel_HANDLE）函數(shù)來生成一個BSOD。

解除主Windows Defender進程

內(nèi)核驅(qū)動程序還試圖解除主Windows Defender進程MsMpEng.exe的防護。為此，它通過為每個進程設(shè)置SE_PRIVILEGE_REMOVED屬性來刪除所有進程的令牌權(quán)限。因此，Defender進程應(yīng)該無法正確地完成其工作（例如掃描文件）。但是，由于該功能執(zhí)行得很差，因此可以通過重新啟動MsMpEng.exe進程使其失效。

最新評論