Swedish Windows Security User Group

VBS and HVCI-enabled devices help protect from advanced attacks

Escalation of privilege attacks are a malicious actor’s best friend, and they often target sensitive information stored in memory. These kinds of attacks can turn a minor user mode compromise into a full compromise of your OS and device. To combat these kinds of attacks, Microsoft developed virtualization-based security (VBS) and Hypervisor-protected code integrity (HVCI, also commonly referred to as memory integrity). VBS and HVCI use the power of hardware capabilities like virtualization to provide better protection against common and sophisticated malware by performing sensitive security operations in an isolated environment.

Today, Microsoft announced that the new Surface Pro 7+ for Business will ship with these Windows enhanced hardware security features enabled out of the box to give customers even stronger security that is built-in and turned on by default. The Surface Pro 7+ for Business joins existing recently shipped devices like the Surface Book 3, Surface Laptop Go, and the Surface Pro X in enabling VBS and HVCI by default.

Surface enables added security features by default to combat common threats

Surface devices are used by customers across a variety of mission critical scenarios – from collaborating in Office on important documents to Microsoft Teams calls with coworkers across the globe. Providing robust protection against the latest malware and ransomware is a critical goal for Surface as customers expect that their devices and data can withstand common attacks. To meet this customer need, Surface has worked diligently across multiple hardware platforms to enable VBS and HVCI by default on capable new Surface models, including the Surface Book 3 and Surface Laptop Go, to provide the latest security protections consistently across different form factors and price points available to customers.

VBS and HVCI create and isolate a region of memory from the normal operating system using hardware virtualization capabilities. This security capability can stop most escalation of privilege attacks. The security subsystems running in the isolated environment provided by the hypervisor can help enforce HVCI protections, including preventing kernel memory pages from being both writeable and executable.

VBS provides significant security gains against practical attacks including several we saw last year, including human-operated ransomware attacks like RobbinHood and sophisticated malware attacks like Trickbot, which employ kernel drivers and techniques that can be mitigated by HVCI. Our research shows that there were 60% fewer active malware reports from machines reporting detections to Microsoft 365 Defender with HVCI enabled compared to systems without HVCI.  The Surface Book 3 shipped in May 2020 and the Surface Laptop Go shipped in October 2020, and users may not have noticed they are running VBS and are therefore better protected based on the work done under the hood.

The simple choice for device security

Endpoint security has always been at the core of Surface devices. Our engineering team has been using a unified approach to firmware protection and device security since 2015 through complete end-to-end ownership of hardware design, in-house firmware development, and a holistic approach to device updates and management.

For Surface, our Unified Extensible Firmware Interface (UEFI) is written in-house, continuously maintained through Windows Update, and fully managed through the cloud by Microsoft Endpoint Manager. This level of control enables enterprises to minimize risk and maximize control at the firmware level before the device even starts Windows 10. IT organizations now have the ability through the cloud to disable a camera or disable the ability to boot from USB all at the pre-boot firmware level. The result is a reduced attack vector that is critical to endpoint protection. Microsoft is making this UEFI* available broadly via open source through Project Mu on GitHub.

To protect the firmware and initial boot of your device, Surface enables Secure boot to ensure an authentic version of Windows 10 is started and make certain the firmware is as genuine as it was when it left the factory. Surface also ensures that each commercial device includes a security processor (TPM 2.0) to provide advanced encryption capabilities such as BitLocker to secure and encrypt your data and Windows Hello to enable passwordless sign-in. Each of these built-in security options helps protect your device from malicious software attacks.

With the necessary hardware and OS settings configured during manufacturing, the simple choice for customers looking for devices with advanced Windows security enabled is a Windows PC. Today, the Surface Pro 7 + for Business, Surface Book 3, Surface Laptop Go, and Surface Pro X already ship with VBS and HVCI enabled by default. Future Surface models on capable silicon will ship with these capabilities also enabled by default. Most recent Surface devices and Windows PCs from many other OEMs that have virtualization support are also capable of using these features. Customers can turn on the Memory integrity feature in the device security settings, which also automatically checks if devices are capable.

The post New Surface PCs enable virtualization-based security (VBS) by default to empower customers to do more, securely appeared first on Microsoft Security.

Ensuring that the platform firmware is healthy and trustworthy is fundamental to guaranteeing that powerful platform security features like Hypervisor-protected code integrity (HVCI) and Windows Defender Credential Guard are functioning as expected. Windows 10 achieves this by leveraging a hardware-based root of trust that ensures unauthorized code like Unified Extensible Firmware Interface (UEFI) malware cannot take root before the Windows bootloader launches.

Key to defending the hypervisor, and by extension the rest of the OS, from such low-level threats is protecting System Management Mode (SMM), an execution mode in x86-based processors that runs at a higher effective privilege than the hypervisor. Because of its traditionally unfettered access to memory and device resources, SMM is a known vector of attack for gaining access to the OS and hardware. SMM is particularly vulnerable to threats like confused deputy attacks, in which malicious code tricks another code with higher privileges to perform certain activities. One could have perfect code in SMM and still be affected by behavior like trampolining into secure kernel code.

Sometimes referred to as “Ring -2”, SMM is used by OEMs to interact with hardware like NV RAM, emulate hardware functionality, handle hardware interrupts or errata, and perform other functions. SMM runs in the form of interrupt handlers that are triggered by timers or access to certain memory, registers, or hardware resources. OEM drivers and runtime firmware services may explicitly trap SMM to control certain hardware functionality.

To stop sophisticated attacks from taking control of the system through SMM, the OS must have enforcement or oversight of SMM’s behavior. As part of Secured-core PCs and System Guard, Intel and AMD have developed mechanisms to isolate SMM from the OS by enforcing and reporting what resources SMM has access to.

SMM isolation

Isolating SMM is implemented in three parts: OEMs implement a policy that states what they require access to; the chip vendor enforces this policy on SMIs; and the chip vendor reports compliance to this policy to the OS.

The policy provided by the OEM is a list detailing the resources that the SMI handlers require access to. This policy is validated and enforced by the chipset vendors’ specific enforcement mechanism detailed later. The OS does not have any control over what the policy is; it is only guaranteed enforcement of the policy stated.

Trusted Computing Base (Tcb) Launch, introduced in the Windows implementation of Dynamic Root of Trust (DRTM), gets the enforced policy from the chip vendor’s reporting mechanism. Because resource access is specific to a platform’s needs, Tcb Launch compares the OEM’s SMM access policy with several levels of Windows SMM isolation requirements to determine the level of isolation provided. The isolation level achieved by the OEM’s policy is measured for attestation and is reported to the OS.

The isolation levels consist of increasing restrictions on what SMIs may access, as well as enforcement capabilities required on the system. An example of an isolation requirement is that SMIs may not access memory owned by the OS. Additionally, these requirements can include restrictions on the following resources:

1. SMM page configuration lockdown
2. Static page tables
3. Model-Specific Register (MSR) access
4. IO port access
5. Processor state save access

In order to ensure a consistent security promise for customers using Secured-core PCs if the  minimum requirements are not met, the DRTM measurements are capped, and local and remote attestation fail. SMM isolation is tied with DRTM because without DRTM, the OS cannot trust anything evaluated by the boot environment as it is not protected from the influence of SMM. SMIs are suspended during DRTM, so the new root of trust established by DRTM can evaluate the security of the SMM access policy.

Not only are these protections utilized by Windows for local secrets protection, but remote attestation tools can also leverage this information to determine the security posture of a specific device. This attestation report can be used to prevent access to sensitive network files, for example, unless a certain combination of features is present.

AMD solution (SMM Supervisor)

During UEFI boot phase, the SMM Supervisor is loaded as a UEFI driver. This driver is signed by AMD and authenticated by the Platform Security Processor (PSP) at the time of DRTM launch. Failure of authentication will fail DRTM. (It is also under firmware anti-rollback protection by PSP.)

SMM Supervisor provides and initializes the SMI entry routine (the first code block executed after SMI is triggered). This routine is also signed by AMD and authenticated by PSP at the time of DRTM launch. Upon DRTM event, PSP also verifies that the SMI entry is properly configured to this authenticated block. Failure of this authentication will also result in DRTM failure.

SMM Supervisor marks critical pages—including SMM Supervisor code block, internal data, the page table itself, exception handler, as well as processor save state—as supervisor pages, accessible only  from current privilege level 0 (CPL0, the most privileged level).

Immediately after SMI is triggered, the SMI entry routine demotes the system to execute under CPL3 (least privileged level) before executing any third party SMI handlers. From CPL3 environment, MSR, IO, and supervisor pages access, critical register changes such as CR3, as well as privileged instructions such as “hlt” and “cli” all end up as General Protection Fault enforced by CPU hardware.

In order for SMI handlers under CPL3 to access privileged data and register, SMM Supervisor provides syscall interface to allow third-party SMI handlers to make such requests. The backend of the syscall interface, which resides in SMM supervisor, is controlled by SMM secure policy. The said policy is a deny list that can be customized per platform to determine which MSRs, IOs, or memory regions can be accessed from CPL3. SMM secure policy is reported to and verified by OS secure loader during DRTM event.

Intel Hardware Shield

Intel® Hardware Shield, a part of the Intel vPro® platform, uses CPU hardware and firmware to enforce the platform’s SMM access policy. Generationally, these capabilities evolve using new CPU hardware features in conjunction with existing CPU capabilities to strengthen related micro-architectural flows and provide new register locks in support of related firmware hardening^*.

• Intel vPro® platform with 8^th Generation Intel® Core vPro® processors introduced firmware hardening and hardware-locked static page table support to reduce SMM privilege with regard to memory and to lock the memory configuration. These new locks include: CR3 lock, MSEG lock, SMBASE lock, etc.
• Intel vPro platform with 9^th Generation Intel Core vPro processors added an Intel signed SMM module enables attestation of the SMM memory configuration using Intel® Trusted Execution Technology (Intel® TXT), a component of Intel® Hardware Shield, via PCR17. The module first verifies the integrity of the hardened SMM code used to enforce the SMM access policy. It then reports this, as well as the details of the policy, back to the OS. Therefore, the OS can verify the trustworthiness of SMM and evaluate the platform’s SMM access policy without the possibility of interference from SMI handlers.
• Intel vPro platform with 10^th Generation Intel Core vPro processors enhanced the verified CPL0 SMM components to create a privilege separation with SMI handlers in order to extend policy enforcement to MSRs, IO ports, and SMM state save (access policy may vary by platform). The reporting mechanism was extended to include these capabilities as well.

*No product or component can be absolutely secure.

Secured-core PCs give the simplest experience for customers to get Secure Launch and SMM protection

Enabling SMM protection and System Guard Secure Launch may be achieved when the following support is present:

• Intel, AMD, or ARM virtualization extensions
• Trusted Platform Module (TPM) 2.0
• On Intel: TXT support in the BIOS
• On AMD: SKINIT package must be integrated in the Windows system image
• On Qualcomm: Implements DRTM TrustZone application and supports SMC memory protections.
• Kernel DMA Protection (learn more)

Further configuration information and requirements can be found here.On Secured-core PCs, virtualization-based security is supported, and hardware-backed security features like System Guard Secure Launch with SMM Protections are enabled by default. Customers do not need to worry about  configuring the necessary functionality as Secured-core PCs come with the right configurations from OEMs, thereby providing the simplest path to the most secure Windows 10 systems. Learn more about the line of Secured-core PCs available today.

 

The post System Management Mode deep dive: How SMM isolation hardens the platform appeared first on Microsoft Security.

Gaining kernel privileges by taking advantage of legitimate but vulnerable kernel drivers has become an established tool of choice for advanced adversaries. Multiple malware attacks, including RobbinHood, Uroburos, Derusbi, GrayFish, and Sauron, and campaigns by the threat actor STRONTIUM, have leveraged driver vulnerabilities (for example, CVE-2008-3431, CVE-2013-3956, CVE-2009-0824, CVE-2010-1592, etc.) to gain kernel privileges and, in some cases, effectively disable security agents on compromised machines.

Defending against these types of threats—whether those that live off the land by using what’s already on the machine or those that bring in vulnerable drivers as part of their attack chain—requires a fresh approach to security, one that combines threat defense on multiple levels: silicon, operating system, and cloud. Microsoft brought this chip-to-cloud approach with Azure Sphere, the integrated security solution for IoT devices and equipment. We brought the same approach to securing endpoint devices through Secured-core PCs.

Secured-core PCs combine virtualization, operating system, and hardware and firmware protection. Along with Microsoft Defender Advanced Threat Protection, Secured-core PCs provide end-to-end protection against advanced threats.

Hardware profile guaranteed to support the latest hardware-backed security features

Microsoft worked internally and externally with OEM partners Lenovo, HP, Dell, Panasonic, Dynabook, and Getac to introduce a new a class of devices, Secured-core PCs. Secured-core PCs address the need for customers to perform the complex decision flow of mapping which security feature (e.g., hypervisor-protected code integrity (HVCI), virtualization-based security (VBS), Windows Defender Credential Guard) are supported by which hardware (e.g., TPM 1.0, 2.0, etc.).

With Secured-core PCs, customers no longer need to make this complex decision; they’re assured that these devices support the latest hardware-backed security features.

Hardware-backed security features enabled by default

Secured-core PCs have the hardware-backed security featured enabled by default, removing the need for customers to test and enable these features, which require a combination of BIOS and OS settings changes.

Because both BIOS settings and OS settings are enabled out of the box with these devices, the burden to enable these features onsite is removed for customers. The following hardware-backed security features are enabled by default on any Secured-core PC:

 

Security promise	Technical features
Protect with hardware root of trust	TPM 2.0 or higher TPM support enabled by default Virtualization-based security (VBS) enabled
Defend against firmware attack	Windows Defender System guard enabled
Defend against vulnerable and malicious drivers	Hypervisor-protected code integrity (HVCI) enabled
Defend against unverified code execution	Arbitrary code generation and control flow hijacking protection [CFG, xFG, CET, ACG, CIG, KDP] enabled
Defend against limited physical access, data attacks	Kernel DMA protection enabled
Protect identities and secrets from external threats	Credential Guard enabled

While some of these features have previously existed, customers had the burden of (1) choosing the right hardware profile that supported all of these features and (2) enabling these features on their devices. With Secured-core PCs, these hardware-backed security features are assured to work on the hardware and are enabled by default.

Advanced security features: Secure device risk, anti-tampering, driver control, firmware control, supply-chain interdiction, and more

The hardware-backed security features that are enabled by default, along with a combination of Secured-core services, seamlessly integrate with Microsoft Defender ATP, lighting up additional security scenarios and providing unified protection against the entire attack chain.

In this blog, we will showcase how Secured-core PC features deliver strong driver controls that protects against threats that use vulnerable drivers to elevate privilege, using the RobbinHood ransomware as example.

Case study: Secured-core PCs vs. RobbinHood ransomware

RobbinHood ransomware is distributed as a packed executable that contains multiple binaries. One of these files is a Gigabyte driver (GDRV.sys), which has a vulnerability that  could allow elevation of privilege, enabling an adversary to gain kernel privileges. In RobbinHood campaigns, adversaries use these kernel privileges to disable kernel-mode signing to facilitate the loading of an unsigned driver. The unsigned malicious driver is then used to disable security products from the kernel.

RobbinHood is not an isolated threat leveraging a vulnerable driver to achieve elevation of privilege. In the last two years, the Microsoft Defender ATP Research Team has seen a rise in the use of vulnerable drivers by adversaries, ranging from commodity malware to nation-state level attacks. In addition to vulnerable drivers, there are also drivers that are vulnerable by design (also referred to as “wormhole drivers”), which can break the security promise of the platform by opening up direct access to kernel-level arbitrary memory read/write, MSRs.

In our research, we identified over 50 vendors that have published many such wormhole drivers. We actively work with these vendors and determine an action plan to remediate these drivers. In order to further help customers identify these drivers and take necessary measures, we built an automated way in which we can block vulnerable drivers, and that is updated through Windows update. Customers can also manage their own blocklist as outlined in the sections below.

Preventive defenses

Two of the security promises of Secured-core PCs are directly applicable to preventing RobbinHood attacks:

• Defending against vulnerable and malicious drivers
• Defending against unverified code execution

Defending against vulnerable and malicious drivers

Secured-core PCs are the latest hardware to provide driver control out of the box, with baseline configuration already set. Driver control is provided by a combination of HVCI & Windows Defender Application Control (WDAC) technologies.

Every driver loaded into the kernel is verified by HVCI before it’s allowed to run. HVCI runs in a hardware-protected execution environment isolated from the kernel space and cannot be tampered with by other code running in the kernel, including drivers.

Driver control uses HVCI & WDAC technologies to perform the following operations:

1. Validity and memory integrity enforcement at load-time and runtime

HVCI uses hardware-based virtualization and the hypervisor (the same hypervisor also used in Azure) to protect Windows kernel mode processes from injection and execution of malicious or unverified code. The integrity of code that runs in the Windows kernel is validated by HVCI according to the kernel signing policy applied to the device. Additionally, kernel memory pages are never simultaneously writable and executable. This makes Secured-core PCs highly resistant to malicious software attempting to gain code execution in the kernel.

In the case of GDRV.sys, which is the driver used by the RobbinHood malware, if the vulnerable driver is successfully loaded and then exploited, the runtime memory integrity check would protect the critical components. Thus, an attack to change ci!g_CiOptions and nt!g_CiEnabled, would be ineffective, as the kernel ignores changes to the variables coming from the general kernel space. And, as code integrity is enabled by default, the malicious driver RBNL.sys wouldn’t load.

The image below shows an event log from a Secured-core PC showing runtime memory integrity check preventing the CI options from being tampered with by RobbinHood and, subsequently, preventing the malicious driver RBNL.sys from being loaded.

Because runtime memory integrity check is enabled by default on Secured-core PCs, RobbinHood wouldn’t be able to disable code integrity on these machines.

2. Blocklist check

While the most ideal scenario is for enterprises to set customer-specific allows lists, it can be a complex undertaking. To help customers, HVCI uses a blocklist of drivers that are blocked from loading. This blocklist is supplied in two ways:

• • Microsoft-supplied blocklist

Microsoft threat research teams continuously monitor the threat ecosystem and update the list of drivers that in the Microsoft-supplied blocklist. This blocklist is pushed down to devices via Windows update.

We’ve heard from customers that they’d like to provide a list of drivers that should be on the generic Microsoft-supplied blocklist. We’re working on a new feature that allow customers to submit drivers that they’d like us to review and add to the Microsoft-supplied blocklist.

• • Customer-specific blocklist

We recognize that there are situations where customers want a blocklist specific to their organization. By default, any validly signed driver is accepted, but customers can choose to reduce the list of accepted drivers by choosing only WHQL signed drivers. These are drivers that are submitted to Microsoft for signing and are run through a number of tests before being signed.

Devices can apply a custom code integrity policy that customers can use to define their own specific blocklist. This article has more information on how to create such a customer specific blocklist. Below is an example of a customer-specific blocklist that blocks the vulnerable driver GDRV.sys.

Defending against unverified code execution and kernel data corruption attacks

There are several unverified code execution mitigations built-in to Windows. These are readily available on Secured-core PCs.

The RobbinHood attack utilized the vulnerable GDRV.sys driver to change a crucial variable within the system memory. Although HVCI already protects against the attack on g_CiOptions, other areas of memory may still be susceptible, and we need broader defense against kernel data corruption attacks.

In addition to existing mitigations, Windows is introducing a new feature called Kernel Data Protection (KDP), which provides driver developers and software running in the Windows kernel (and the OS code itself) with the ability to mark some kernel memory containing sensitive information as read-only protected. The memory is protected through the second level address translation (SLAT) tables by the hypervisor, such that no software running in VTL0 have access to the protected memory. KDP does not protect executable pages, as those are already protected with HVCI.

Many kernel components have data that is set only once during boot and remains unchanged for the rest of the boot cycle. The first release of KDP protects the static data sections of a driver. In the future, we’re also planning to provide APIs to dynamically allocate and release protected initialized pool memory.

Secured-core PCs have KDP enabled by default.

Detection defenses

As observed in RobbinHood attacks, once the threat gains kernel-level privilege, the threat turns off system defenses, including the endpoint protection agent. Secured-core PCs provide a monitoring agent that utilizes virtualization-based security and runs in this protected environment.

The monitoring agent performs several functions. The ones relevant for this case study are:

• Secure anti-tampering for security agents
• Secure monitoring of Windows

Secure anti-tampering for security agents

This monitoring agent watches for attempts to tamper with the security agents. For Microsoft Defender ATP customers, these are integrated into alerts that are surfaced in Microsoft Defender Security Center.

Secure monitoring of Windows

The agent also monitors several areas of Windows, including checking for kernel exploit behavior that are often used to elevate privileges. In this particular case, the monitoring agent detected a token tampering assertion.

Secured-core PCs have both VBS and this secure monitoring agent turned on by default.

Conclusion

As this case study demonstrates, more and more threats are becoming so advanced that they can bypass software-only based defenses. Secured-core PCs are protected from RobbinHood and similar threats by default.

Customers can also get similar protection on traditional devices as long as they have the necessary hardware and are configured correctly. Specifically, the following features need to be enabled: Secure boot, HVCI (enables VBS), KDP (automatically turned on when VBS is on), KDMA (Thunderbolt only) and Windows Defender System Guard.

With Secured-core PCs, however, customers get a seamless chip to cloud security pattern that starts from a strong hardware root of trust and works with cloud services and Microsoft Defender ATP to aggregate and normalize the alerts from hardware elements to provide end-to-end endpoint security.

Overall improved endpoint protection accrues to the broader Microsoft Threat Protection, which combines and orchestrates into a single solutions the capabilities of Microsoft Defender ATP, Office 365 ATP, Azure ATP, and Microsoft Cloud App Security to provide comprehensive, cross-domain protection for endpoints, email and data, identities, and apps.

 

The post Secured-core PCs: A brief showcase of chip-to-cloud security against kernel attacks appeared first on Microsoft Security.