Researchers Discover Vulnerability in Microsoft Windows Kernel Allowing OS Downgrade Attacks
A new attack technique has been uncovered that can bypass Microsoft’s Driver Signature Enforcement (DSE) on fully updated Windows systems, enabling OS downgrade attacks.
“This bypass allows attackers to load unsigned kernel drivers, making it possible to deploy custom rootkits that can disable security controls, conceal processes and network activity, maintain stealth, and much more,” SafeBreach researcher Alon Leviev explained in a report.
The discovery builds upon prior research revealing two privilege escalation vulnerabilities in the Windows update process (CVE-2024-21302 and CVE-2024-38202) that could be exploited to roll back current Windows software to an older, vulnerable version.
According to Leviev, the exploit, presented as a Windows Downdate tool, can hijack the Windows Update process to carry out undetectable, persistent, and irreversible downgrades of critical OS components.
This technique has serious implications. It provides attackers with a more sophisticated alternative to Bring Your Own Vulnerable Driver (BYOVD) attacks. It allows them to downgrade first-party components, including the OS kernel itself, rather than relying on third-party drivers.
Microsoft has since addressed the vulnerabilities CVE-2024-21302 and CVE-2024-38202 in its Patch Tuesday updates on August 13 and October 8, 2024.
Leviev’s latest approach uses the downgrade tool to roll back the “ItsNotASecurityBoundary” DSE bypass patch on fully patched Windows 11 systems. Originally identified by Elastic Security Labs researcher Gabriel Landau in July 2024, alongside PPLFault, this flaw was part of a new bug class termed False File Immutability, which Microsoft fixed in May.
The exploit leverages a race condition to swap a verified security catalog file with a malicious one containing an Authenticode signature for an unsigned kernel driver. Once the malicious catalog is in place, the attacker prompts the kernel to load the driver.
By parsing the altered security catalog, Microsoft’s code integrity mechanism—responsible for file verification via the kernel library ci.dll
—mistakenly validates the rogue driver’s signature, allowing the attacker to execute arbitrary code within the kernel.
The DSE bypass is executed by using the downgrade tool to replace the “ci.dll” library with an older, vulnerable version (10.0.22621.1376), effectively undoing Microsoft’s patch.
There is a protective measure that could thwart this bypass, however: if Virtualization-Based Security (VBS) is enabled on the target system, catalog scanning is handled by the Secure Kernel Code Integrity DLL (skci.dll) rather than ci.dll, reinforcing kernel integrity.
It’s important to note that VBS often runs without a Unified Extensible Firmware Interface (UEFI) Lock by default. This configuration allows an attacker to disable it by modifying the EnableVirtualizationBasedSecurity
and RequirePlatformSecurityFeatures
registry keys. Even with UEFI lock enabled, attackers could potentially disable VBS by replacing essential files with invalid versions.
The steps for exploitation are as follows:
- Disable VBS through registry edits or by invalidating
SecureKernel.exe
- Downgrade
ci.dll
to an unpatched version - Restart the machine
- Exploit the ItsNotASecurityBoundary DSE bypass for kernel-level code execution
The bypass would fail only if VBS is enabled with a UEFI lock and a “Mandatory” flag. The Mandatory mode, which causes the system to fail at boot if VBS files are corrupted, is set manually via a registry modification.
According to Microsoft’s documentation, “The Mandatory setting prevents the OS loader from continuing to boot if the Hypervisor, Secure Kernel, or one of their dependent modules fails to load. Special care should be taken before enabling this mode, as any failure of the virtualization modules will prevent the system from booting.”
To fully mitigate this attack, VBS must be enabled with both the UEFI lock and the Mandatory flag. Without this configuration, an attacker could potentially disable the security feature, perform the DLL downgrade, and achieve a DSE bypass.
Post Comment