In an evolving landscape of cybersecurity, software and operating system vendors are increasingly focused on fortifying their products against potential threats. The urgency stems from a stark reality: while threat actors invest considerable time identifying zero-day vulnerabilities, they can exploit existing weaknesses in outdated software with alarming speed. This has prompted a troubling trend where attackers seek to downgrade systems to earlier, more vulnerable versions.
A notable case illustrating this phenomenon is the emergence of the BlackLotus UEFI BootKit malware. This sophisticated malware effectively downgraded the Windows Boot Manager to a version susceptible to exploitation via CVE-2022-21894. This vulnerability enables attackers to bypass Secure Boot, thereby disabling essential OS security mechanisms and securing persistent access to compromised systems.
Remarkably, the BlackLotus UEFI BootKit demonstrated its capability to operate on fully patched and updated Windows 11 systems, even with Secure Boot enabled. Researchers have harnessed this method to achieve privilege escalation and circumvent security features, raising significant concerns about the robustness of current security measures.
Are you from SOC and DFIR Teams? – Analyse Malware Incidents & get live Access with ANY.RUN -> Free Access
Windows Zero-day Downgrade Attack
In a groundbreaking discovery, researchers identified a critical flaw that allowed them to take control of the Windows Update process. This led to the creation of a tool dubbed Windows Downdate, capable of downgrading updates and bypassing crucial verification steps, including Integrity Verification and Trusted Installer Enforcement.
Through this method, the researchers successfully downgraded critical OS components such as DLLs, drivers, and the NT kernel. Surprisingly, the operating system continued to report itself as fully updated, rendering it unable to install future updates. Recovery and scanning tools also failed to detect the underlying issues within the operating system.
Further escalating the attack, researchers managed to downgrade key security features, including Credential Guard’s Isolated User Mode process, Secure Kernel, and Hyper-V’s hypervisor, exposing previously patched privilege escalation vulnerabilities. This culminated in a scenario where a fully patched Windows machine became vulnerable to thousands of previously fixed vulnerabilities, effectively transforming them into zero-days while misleading the OS into believing it remained “fully patched.”
Windows Update Architecture
During the recent Black Hat USA 2024 conference, Safebreach detailed the intricacies of this attack. According to Windows Documentation, the Windows Update architecture comprises an update client and an update server. The update client typically operates with Administrator privileges, while the Trusted Installer is enforced on the server side, ensuring that even Administrators and NT SYSTEM cannot modify system files without going through the Trusted Installer.
The Windows Update flow follows a structured process:
- The client requests the server to perform updates contained in an update folder.
- The server validates the integrity of the update folder.
- Upon verification, the server processes the update folder to finalize the update files, which are stored in a server-controlled folder inaccessible to the client.
- The server logs actions in a list named “pending.xml,” detailing which files to update, their source and destination, and other relevant information.
- Finally, during a system reboot, the actions listed are executed, completing the update process.
Update Folder Investigation
The update folder houses various components, each containing critical files necessary for the update process:
- MUM files: Contain Microsoft Update metadata, including component dependencies and installation order.
- Manifest files: Provide installation-specific information such as file paths and registry keys.
- Differential files: Delta files that, when combined with base files, create the complete update file.
- Catalog files: Contain digital signatures for MUM and manifest files.
It is noteworthy that only catalog files are explicitly signed, while manifest and MUM files are indirectly signed through the catalogs. Differential files, however, are not signed but dictate the final content of the update file.
Further investigation revealed an intriguing registry key named “PoqexecCmdline,” which holds the executable responsible for parsing the action list. Notably, the Trusted Installer was not enforced on this key, allowing for control over all update actions.
The pending.xml file grants extensive capabilities, including creating, deleting, and moving files, as well as manipulating registry keys and values. By altering the source in the destination of file actions, researchers could effectively downgrade patches.
Attack Methodology
In summary, the research revealed that no malicious elevation of Trusted Installer privileges was necessary for the attack to succeed. The methodology relied on three key actions:
- Setting the Trusted Installer service to Auto-Start.
- Adding the pending.xml path in the registry.
- Including the pending.xml identifier in the registry without Trusted Installer enforcement.
What is particularly alarming about this attack is its undetectable nature. By masquerading as a legitimate system update, the attack allowed the system to report itself as “fully updated,” despite being downgraded.
Persistence was achieved through the action list parser poqexec.exe, which is not digitally signed and can be supplied with empty updates to install any newly available updates.
Crucially, the actions performed during this attack cannot be reversed. The repair utility SFC.exe is also not digitally signed and can be supplied with a false patch that fails to detect any corruption. Additionally, researchers successfully targeted:
- Windows VBS,
- Bypassed VBS UEFI Lock,
- Isolated User Mode Processes in Secure Mode,
- Secure Mode’s Kernel, and
- Hyper-V’s Hypervisor.
In response to these findings, Microsoft issued two CVEs, CVE-2024-21302 and CVE-2024-38202, acknowledging the work of SafeBreach in identifying and responsibly reporting the vulnerabilities. The company stated, “We appreciate the work of SafeBreach in identifying and responsibly reporting this vulnerability through a coordinated vulnerability disclosure. We are actively developing mitigations to protect against these risks while following an extensive process involving a thorough investigation, update development across all affected versions, and compatibility testing to ensure maximized customer protection with minimized operational disruption.”
How to Build a Security Framework With Limited Resources IT Security Team (PDF) - Free Guide
