A talk by David “dwizzzle” Weston at Blue Hat 2018
Microsoft is trying to change how security works at a fundamental level. David “dwizzzle” Weston outlines how Microsoft is looking to change the “Ten Immutable Law of Security,” which were first outlined in 2000. These laws, which are listed at the end of this summary, have provided a framework within which security personnel have worked for much of technology’s past, whether they knew it or not. Changing these laws is requiring a different way of looking at how we manage our devices and ensure the security of our data. To do this, Weston outlined several ways that Microsoft is starting to do this differently and the promises they are aiming to fulfill in the future.
Can we use hardware capabilities to redefine Windows security guarantees?
Weston outlines the goals of Microsoft in six areas:
- “All code executes with integrity
- User identities cannot be compromised, spoofed, or stolen
- Attacker with casual physical access cannot modify data or code on the device
- Malicious code cannot persist on a device
- Violations of promises are observable
- All apps and system components have only the privilege they need.”
From these promises he explains how Microsoft is currently providing this service or working toward it.
One point of note is that he does not talk about user identities in this talk. He discusses the other components, which I will outline below.
All code executes with integrity:
The way that Microsoft is working toward this goal is to:
- Prevent arbitrary code generation
- Prevent control-flow hijacking
Current controls in place for arbitrary code generation are the Code Integrity Guard (images must be signed and loaded from valid places) and Arbitrary Code Guard (Prevents dynamic code generation, modification, and execution). To prevent control-flow hijacking, there is currently the Control Flow Guard to enforce control flow integrity on indirect function calls, and a work in progress to enforce control flow integrity on function returns. The overall goals are that:
- Only valid, signed code pages can be mapped by the app
- Code pages are immutable and cannot be modified by the app
- Code execution stays “on the rails” per the control-flow integrity policy
One way that this is being currently employed is through Hypervisor Enforce Code Integrity (HVCI). HVCI uses virtualization page tables managed by security mode (VTL1) to eliminate malicious code from being run against the Hypervisor. HVCI has improved performance available starting on Skylake, and starting in 1803, all new Windows installs will have HVCI by default (MBEC/Kaby Lake+).
In addition to HVCI, Kernel Control Flow Integrity (CFG) also improves protection against control flow hijacking for kernel code. Kernel CFG is paired with HVCI to ensure both code integrity and control flow integrity. Here is the visual representation:
One of the problems with new solutions is that they provide new attack surfaces. Virtualization Based Security highlights the importance of Firmware (SMM) security. So, Microsoft is working with Intel to design a hardware-assisted solution for return address protection. Malicious code running in Firmware is difficult to detect, and arbitrary code execution in SMRAM can be used to defeat Hypervisor, so this push is especially important to ensure that the security features put in place remain in place. This is still I progress with Intel, but red teams and bug bounty programs are currently working on tightening holes in these technologies.
Malicious Code Cannot Persist on a Device
Current technologies use Secure Boot as a static root of trust. This includes OEM UEFI, which has had dozens of vulnerabilities discovered in recent years. To combat this, a System Guard provides a dynamic root of trust:
In the future, Microsoft is looking to merge System Guard with dynamic root of trust measurement (DRTM). This would remove the broad third party UEFI ecosystem from the root of trust and reduces the chances of attacker persistence in early boot by removing the attack surface.
Attacker with casual physical access cannot modify data or code on the device
The goal is to prevent drive-by physical attacks. The goal for the 1803 release is to use IOMMU to block newly attached Thunderbolt 3 devices from using Direct Memory Access until an authorized user is logged in and the screen is unlocked. In future releases, they are looking to harden protection on all external PCI ports and cross-silicon platforms. Here is how the current goal would operate:
All apps and system components have only the privilege they need
The past strategy has been containment with virtualization, which has many strengths, but the high resource requirements, difficult experience for non-technical users, and expensive configuration makes it a hard strategy to implement broadly. Microsoft is offering several improved isolation technologies, including improved software isolation, such as the Microsoft Edge AppContainer Profile, and virtualized isolation, with Application Guard. The container technology that Weston focuses on is called Krypton. The features highlighted are the direct map (which allows resource sharing between guest and host), memory enlightenment (physically-based VMs are statically mapped to reduce the number of memory intercepts generated by the guest), and an integrated scheduler (which removes the extra scheduling layer, and improves CPU resource tracking/management). When IOMMU Base GPU Isolation is used, it limits GPU accessible system memory to only pages the GPU should have access to, as illustrated here:
Violations of promises are observable
Current controls are explained, and it is also shown how they are not true solutions. For example, Patch Guard and Hyper Guard can effectively monitor TCB tampering, but it’s not extensible for consumers. Key boot properties are measure into PCRs, but there is no easy way to consume and extend. The goal is to have a Tamper Evident Windows. And that is the current goal. One way they are trying to achieve this is through System Guard Runtime Attestation, which can potentially provide continuous integrity with the use of the ATP Cloud and an Assertion Engine, as illustrated here:
Windows Defender Security Center can provide alerts on Process Code integrity violations and process privilege escalation, giving security personnel a window into what is happening on individual machines. The Secure attestation technology builds on boot time attestation, and secure enclaves to provide strong tamper resistance, and is included with Windows starting in 1803. Building on Device Health Attestation, the future path is to provide a device health score for true zero trust networking and will take several releases to complete.
Windows devices are getting more secure. It’s good to see that Microsoft is putting so much focus on providing security to everyone, even those with no security background. The Device security features will help provide transparency for administrators and user alike. I am very interested in seeing what they do with the user accounts, as that is one thing that Weston did not discuss during this presentation. However, I’m impressed with the steps they have taken, including in scrapping proposed changes because they are testing internally and found that it would not hold up in the wild. Microsoft has historically been known for rolling out patches without testing them beforehand, which put the burden of troubleshooting on the system admins and security staff. Seeing Microsoft put forward this level of self-correcting behavior makes me hopeful for a future when they can provide a secure product to home and business users, a more user-friendly and defendable piece of technology.