WINDOWS 10 VIRTUALIZATION-BASED SECURITY

Recommendations

Info

The situation is still improved in comparison to the case without CG: attacker needs to launch the lateral movement from the same machine that the encrypted blob was collected on. Also, after reboot, the encrypted blob is no longer valid – if we pass the saved encrypted blob to NtlmIumLm20GetNtlm3ChallengeResponse then it returns STATUS_DECRYPTION_FAILED. 4) There is still a problem with how the unencrypted credentials are initially delivered to VTL1 (which happens during logon). Attacker can entice the user to perform logon again, while the machine is under attacker’s control, e.g. by locking the workstation (just run “rundll32.exe user32.dll,LockWorkStation”). If not using smart-card based authentication, then the plaintext credentials can be captured by keylogger and used anywhere, anytime. In case of smart-card based authentication, the NTOWF hashes sent by KDC can be captured and reused. This problem is solved below – but it requires much more configuration, and limiting flexibility. Scenario 2: Credential Guard with armor key protection and smartcard-based authentication As described in [sop], it is possible to configure an account so that it can authenticate only from a single machine. Another key (machine key, specific to the machine) is needed in order to decrypt the authentication material received from KDC. With CG enabled, the machine key is available only in VTL1 (protected against rogue root partition), so only CG running on a particular machine can decrypt the authentication material. In such case, the above problem no 4 goes away. Still, same as before, the scenarios 2 and 3 are possible: until reboot, attacker can interact with CG and have it perform all necessary authentications (supported by SSO) for remote resources; again, all attacker’s actions must originate from the initially-compromised machine. There is no reliable way to deliver “user has logged out, refuse SSO” message to VTL1 – it would have to be produced by the root partition. The threat model it that it has been compromised, so even if such a message was supported and recognized by VTL1, compromised lsass could just elect to not send it. One thing worth noting is that the only secret needed permanently by CG is the machine key, and it is why TPM is required in order to protect it reliably against rogue root partition. Without TPM, there is no way to store the machine key permanently in a manner preventing the root partition from reading it 3 . VBS-enforced code integrity One can configure Windows <strong>10</strong> to enforce code integrity of usermode binaries, usermode scripts 4 and kernelmode code. In this paper, we will talk about details of implementation of VBS-enforced kernelmode code integrity. The goal is ambitious – not allow execution of any unsigned code in kernel context, even if the kernel has been compromised 5 . The basic idea is that the trusted code (running in VTL1) agrees to grant 3 See also the below discussion on protecting keys used during S4. 4 Judging by [pow], powershell scripts integrity is enforced in usermode and can be easily bypassed by attaching a debugger to the powershell process.
execute rights in EPT tables of the root partition only for pages storing signed code. As the root partition does not have direct access to its EPT table, then even malware having kernel privileges cannot alter these permissions. The problem arises when the configuration allows unsigned usermode code and only signed kernelmode code. Intel CPUs use same EPT table regardless whether running VM usermode or kernelmode. The problematic scenario is: 1) Usermode tries to execute unsigned code stored in physical page X. DG needs to approve it, by marking X as executable in EPT. 2) VM changes to kernelmode, and attempts to execute same code as above. Because X was just marked as executable, this operation will succeed, violating the policy. This problem was considered in secvisor paper [scv], and although it is not stated explicitly in any official MS document, VBS-enforced KMCI uses very similar approach. The scenario below starts with usermode running unsigned code: 1) The root partition is configured so that each attempt to transition to kernelmode causes vmexit, namely: a. Root partition usermode runs with both IDT limit and GDT limit set to 0. Thus, any action involving reloading CS must throw #GP exception. VMCS exception bitmap (when running usermode) is all 1. b. IA32_EFER.SCE is cleared (so "syscall" instruction throws #UD) and IA32_SYSENTER_CS is zeroed (so that "sysenter" instruction throws #GP). 2) Upon detecting attempt to transition to kernelmode, hypervisor changes EPT to a version (let’s name it sEPT) suitable for kernel – it has execute permission bit set only for pages containing signed code. IDT and GDT limits are restored to sanity, context is manually switched to kernelmode, and execution is resumed. 3) When kernelmode attempts to return to usermode, then either: a. RIP points to unsigned usermode code. Page storing such code is never marked as executable in the EPT used to run kernelmode. So, vmexit (EPT violation) happens, DG detects that the root partition attempts to return to usermode, so it emulates just this, additionally flipping EPT pointer back to the EPT tables specific for unsigned usermode (let’s name it uEPT). b. RIP points to signed usermode code. No vmexit happens, VM continues to run with sEPT, until it tries to execute unsigned usermode code (and then vmexit and switch to uEPT happens). c. RIP points to kernel code. Sane kernel never returns to usermode with RIP pointing to kernel code, but if it happens, such scenario does not allow breaking the policy (because all kernel code is signed). Depending on the page tables used and whether SMEP is available, this might cause an exception in kernelmode. Naturally, in case of unsigned usermode code, such approach results in many additional vmexits, and this impacts performance. In the worst case scenario involving Hyper-V running in VM and the 5 Actually, the last statement is a conjecture - the author has not found any official explicit description on what precisely VBS KMCI is supposed to ensure. Perhaps, the name is self-descriptive, at least to some.
Page 1 and 2: ANALYSIS OF THE ATTACK SURFACE OF W
Page 3: The workflow is as follows: 1) On s
Page 7 and 8: attacker does not have ability to l
Page 9 and 10: The topic of hypervisor security ha
Page 11 and 12: Utilizing the availability of the a
Page 13 and 14: In order to prevent this, both the
Page 15 and 16: The author used a runtime vulnerabi
Page 17 and 18: The most interesting cases were CVE
Page 19 and 20: Documentation/raw/master/tlfs/Hyper

WINDOWS 10 VIRTUALIZATION-BASED SECURITY

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?