Add option to pass WinPriv through UAC

[niansa]

Hey!

I've been testing this tool and it seems to be working awesomely well! However, one issue that I have experienced is that WInPriv won't be passed to childs that've gone through ACL UAC.
The program I am trying to mess with does exactly that, rendering this tool useless in that case :-/

Thanks for creating this tool anyways!
niansa

[NoMoreFood]

What do you mean by “ACL”?

[niansa]

Access Control, like what happens when you rightclick a program and select "run as admin". What then happens is access control. It often works in the background, you don't notice it but Windows may display an authentication prompt.
I wish I knew the Windows function responsible for this, I attempted detouring StartProcessAsUser but it doesn't seem to be called.

[NoMoreFood]

Ok, that's more commonly referred to as "UAC" or User Account Control. WinPriv should work in those scenarios if the initial (parent) process is already elevated. I think the only way we could make that work for WinPriv is finding the function that starting the process (CreateProcess, etc) and actually prepend the entire WinPriv execution command line to command line is going to be called. You may want to try to use API Monitor (http://www.rohitab.com/apimonitor) to see what function the parent process is running and work from there. I might be able to look at this at some point in the future, but I'm a bit overloaded right now.

[niansa]

I actually meant "UAC", I just mixed them up, haha.
One program that does this and actually is preinstalled everywhere is control.exe (the control panel).

Thanks for the link! I so far relied on process monitor which seems to suck for stuff like this.

I'll attempt to do this myself, and maybe create a pull request 🙂

[niansa]

I found a very informative article about this:
https://www.codeproject.com/Articles/19165/Vista-UAC-The-Definitive-Guide

Pretty sure most of this is still the same today.

AppInfo is, obviously, the key to UAC elevation. ShellExecuteEx() forwards all elevation requests to the AppInfo NT Service via an RPC call. AppInfo then turns around and calls an executable in the SYSTEM context, called "consent.exe". As the name implies, this is the executable that brings up the dialog that the user consents to.

However, consent.exe is not your average, run-of-the-mill application. What you see when the dialog is active is not Session 1's WinSta0\Default. Nope. What you see is a desktop on Session 0. Hence the reason it is called a "secure desktop". consent.exe takes a snapshot of the screen, switches to the Session 0 desktop, plops the screenshot on the desktop, and displays the dialog. It only looks like Session 1's desktop. You can't click on anything but the dialog, because there literally isn't anything to click on. Once you accept/cancel, the desktop is switched again back to Session 1 and consent.exe exits.

AppInfo then takes the results from consent.exe and determines if it needs to start a new process (i.e., you accepted the elevation request). AppInfo then creates a process using the full administrative token (remember that split token thing?) of the logged in user on the Session 1 desktop with a High Integrity Level. If you fire up Task Manager, you can see that elevated processes indeed run as the current user. We know it also runs on the Session 1 desktop because GUI windows can be created, seen, and interacted with.

So I'll try to figure out what RPC exactly is responsible for this and how to intercept it.

[NoMoreFood]

@niansa Did you ever crack this case?

[niansa]

No, unfortunately not. Documentation is just wayyyy too sparse on this.

But now that I think of it – reading ROS sources could be worth a try. If they even implement UAC at all.