Rafal Wojtczuk
rafal@bromium.com

ANALYSIS OF THE ATTACK SURFACE OF
WINDOWS 10 VIRTUALIZATION-BASEDSECURITY

aAgendaupa• Short reminder on VBS architecture• Credential Guard properties and internals• HV Code Integrity properties and internals• Hyper-V security/complexity/attack surface• More details in the whitepaper

aScopeupa• Most of this research done with W10 1511
• Intel’s hardware (when hw mentioned)• Mixed original, little-known and well-knowncontent

VBS architecture

aCredential Guard architectureupa

Picture taken from BH2015
Microsoft presentation

Mimikatz fails on CG-protected box

aCG scenario 1upa
• Admins just enabled CG in Group Policy• No further hardening• Easy to deploy

aCG RPC interfaceupa

LsaIso trustlet, running in VTL1, exposes the above functions via RPC over ALPC port \RPC Control\LSA_ISO_RPC_SERVER

aNtlmIumProtectCredentialupa• Input (from lsass.exe): plaintext credentials• Output (from LsaIso.exe) : blob with encryptedcredentials

aNtlmIumLm20GetNtlm3ChallengeResponseupa• Input (from lsass.exe): blob with encrypted
credentials + NTLM challenge• Output (from LsaIso.exe): NTLM response

aScenario 1 propertiesupa• After logon, no cleartext credentials in lsass• While user is logged in, lsass will auth to remote
servers automatically (SSO), for attacker as well
• If attacker collects encrypted blob, he can force
LsaIso to auth even after logout (until reboot)• DemoCredentials during logon ?
• There is still a problem with how the unencrypted
credentials are initially delivered to VTL1 (which happens
during logon).“rundll32.exe user32.dll,LockWorkStation”.
• If not using smart-card based authentication, then theplaintext credentials can be captured by keylogger andused anywhere, anytime.
• In case of smart-card based authentication, the NTOWF
hashes sent by KDC can be captured and reused.

aCG scenario 2upa
• Credential Guard with armor key protection andsmartcard-based authentication• Nontrivial deployment challenge• Possible to enable without TPM, but in suchcase no real advantage

aCG scenario 2upa

Picture taken from BH2015
Microsoft presentation

aScenario 2 properties• No more cleartext creds in lsass, ever
• Still, as before, until reboot, attacker caninteract with CG and have it perform all SSOsupported authentications for remote resources• There is no reliable way to deliver “user has
logged out, refuse future SSO” message to VTL1

aCG properties summary• Even in the most hardened configuration, once attacker has
SYSTEM privileges, they can silently authenticate as logged-in
user to remote servers, from the compromised machine, untilreboot• No more classical pass-the-hash – but attackers can adapt andstart lateral movement from the same machine, until reboot• In classical pass-the-hash, one can reuse stolen hashes
anytime, from anywhere – thus CG is an improvement• Again, no hypervisor compromise required for the above
attack, just root partition compromiseVBS-enforced code integrity• Windows 10 can enforce code integrity ofusermode binaries, usermode scripts andkernelmode code; the latter via VBS• We focus on kernelmode case
• The goal – not allow execution of any unsigned
code in kernel context, even if the kernel has
been compromised

VBS-enforced code integrity• Basic idea: trusted code (running in VTL1)
agrees to grant execute rights in EPT tables ofthe root partition only for pages storing signedcode• No such page can be both writable andexecutable

Mixing signed & unsigned code
• Common configuration: unsigned usermode code
allowed, unsigned kernelmode denied• Usermode wants to execute unsigned code at C
– VTL1 must grant execute right for C in EPT• Usermode switches to kernelmode, and jumps to C–?

Kernel HVCI is based on secvisor• Separate EPT for code originating from signed
and unsigned page
• Root partition is configured so that any attempt
by unsigned usermode code to enter
kernelmode results in vmexit (and EPT flip)–IDT, GDT limits set to 0, syscall&sysenter disabledKernel HVCI and kernel exploits• Attackers love arbitrary code running in ring0• SMEP a problem, but natural bypass:– Get ROP capability, then clear CR4.SMEP– Or, via write-what-where, clear U/S bit in PT– Run your arbitrary code

• Not working with Kernel HVCI !
• Also, cannot hook kernel code, at least not directly• Data-only exploits, or ROP-only, still fineKernel HVCI bypass, MS16-066• Before MS16-066 fix, there are some pages withRWX permission in root partition (kernelmode)
EPT• Likely artifacts of early boot phase• Attacker can find them by probing each physicalpage for write and execute, in ring0

Kernel HVCI bypass, MS16-066

HYPERV-V SECURITY

[Un]usual threat model• Usual model: hypervisor must be resistant to attacks
coming from unprivileged, worker VMs• Without VBS, root partition is semi-trusted; it cancompromise Hyper-V (no big deal) because– HvCallDisableHypervisor hypercall– Cleartext hiberfile– VTd not enabled• With VBS, the threat comes from the root partition

Necessary support• Secureboot– many vulnerabilities in the past allowing secureboot
bypass• VTd– without it, possible to overwrite hypervisor via DMA• TPM– needed to secure S4, see below

Root partition privileges• Access to privileged hypercalls–Hypervisor Top-Level Functional Specificationmentions 14 hypercalls usable by nonprivileged
VM, and 67 privileged hypercalls. More hypercalls
exist, entirely undocumented.

• Possible to overlook some dangerous
functionality, or e.g. memory corruption bug

Root partition privileges• Access to almost all physical memory range–Without pages allocated for Hyper-V and VTL1–Including• chipset and PCIe MMIO• ACPI NVS–LAPIC and VTd bars not accessible

Root partition privileges• I/O ports: all available except:• 32, 33 (PCH interrupt controller), 160, 161 (same)• 0x64, lpc microcontroller (A20 gate)• 0xcf8, 0xcfc-0xcff – PCI config space• 0x1804. It is PMBASE+4 == PM1_CNT, it holds theSLP_EN bit, that triggers S3 sleep; see below

Root partition privileges• MSR – none available directly except :• three SYSENTER MSRS
• fs/gs/shadow gs base
• So, Hyper-V has at least a chance to reactproperlyProblem 1 – unfiltered MMCFG• MMCFG is a region of physical address space; accessto it results in PCIe config space access– Device-specific registers, memory bars locations• REMAP_LIMIT/REMAP_BASE are locked• Overlapping RAM with PCIe memory bar does notwork• Anything else interesting we can overlap/cover ?

Overlap VTd bars

But write access hangs the tested platform Problem 2 – chipset registers• Some memory-mapped regions, e.g. in
MCHBAR, have thousands of registers, most ofthem undocumented at all• Are all of them locked ? Anything evil can bedone ?
• I do not know

S3 sleep• S3 is fragile from security POV• Boot script hijack vulnerability from 2014 could
be used to take control over the hypervisor– likely all firmware makes were affected• More potential attacks via S3 thinkable (see thewhitepaper)

S4 sleep• S4 is even more fragile from security POV• Need to protect integrity of hiberfile• With VBS, it is encrypted• Need to keep the key secret• If TPM available, the key is sealed to TPM• If no TPM, then the key is cleartext in UEFI variableS4 is insecure without TPM

SMM• SMM is highly-privileged mode of CPU,
unrestricted by hypervisor• Usually, firmware vendors pack quite some
services in SMM; they can be invoked by writeto I/O port 0xb2
• A lot of bugs in SMM found recently

SMM code tends to be buggy

SMM• It is well-known that SMM vulnerability can beused to compromise a hypervisor in runtime– BTW, secureboot as well

• VBS allows direct access to I/O port 0xb2, as
well as to ACPI NVS• Intel researchers demoed searching VTL1
memory for password hashes

SMM abuse example

SMM abuse example

SMM

Summary• Despite its limited scope, VBS is useful• A lot of effort by MS to make it as secure as
possible; still, unusual attack surface• VTd, TPM strictly necessary (with secureboot)• SMM vulnerabilities the greatest threat

Questions ?

Extra slides: Non-VBS-specificthreats• CPU erratas• Rowhammer• Flashable discrete hardware

VTL1 attack surface• RPC services implemented in LsaIso (including RPC
demarshalling code)• 48 services implemented insecurekernel!IumInvokeSecureService (called by nt!
HvlpEnterIumSecureMode)• VTL1 extensively calls into VTL0 to use someservices – need to sanitize all responses

Other funny chipset capabilities• E.g. chipset can program DRAM SPD• Capability locked by sane BIOS
Picture taken from
Wikipedia article
on Serial Presence
Detect