Microsoft Windows Secure Kernel Mode Elevation of Privilege Vulnerability CVE-2024-21302-Fixed
Released: Aug 7, 2024
CVSS:3.1 6.7 / 5.8
Summary:-
Microsoft Windows Secure Kernel Mode Elevation of Privilege Vulnerability exists in Windows 10, Windows 11, Windows Server 2016, and higher based systems including Azure Virtual Machines (VM) that support VBS. vulnerability enables an attacker with administrator privileges to replace current versions of Windows system files with outdated versions. By exploiting this vulnerability, an attacker could reintroduce previously mitigated vulnerabilities, circumvent some features of VBS, and exfiltrate data protected by VBS.
Impact:-
The vulnerability has a CVSS score of 6.7, categorized as “Important.” Its potential impact includes:
- Confidentiality: High risk of data exfiltration.
- Integrity: There is a high risk of integrity compromise due to reintroducing old vulnerabilities.
- Availability: High risk as critical system files could be tampered with.
Detection Logic:-
The detection logic consists of the following steps:
1. VBS Status Check: Check the WMI class Win32_DeviceGuard to retrieve the VirtualizationBasedSecurityStatus. This status must be 2 (Enabled and Running).
2. Patch Check: Verify whether the August Operating System patches mentioned in the CVE-2024-21302 are installed.
3. Policy Configuration Check: Verify if the opt-in policy configuration as mentioned in CVE-2024-21302 is applied.
Solution:-
Microsoft released Aug-2024 patch with an opt-in mitigation available as an interim solution to protect from this vulnerability.
For Windows 10 1809 and later, Windows 11 version 21H2 and later, and Windows Server 2019 and later, administrators can deploy a Microsoft-signed revocation policy (SkuSiPolicy.p7b) to block vulnerable, unpatched versions of VBS system files from being loaded by the operating system.
All Windows devices that support VBS are affected by this issue. This includes on-premises physical devices and virtual machines (VMs). VBS is supported on Windows 10 and later Windows versions, and Windows Server 2016 and later Windows Server versions.
The VBS state can be checked through the Microsoft System Information tool (Msinfo32.exe). This tool collects information about your device. After starting Msinfo32.exe, scroll down to the Virtualization-based security row. If the value of this row is Running, VBS is enabled and running.
To query the VBS state from PowerShell, open an elevated Windows PowerShell session and then run the following command:
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard
After running the above PowerShell command, the VBS state status should be one of the following.
VirtualizationBasedSecurityStatus
- 1:-If the field equals 0, VBS is not enabled.
- 2:- If the field equals 1, VBS is enabled but not running.
- 3:-If the field equals 2, VBS is enabled and running.
To fix this vulnerability follow below steps.
1:- Machine should be updated with Aug-2024 or later patch level.
2:- Apply Microsoft revocation policy(SkuSiPolicy.p7b)
How to apply Microsoft revocation policy.
1:-Deploying a Microsoft-signed revocation policy (SkuSiPolicy.p7b)
Run the following commands in an elevated Windows PowerShell prompt:
$PolicyBinary = $env:windir+”\System32\SecureBootUpdates\SkuSiPolicy.p7b”
$MountPoint = ‘C:\EFIMount’
$EFIDestinationFolder = “$MountPoint\EFI\Microsoft\Boot”
$EFIPartition = (Get-Partition | Where-Object IsSystem).AccessPaths[0]
if (-Not (Test-Path $MountPoint)) { New-Item -Path $MountPoint -Type Directory -Force }
mountvol $MountPoint $EFIPartition
if (-Not (Test-Path $EFIDestinationFolder)) { New-Item -Path $EFIDestinationFolder -Type Directory -Force }
Copy-Item -Path $PolicyBinary -Destination $EFIDestinationFolder -Force
mountvol $MountPoint /D
2:-Post this command reboot your device.
3:- Confirm the policy is loaded in the Event Viewer by using the information in the Windows Event logs section.
Note:- To check the environment compatibility make sure to apply Audit policy before applying Microsoft revocation policy.
How to apply Audit Policy:-
Risk:-
As of now above mitigation workaround solution is recommended by Microsoft, With this workaround some risk are associated with it.
User Mode Code Integrity (UMCI). The Microsoft-signed revocation policy enables user mode code integrity so that rules in the policy are applied to user mode binaries. Enforcing these features may introduce compatibility issues with applications and scripts and may prevent them from running.
UEFI Lock and Uninstalling updates. After applying the UEFI lock with the Microsoft-signed revocation policy on a device, the device cannot be reverted if you continue to apply Secure Boot. Even reformatting the disk will not remove the UEFI lock of the mitigation. This means that if you attempt to revert the Windows OS to an earlier state that does not have the applied mitigation, the device will not start, no error message will be displayed, and UEFI will proceed to the next available boot option. This might result in a boot loop. ou must disable Secure Boot to remove the UEFI lock.
External Boot Media. After the UEFI lock mitigations have been applied to a device, external boot media must be updated with the latest Windows updates installed on the device and with the Microsoft-signed revocation policy (SkuSiPolicy.p7b). If external boot media is not updated, the device might not boot from that media.
Windows Recovery Environment. The Windows Recovery Environment (WinRE) on the device must be updated with the latest Windows updates installed on the device before the SkuSipolicy.p7b is applied to the device.
Preboot Execution Environment (PXE) boot. If the mitigation is deployed to a device and you attempt to use PXE boot, the device will not start unless the mitigations are also applied to the network boot sources (root where bootmgfw.efi is present). If a device starts from a network boot source that has the mitigation applied, then the UEFI lock will apply to the device and impact subsequent starts.