Bypassing Administrator Protection by Abusing UI Access

A security researcher has detailed multiple vulnerabilities in Windows' User Account Control (UAC) system, specifically concerning the "UI Access" feature, which were present even before the introduction of Administrator Protection. These bypasses, totaling nine discovered by James Forshaw, have since been addressed by Microsoft. This article focuses on five of these issues, stemming from the fundamental design of UI Access and its long-standing implications for UAC security.

Historically, prior to Windows Vista, any application running on a user's desktop could manipulate windows created by other applications, including those with elevated privileges. This vulnerability, known as a "Shatter Attack," allowed lower-privileged users to potentially elevate their own permissions by interacting with privileged user interfaces. A common mitigation was to remove user interface components from highly privileged code.

With the advent of UAC, which allows processes to run at different privilege levels on the same desktop, Microsoft introduced User Interface Privacy Isolation (UIPI). UIPI leverages Mandatory Integrity Control to prevent lower-integrity processes from interacting with windows created by higher-integrity processes. For instance, a "Medium" integrity process is blocked from sending messages or using window hooks on windows created by a "High" integrity process.

However, this restriction posed a problem for accessibility tools, such as screen readers, which often ran at a lower integrity level. These tools needed to interact with applications running at higher integrity levels to function. To accommodate these essential accessibility features, Windows Vista introduced the "UI Access" flag for process access tokens.

Processes with the UI Access flag set gain special permissions to bypass many UIPI restrictions. This flag can only be enabled by processes with the SE_TCB_NAME privilege, typically requiring a system service. When a UI Access process is launched through the standard UAC elevation flow (RAiLaunchAdminProcess RPC call), it does not display a consent prompt, ensuring accessibility applications can function without user intervention.

To prevent malicious applications from falsely claiming accessibility roles, Microsoft implemented several checks for UI Access. The executable must possess an embedded manifest with the `uiAccess` attribute set to `true`, be signed by a certificate trusted by the local machine's root certificate store, and reside in an administrator-only location on the system drive, such as Program Files or System32.

If these criteria are met, the service can enable the UI Access flag and adjust the process's integrity level. For a limited user initiating the process, the integrity level is elevated to "High." This elevation to High integrity prevents lower-integrity processes from accessing the newly created UI Access process, thus mitigating code injection.

Despite these safeguards, the UI Access feature itself presented a security challenge, particularly in relation to the newly introduced Administrator Protection. The UI Access flag permits bypassing certain restrictions, such as sending window messages to higher-integrity processes. However, it does not allow for more intrusive actions like using window hooks for code injection.

The core issue arises when a UI Access process is launched by a limited user. This process gains a High integrity level, effectively allowing it to compromise any other process running at the same level on the desktop, regardless of the user. Crucially, this elevation occurs silently, without a UAC prompt, and bypasses the profile separation intended by Administrator Protection because the UI Access process runs as the limited user. This creates a pathway to bypass Administrator Protection by executing arbitrary code within a High integrity UI Access process, which can then target other administrator processes.