基于虛擬化的安全（part1）：引導過程
一、前言
本文是覆蓋基于虛擬化的安全和設備保護功能的文章的一部分。這些文章的目的是從技術的角度分享這些功能以便更好的理解。這第一篇文章將涵蓋系統引導過程，從Windows bootloader到VTL0啟動。
二、基于虛擬化的安全
基于虛擬化的安全(VBS)是微軟Windows10和Windows Server2016的一個主要的安全特性。例如，DeviceGuard和CredentialGuard都依賴它。DeviceGuard允許系統阻止任何不受信任的程序。同時CredentialGuard允許系統隔離lsass.exe進程，以便阻止類似Mimikatz等工具內存讀取密碼。
這個新功能的主要思想是使用硬件虛擬化技術(例如Intel VT-x)，以便在兩個虛擬機(VM)之間實現強隔離，并且將來功能可能更豐富。這些技術允許虛擬機管理器(VMM)使用擴展頁表(EPT)來對物理頁設置不同的權限。換句話說，一個VM能夠在它的頁表入口(PTE)設置一個物理頁可寫(+W)，并且VMM能夠通過在它的EPT上設置適當的權限來授權或阻止這種行為。
基于虛擬化的安全依賴Hyper-V技術，其將產生不同虛擬信任等級(VTL)的虛擬機。Hyper-V包括一個hypervisor，并且任何操作系統，甚至主操作系統，都包含在VM中。這個主操作系統(Windows)被認為是根VM。Hyper-V信任它且接受像控制其他VM的管理命令。其他的VM可能是“開明的”，如果這樣，則向Hyper-V發送受限消息以便他們自己管理。
VTL是有序號的，更高的是最受信任的。現在有兩個VTL：
1. VTL0，是一個普通的環境，且基本包含標準的Windows操作系統。
2. VTL1，是一個安全的環境，且包含一個微內核和安全的應用程序，稱為trustlet。
圖1 – 基于虛擬化的安全的概覽
CredentialGuard安全機制使用這個技術在VTL1 trustlet(lsaiso.exe，上圖中“Isolated LSA”)中隔離關鍵的lsass.exe進程，甚至使得VTL0內核不能訪問它的內存。只有消息可以從VTL0轉發到隔離的進程，有效的阻止了像Mimikatz這類的密碼和哈希收集工具。
DeviceGuard安全機制使得VTL0內核地址空間的W^X內存緩解(物理頁不能同時具有可執行和可寫權限)，并且接受包含授權代碼簽名者的策略。如果VTL0內核想要使一個物理頁可執行，它必須請求VTL1來改變(圖中的“HVCI”)，它會根據策略校驗簽名。對于用戶模式的代碼，這不起作用，只有VTL0內核才請求簽名驗證。策略在引導啟動時加載，且之后不能修改，只有強制用戶重啟才能加載新的策略。
策略也是被簽名的：在這種情況下，授權簽名者在UEFI變量中設置，且新的策略將校驗這個簽名者。UEFI變量設置他們的Setup和Boot標志，意味著在啟動后他們將無法被訪問和修改。為了清除這些變量，本地用戶必須使用一個自定義的微軟EFI bootloader重啟，在用戶交互操作(通過輸入密碼)后移除他們。
因此，VBS強依賴SecureBoot。引導加載器的完整性必須被校驗，因為它負責加載策略、Hyper-V和VTL1等等。
如果你對設備保護的細節感興趣，你能閱讀這個MDSN的文章：https://blogs.technet.microsoft.com/ash/2016/03/02/windows-10-device-guard-and-credential-guard-demystified/。
我們也鼓勵你閱讀Alex lonescu和Rafal Wojtczuk的BlackHat 2015/2016的演講，將有很大幫助：
http://www.alex-ionescu.com/blackhat2015.pdf
https://www.youtube.com/watch?v=LqaWIn4y26E
https://www.blackhat.com/docs/us-16/materials/us-16-Wojtczuk-Analysis-Of-The-Attack-Surface-Of-Windows-10-Virtualization-Based-Security.pdf
https://www.blackhat.com/docs/us-16/materials/us-16-Wojtczuk-Analysis-Of-The-Attack-Surface-Of-Windows-10-Virtualization-Based-Security-wp.pdf
https://www.youtube.com/watch?v=_646Gmr_uo0
本文中，我們將涵蓋系統引導過程，從Windows bootloader到VTL0啟動。為了分析VBS怎么在引導過程期間初始化自身，下面的Windows 10 1607的一些文件已經被逆向過了：
- Bootmgr.efi：EFI引導加載器(一小部分)
- Winload.efi：EFI Windows加載器
- Hvix.exe：Hyper-V(相當小的一部分)
- Ntoskrnl.exe：NTOS內核
- Securekernel.exe：安全內核
- Ci.dll：VTL0代碼完整性
- Skci.dll：VTL1代碼完整性
因此讓我們來深入到VBS引導過程中，從winload.efi的執行開始，到ntoskrnl.exe的入口點執行。
三、引導過程
引導過程可以總結為5個必須的步驟：
- Bootmgr.efi是第一個加載的組件。由SecureBoot驗證并執行
- Bootmgr.efi加載并校驗winload.efi
- Winload加載并校驗VBS配置
- Winload加載并校驗Hyper-V和VTL0/VTL1內核組件
- Winload退出EFI模式，啟動Hyper-V
1. Bootmgr.efi
當系統開始引導，bootmgr.efi是第一個被加載執行的。它的完整性和簽名已經由Secure Boot UEFI代碼校驗過。為了能夠識別過期的簽名，DBX數據庫包含了過期的簽名(截至2016年底，這個數據庫包含了71個黑名單和未知的SHA256的哈希值)。在bootmgr.efi的最后，執行將轉到winload.efi的入口點：OslpMain/OslMain。
OslpMain首先調用OslpPrepareTarget，其是winload.efi的核心函數。它將初始化hypervisor，內核等。但是先會使用OslSetVsmPolicy初始化VBS配置。
2. VBS策略加載
OslSetVsmPolicy首先校驗VbsPolicyDisabled EFI變量的值(參見下面的微軟命名空間)。如果設置了，這個變量是0，意味著沒有憑據保護配置將要加載。這個EFI變量因此將在引導時禁用憑據保護(并且能夠在VTL0 ring3調用設置權限)。如果沒有設置，配置將從SYSTEM注冊表的hive中加載，并且由BlVsmSetSystemPolicy調用執行，其將讀取和更新VbsPolicy EFI 變量。相應的值被存儲到全局變量BlVsmpSystemPolicy中。如果UEFI鎖開啟，這個EFI變量被設置，并且不能通過winload.efi禁用(它不能移除它，只能使用自定義的EFI代碼才能)。
函數OslpPrepareTarget也會調用OslpProcessSIPolicy(被調用兩次，第一次直接從函數OslInitializeCodeIntegrity中調用)。OslpProcessSIPolicy使用3個EFI變量“pools”來校驗SI策略簽名。每個pool包含3個EFI變量，第一個包含策略，第二個包含版本，第三個包含授權的策略更新簽名者。例如，對于C:\Windows\System32\CodeIntegrity\SIPolicy.p7b，變量是Si，SiPolicyVersion和SiPolicyUpdateSigners。如果“version”和“update signers”變量被設置，系統將增強SI策略簽名：它必須是存在且正確的簽名，否則引導將失敗。通過BlSiPolicyIsSignedPolicyRequired函數來驗證它自己。
3種策略和相關的變量總結如下：
我們不確定“revokeSiPolicy”和“skuPolicy”的目的，但是他們似乎和普通的“SiPolicy”使用類似。
3. Hyper-V和內核組件的加載
執行將轉移到OslArchHypervisorSetup函數，其需要使用與執行的步驟相應的參數來調用，從0開始。在第一次，它將初始化Hyper-V(加載hvloader.efi且通過HvlpLaunchHvLoader執行它)。SecureBoot設置通過OslInitializeCodeIntegrity來校驗。
OslpPrepareTarget然后加載NTOS內核(ntoskrnl.exe)，并且使用OslpLoadAllModules函數來加載hal.dll和mcupdate.dll模塊。然后“Local Key”和“Identification Key”由OslVsmProvisionLKey和OslVsmProvisionIdk函數加載。
此時，NTOS內核初始化了但還沒喲啟動。以步驟“0”為參數的OslVsmSetup被調用(與OslArchHypervisorSetup一樣：以“步驟”為參數)，首先校驗Hyper-V已經啟動，然后初始化OslVsmLoaderBlock(參數在初始化期間由安全內核提供)。然后，OslVsmSetup加載安全內核(securekernel.exe)，并且通過OslpVsmLoadModules函數加載它依賴的skci.dll(OslLoadImage再次被用來校驗他們的簽名)。EFI變量OslLoaderIndications第一位被設置為1。
最后，OslVsmSetup函數再次被調用，但是參數是步驟“1”。這個觸發了OslVsmLoaderBlock的初始化。
當函數OslpPrepareTarget返回后，VBS參數已經被驗證完了，并且NTOS和安全內核都被加載了。他們的入口點地址被存儲在全局變量OslpVsmSystemStartup和OslEntryPoint中(securekernel.exe和ntoskrnl.exe)以便將來使用。
四、微軟EFI變量
VBS EFI變量屬于命名空間：{0x77FA9ABD, 0x0359, 0x4D32, 0xBD, 0x60, 0x28, 0xF4, 0xE7, 0x8F, 0x78, 0x4B}。這些變量有他們的“Boot”和“Setup”屬性設置，因此在EFI引導階段后他們的訪問和修改是不被允許的。
然而轉儲他們是可能的，以便在逆向分析中使用。與VBS相關的EFI變量和他們響應的用法總結如下：
為了轉儲這些變量的內容，關閉安全啟動和使用一個簡單的EFI自定義的引導啟動器(gnu-efi和VisualStudio能完美實現)。一些變量轉儲如下：
五、Hyper-V和安全內核啟動
回到OslpPrepareTarget，現在開始執行啟動Hyper-V和分割VTL0及VTL1空間。這個過程總結如下：
Winload在“第一個“Hyper-V VM中運行
Winload調用安全內核的入口點(EP)
securekernel初始化自身，請求Hyper-V內存保護
securekernel請求VTL1驗證
Hyper-V啟用VTL1(“第二個“VM)，在ShvlpVtlEntry中返回
通過ShvlpVtlReturn，securekernel(現在是VTL1)返回到winload(現在是VTL0)
Winload調用ntoskrnl入口點
下面是securekernel初始化前后的狀態(VTL0 VM是藍色塊，VTL1是綠色塊，Hyper-V是橙色塊)：
圖2 – securekernel初始化前后的狀態對比
繼續執行，通過調用OslFwpKernelSetupPhase1退出EFI模式，并且以“1“參數調用OslArchHypervisorSetup啟動Hyper-V。Hvix64通過向HvlpSavedRsp保存的RSP啟動并且將HvlReturnFromHypervisor傳給hvix64。當HvlpReturnFromHypervisor被命中，使用cpuid指令來驗證啟動，并且RSP被重置。我們確實處在第一個虛擬機中，其將很快變成VTL1。
OslVsmSetup再次被調用(step“2”)：
- 校驗VBS參數
- 驗證Hyper-V正確運行
- 修改OslVsmLoaderBlock設置
- 在相同塊中復制OslVsmLKeyArray(Local Key)和OslVsmIdk(“Identification Key”)
調用儲存在OslpVsmSystemStartup中的安全內核的入口點，指定OslVsmLoaderBlock和它的大小為參數。
然后安全內核將執行它的初始化，并且將調用SkmiProtectSecureKernelPages以便安裝它自己的內存，但是也注冊Hyper-V時間攔截例程(HyperGuard和它的Skpg*前綴的例程)。根據http://www.sandpile.org/x86/msr.htm，對MSR的操作由SkpgxInterceptMsr攔截處理：
- 0x1B(APIC_BASE)
- 0x1004(?)
- 0x1005(?)
- 0x1006(?)
- 0x100C(?)
- 0xC0000080(EFER)
- 0xC0000081(STAR)
- 0xC0000082(LSTAR)
- 0xC0000083(CSTAR)
- 0xC0000084(FMASK)
- 0xC0000103(TSC_AUX)
- 0x174(SEP_SEL)
- 0x175(SEP_RSP)
- 0x176(SEP_RIP)
- 0x1a0(MISC_ENABLE)
我們的假設是這個處理器的設置是為了捕獲VTL0中CPL轉變，來阻止關鍵的MSR修改。還有兩個其他的例程，SkpgxInterceptRegisters和SkpgInterceptRepHypercall。前者可能是攔截CRXXX注冊操作的方法(例如，寫CR4能禁用SMEP)，后者是攔截未授權的調用(然而這些只是猜測)。
關于HyperGuard，似乎通過SkpgVerifyExtents執行VTL0完整性校驗。SkpgHyperguardRuntime被調用，可能是計劃執行的(使用SkpgSetTimer)。
HyperGuard處理器和回調函數被復制到SkpgContext(由SkpgAllocateContext和SkpgInitializeContext初始化)。
記住上個章節只是個假設，可能是錯誤的，因為我們現在沒能在VTL1 HyperGuard/PatchGuard例程中花費太多時間。
在初始化的最后，安全內核將執行兩個調用：
- 0x0F，ShvlEnableVpVtl，指定一個ShvlpVtl1Entry函數指針
- 0x12，ShvlpVtlCall，它不會在任何其他地方使用，并且使用它自己的跳板函數(在下篇文章給出更多細節)。
ShvlpVtl1Entry以SkpPrepareForReturnToNormalMode結束，并且這個過程會使Hyper-V開啟VTL0和VTL1，回到ShvlpVtl1Entry，再回到winload.efi進入到VTL0的上下文。
最終，當回到winload.efi的主函數，將通過OslArchTransferToKernel執行NTOS的入口點,它使用OslEntryPoint調用入口點。
然后執行下一個操作，就像Windows在正常環境中啟動，只是現在NTOS內核知道了VBS相關的組件(如設備保護)。
六、總結
基于虛擬化的安全是Windows10安全功能的一個關鍵組件。通過VBS的安全內核的初始化，我們希望這個文章將給想要深入分析這個功能的逆向者幫助。
在第二部分，我們將涵蓋VTL0和VTL1怎么內核通信和Hyper-V調用怎么實現。
