A new technique has emerged that allows bypassing Microsoft's Driver Signature Enforcement (DSE) on fully updated Windows systems, potentially facilitating operating system (OS) downgrade attacks.
“This bypass allows loading unsigned kernel drivers, enabling attackers to deploy custom rootkits that can neutralize security controls, hide processes and network activity, maintain stealth, and much more,” said Alon Leviev, a researcher at SafeBreach, in a report shared with The Hacker News.
The latest findings build upon a prior analysis that revealed two privilege escalation vulnerabilities in the Windows update mechanism (CVE-2024-21302 and CVE-2024-38202). These could be used to revert a current Windows system to a previous, less secure version still harboring unpatched security flaws.
The exploit is embodied in a tool called Windows Downdate, which, according to Leviev, can hijack the Windows Update process to execute undetectable, persistent downgrades on crucial OS components.
The implications are severe, as it offers attackers a new alternative to Bring Your Own Vulnerable Driver (BYOVD) attacks, allowing them to downgrade first-party components, including the OS kernel.
Microsoft addressed CVE-2024-21302 and CVE-2024-38202 with updates on August 13 and October 8, 2024, as part of Patch Tuesday.
Leviev’s latest strategy involves using the Windows Downdate tool to bypass the "ItsNotASecurityBoundary" DSE patch on a fully updated Windows 11 system.
Elastic Security Labs’ Gabriel Landau first documented "ItsNotASecurityBoundary" in July 2024, along with "PPLFault," identifying these as a novel bug category dubbed False File Immutability. Microsoft resolved it this past May.
In essence, the exploit leverages a race condition to swap a verified security catalog file with a malicious variant signed with an authenticode signature for an unsigned kernel driver. The kernel then processes this catalog and loads the driver, allowing attackers to execute code within the kernel.
The DSE bypass works by downgrading the "ci.dll" library to an older version (10.0.22621.1376) that lacks the Microsoft patch.
There is, however, a possible barrier: Virtualization-Based Security (VBS). If VBS is enabled on the host, the Secure Kernel Code Integrity DLL (skci.dll) handles catalog scanning instead of ci.dll. But the default configuration is VBS without a Unified Extensible Firmware Interface (UEFI) lock, allowing attackers to disable it by tampering with the EnableVirtualizationBasedSecurity and RequirePlatformSecurityFeatures registry keys.
In cases where the UEFI lock is active, attackers could still disable VBS by replacing a core file with an invalid counterpart. Here are the steps an attacker would follow:
- Turn off VBS in the Windows Registry or invalidate SecureKernel.exe.
- Downgrade ci.dll to the unpatched version.
- Restart the machine.
- Exploit the ItsNotASecurityBoundary DSE bypass for kernel-level code execution.
This approach is only thwarted when VBS is enabled with a UEFI lock and set to "Mandatory," a flag that causes boot failure if VBS files are corrupted. Microsoft notes, "The Mandatory setting prevents the OS loader from continuing to boot in case the Hypervisor, Secure Kernel, or one of their dependent modules fails to load. Special care should be used before enabling this mode, since, in case of any failure of the virtualization modules, the system will refuse to boot."
To fully prevent the attack, VBS should be configured with UEFI lock and Mandatory mode enabled. In any other mode, attackers may disable the security feature, execute the DLL downgrade, and achieve a DSE bypass.
