Is there a single UAC binary?

27

12

Is there a binary (.exe) in the System32 folder responsible for the Windows UAC functionalities? (e.g., uac.exe). What would happen if that file was forcefully deleted? Would Windows break or fail to boot?

There's no XY problem here; I'm just curious to know what would happen if UAC was forcefully removed from a PC.

Kathy

Posted 2018-03-18T21:43:46.237

Reputation: 283

1You can easily disable UAC. UAC is a function of the kernel. What you want isn’t possible – Ramhound – 2018-03-18T22:38:11.920

There is a file win32k.sys https://www.technize.net/windows-vista-and-windows-7-kernel-bug-can-bypass-uac/ and apparently that file in a pre patched windows, can be manipulated/changed..to disable UAC. Alternatively one can disable UAC in a normal manner, though it's not an EXE file

– barlop – 2018-03-18T23:37:43.850

You can disable UAC using various methods, for example https://superuser.com/questions/1013702/completely-disable-uac-in-windows-10. I'm thinking that if you remove it some other hack-ish way, you'd get mostly the same effect, albeit with the errors in the answers below about missing binaries.

– YetAnotherRandomUser – 2018-03-19T01:54:35.857

@barlop, win32k.sys is just the kernel side of the Windows subsystem. In other words, the core code used by everything. I would not recommend attempting to change it. http://pasotech.altervista.org/windows_internals/Win32KSYS.pdf

– Dark Falcon – 2018-03-20T07:53:27.093

@DarkFalcon There is probably more to the "kernel side of the windows subsystem" than that. And I was not advising that one "change it"! What do you think somebody is going to do? Open it in notepad? I never suggested such a thing! Open a hex editor? better, but I didn't suggest that either! And nobody would do that and change anything unless they had some idea what they wanted to change, which would take a certain skill level! – barlop – 2018-03-20T12:32:26.983

Answers

56

UAC is a multi-component architechture implemented by multiple binaries

User Account Control (UAC) refers to several components that together form the UAC architecture. I'll briefly review some of them along with the binaries responsible for their implementation, but first here's an overview of the UAC architecture from the Microsoft Docs article How User Account Control Works:

enter image description here

Local Security Authority (LSA) / Filtered Token

Conceptually the "first" component of UAC is implemented by the Local Security Authority subsystem which handles creation of a user's Access Token during the logon process. Starting with Windows Vista, the logon process was modified so that when an Administrator logs on with UAC enabled, the LSA subsystem generates two separate access tokens for the user:

  1. One with full administrator access, and
  2. A second "filtered token" with standard user access

As shown here this process is different than that of a standard user logon:

enter image description here

The LSA subsystem service lives in the lsass.exe process.

Virtualization

Added in Windows 7, File and Registry Virtualization is a component of UAC that shims older applications that are not-UAC compliant but only require administrative rights in order to access certain protected areas of the filesystem or Registry:

When an administrative application that is not UAC compliant attempts to write to a protected directory, such as Program Files, UAC gives the application its own virtualized view of the resource it is attempting to change. The virtualized copy is maintained in the user's profile.

Source

By redirection these access attempts to areas that don't require admin permissions, these applications continue to function despite UAC being enabled on the system.

This virtualization is implemented in the Kernel.

Application Information Service

The Application Information Service (AIS) reads an application's manifest and works with the UAC Consent Prompt to determine if an application is allowed to execute with elevated rights (i.e. start in the context of the non-filtered administrative-level access token created at logon). This blog post provides a good overview of its role in the UAC process:

AIS Facilitates the running of interactive applications with additional administrative privileges. If this service is stopped, users will be unable to launch applications with the additional administrative privileges they may require....The shell checks with this service when it launches an application. AIS is the one that reads the manifest and the ‘trustInfo’ xml section that has the requirements for the ‘requestedExecutionLevel’...

Here's a graphic that follows the above quote detailing AIS' role in the UAC Consent Prompt process:

enter image description here

The AIS is implemented in the DLL appinfo.dll which is executed by svchost.exe.

Consent Prompt

@BenN's answer explains the key role of the (in)famous UAC Consent Prompt. This is implemented in consent.exe and is responsible for getting the user's consent or an administrative user's credentials in order to allow launching of an application requiring admin rights.

Secure Desktop

The Secure Desktop is where the UAC Consent Prompt is displayed by default. Microsoft's UACBlog tells us what's unique about this Desktop compared to the User Desktop:

You most commonly interact with [the Secure Desktop] when you log on to Windows since the Logon UI runs on the Secure Desktop. The Secure Desktop’s primary difference from the User Desktop is that only trusted processes running as SYSTEM are allowed to run here (i.e. nothing running as the User’s privilege level) and the path to get to the Secure Desktop from the User Desktop must also be trusted through the entire chain.

The idea behind using it when asking the user's consent to run an application with elevated permissions is that malware cannot imitate the Secure Desktop unless it already has administrative rights, in which case tricking a user into granting them is moot.


Conclusion: UAC is not just one binary. It's a fabric of interwoven subsystems.

There are yet other aspects of the UAC architecture not covered here, but this should provide enough evidence for the facts that:

  1. UAC is not implemented in a single binary.
  2. If enabled, it's an integral part of performing administrative tasks.

Since its introduction in Windows Vista it has been deeply integrated into key portions of the operating system, making it infeasible delete all the code responsible for UAC without breaking other things (such as your ability to logon!)

I think it's safe to say that if you "forcefully deleted" UAC you would break Windows.

I say Reinstate Monica

Posted 2018-03-18T21:43:46.237

Reputation: 21 477

1

FWIW https://www.technize.net/windows-vista-and-windows-7-kernel-bug-can-bypass-uac/ based on that link, it seems the file win32k.sys seems to play a role I notice that file.exe identifies it as "PE32+ executable (native) x86-64, for MS Windows"

– barlop – 2018-03-18T23:39:13.320

win32k.sys is -- essentially -- a large chunk of the kernel. Of course it plays a role in UAC. It is Windows. – Roger Lipscombe – 2018-03-20T11:43:25.563

25

As Twisty excellently explained, there are a lot of components that help implement UAC. The part of UAC that people are most familiar with is the elevation/consent dialog:

This is provided by consent.exe, "Consent UI for administrative applications." I tried renaming it in a VM and seeing what happens. As expected, no elevation prompts appear when using "run as administrator" — instead, you get a file-not-found error that blames the thing you're trying to elevate:

not found

Trying to use any Control Panel UI element that requires elevation (i.e. has the shield icon), even if logged in as an administrator, fails with similar errors. Trying to launch administrative things from the Start menu produces a slightly different error:

no app associated

Depending on the ACL set when doing the rename that broke everything, it could be impossible to fix this from within the OS, since file operations can require elevation (even if they doesn't usually produce the consent dialog). Normal-user-like activities don't seem to be degraded, though.

Ben N

Posted 2018-03-18T21:43:46.237

Reputation: 32 973

I'm curious as to what will happen if it's replaced with an exe that silently returns true using whichever system Windows checks the result of the prompt. Will Windows verify the file in some way? – muru – 2018-03-19T01:40:31.450

Very interesting. Can you trigger functions in Windows that require elevation but by an internal component of Windows that would be considered "signed and manifested for silent elevation" (e.g. starting Device Manager logged on as the built-in Administrator)? In any case, I've reworded my concluding paragraph as I feel your information invalidates the assertion that you can't break UAC without preventing Windows from booting (though I maintain removing all components involved in UAC, including things like CreateProcess API code, would wreak havoc). – I say Reinstate Monica – 2018-03-19T01:58:44.090

3@muru, I'd guess consent.exe doesn't just return true or false, but instead the token to execute under. Which means you can't get from a normal user to an administrator token without actually authenticating as the admin. – Joey – 2018-03-19T06:03:04.220

6@muru Windows does verify and replace many system files, not sure if this one is included or not. However, from a security standpoint, the point is moot - to replace consent.exe, you need administrator privileges in the first place, so there's no privilege escalation even if it were possible to replace the way you imagine it. – Luaan – 2018-03-19T11:45:54.483

3Just to include it since the thought came to my mind. You could still boot the machine into Linux or something to replace the file. But that requires physical access to the machine, which is basically administrative access as well. So it's still not a security concern – DeadChex – 2018-03-19T15:53:36.753

@Joey : Does the same Trojan consent.exe get used for all users, including an admin user, making it possible to snag an administrator token for future use by non-admin accounts? – Eric Towers – 2018-03-19T18:52:11.513

1

@EricTowers Yes, but since administrative privileges are required to alter consent.exe, an attacker who can do that is already on the other side of the airtight hatchway and has more straightforward ways of doing bad things.

– Ben N – 2018-03-19T19:01:50.057

1

@TwistyImpersonator Interesting question! Silent elevation seems to also trigger a Consent run (per process start monitoring) when done under a normal admin account. The built-in Administrator account is not subject to UAC, so all its programs are already elevated and Consent doesn't get involved. You can change that behavior using this security policy.

– Ben N – 2018-03-19T19:32:54.413

I'm pretty sure that the OS checks if consent.exe is properly signed by Microsoft when trying to run it. There's no point in signing your own binaries if you're not going to check if they are signed. – meneldal – 2018-03-20T05:53:58.513