I worked on some server 2008 builds recently and was pretty annoyed that you couldn’t remove calc and mspaint using the AIK… Why would MS make these mandatory on a Server OS?

Have you tried this proof of concept on Server 2008 R2 beta??

I can see where MS are coming from when they say the code has to get on the machine first, but if that’s their argument then we don’t need UAC prompts at all. Clearly they think we do need UAC prompts — or that people want to see them occasionally to *feel* secure — but as it is in build 7000 and build 7022 the UAC prompts provide the worst of both worlds: Insecurity and Inconvenience.

Personally, I don’t mind UAC prompts too much so I’ll go for Always Prompt and choose Security and Inconvenience. People who trust everything that’s running might want to leave UAC on but have it Never Prompt and get Insecurity and Convenience. (not that this is an option in the Win7 UAC control panel, despite already being possible on Vista :( ) Either seems reasonable to me.

I also don’t understand how MS (or at least the E7 blog people; perhaps they don’t represent MS as a whole) can dismiss a flaw for requiring code to be on the box when methods for getting code to run on a box are found all the time. It’s like they want us to find an end-to-end sequence of flaws before they’ll take any of them seriously, which is ridiculous. Working attacks are almost always a blend of several flaws and you don’t wait for someone to combine them before you start fixing them.

If I remember correctly, unsigned drivers get a big red warning when the user attempts to install it. Of course, this occurs only after the UAC prompt with the highest UAC setting.

This flaw will no doubt be exploited, and it only becomes a question of when. The question of how such file gets on the system is irrelevant (even if Microsoft argues otherwise), because UAC fails to notify the users for consent for privileged operations.

(It took more time to re-do the GUI and make the videos than to turn the “copy a file” concept into “own the machine”. Like I said, if you can copy to System32 and Program Files then it’s game over, as the second of these new videos shows dramatically. Or perhaps over-dramatically. Well, I hadn’t seen the Win7 self-recovery process before so I figured it might be interesting to other people and left it in.)

The first video shows a bit more about how Win7′s COM elevation stuff works:

Mirror 1: http://nudel.kelbv.com/W7E_VID_INT/W7E_VID_INT.htm
Mirror 2: http://leo.lss.com.au/W7E_VID_INT/W7E_VID_INT.htm

The second shows this new code completely hosing a machine without a UAC prompt, in case people don’t realise what “You can open an admin command prompt” means from the first vid. heh:

Mirror 1: http://nudel.kelbv.com/W7E_VID_DRA/W7E_VID_DRA.htm
Mirror 2: http://leo.lss.com.au/W7E_VID_DRA/W7E_VID_DRA.htm

I also posted some corrections to my page (linked from the vids), at the top for now until I work them into the main body.

BTW, Cacl.exe and Notepad.exe both have access to create elevated COM objects without prompting. How on earth is that sensible considering that neither process would ever need it? So far it appears that all signed in-box MS executables have the special access. Why make the attack surface larger than it has to be?

That’s what the program’s second button demonstrates. That button creates the same object in the same way but does it within the process — i.e. the normal way — instead of injecting a thread into Explorer.exe. The code that is run by both buttons is identical — exactly the same function and inputs — and the only difference between the two buttons is which process that code is executed within. The first button copies the function & arguments into Explorer.exe and then starts a thread within Explorer.exe to execute them.

If the code executes within Explorer then the elevated IFileOperation COM object can be created without a UAC prompt. If the exact same code executes within my program then a UAC prompt is triggered and the COM object is only created if the user clicks ‘Yes’.

The only ways to avoid a prompt when clicking the program’s second button — the one that creates the object in the normal way — is to run the program elevated or to disable UAC or UAC prompts completely.

I’ve sent you a private message with a correct source-code details. Apologies for the mix-up. :( Some how the file got truncated.

His program is simply creating an elevated IFileOperation COM object. If the program requests it directly, you get a UAC prompt. If, however, it injects a thread into the Explorer process, and this injected thread creates it, it does not show a UAC prompt. Therefore, in Windows 7 beta with the default UAC settings, it is possible for ANY process to gain access to an elevated IFileOperation object (and presumably any other COM object that supports elevation) without the user actually seeing a UAC prompt.

Of course, once you have an elevated IFileOperation object, you can pretty much do anything you like…

Processes do not perform elevation tasks. Processes simply -request- elevation and one of two things happen (simplistic version): The requested new process/task is determined to be white-listed and elevated without prompt -or- the user is prompted for action.

Explorer.exe is not an elevated process. As there appears to be a white-list for COM as well, I think you vastly over-engineered your proof-of-concept, i.e. your injection into Explorer is completely unnecessary. A simple third-party application should do, as it’ll be in the same sandbox as Explorer.

Have you tested this without the injection vector?

I’ve dropped a note about my thing to the E7 blog’s contact page. (Update: Got a quick reply already.) I imagine there are better ways to notify them but I don’t know them and I figure that’ll work one way or another. Rafael’s also been looking at what I found and I guess he already knows who to notify if he finds anything interesting.

I’m glad that MS are going to fix the UAC control panel issues. Sounds like they’re doing the right thing there. It will be interesting if they can do anything about the other exploits. They could remove RunDll32.exe’s elevation flag but I wonder which components depended on that? Even so, I fear there may not be a quick/easy fix for the code-injection problem (which is of course fairly irrelevant while the RunDll32.exe problem exists, except as a reminder that fixing RunDll32.exe/MMC.exe/etc. alone won’t solve everything).

I don’t fully buy the idea (on the E7 blog) that exploits which require locally running code are not important… (That’s what they seem to be saying, anyway.) If that was the case then we wouldn’t need UAC elevation prompts at all and we could let any process elevate whenever it wants. I do agree that remote code exploits are far more of an issue than local ones (of course!), but I don’t think that means we should dismiss that fact that on a default Win 7 box absolutely any process (except for protected mode IE, basically) can elevate to admin when and if it wants to.

The good news is that if UAC is at the highest level then my code-injection thing is worthless as it will trigger a UAC prompt. I have not uncovered anything that can bypass UAC at its highest level.

Had you notify of MS of the code-injection problem you discovered?
Does this work if the UAC setting was at the highest?

Microsoft just released an update concerning the first flaw discovered for UAC, in which UAC is not prompted when the setting changes. They’re also aware of the auto-elevate issues, but I don’t think they have commented on this issue yet. You can find the updated blog and Microsoft proposed fixes for the first flaw discovered:

http://blogs.msdn.com/e7/archive/2009/02/05/uac-feedback-and-follow-up.aspx