Within Windows

I’m surprised Explorer.exe isn’t on the list. Was that missed somehow or is it possible it gains elevation via a different method?

I’ve started work on an attempt to prove my theory about code injection. Hope to have something later in the day, if I can make it work. My aim is to show that removing any individual process from the whitelist won’t help because malware could look for any running whitelisted process and target that.

I think — if I am right, which is yet to be proven — this is important because it will show that way there is no checking of which code — only which process — is requesting elevation and no checking of what is being silently elevated means that the whole whitelist design is flawed and cannot be fixed by simply removing individual programs from the list (unless they are *all* removed :)).

(Sorry to keep using the term “whitelist” when there technically isn’t a list… It just seems convenient and true on a conceptual level. :) )

@asf: None of the processes you need to inject into are elevated. That’s the whole point. They can *create* elevated processes but they are not elevated themselves.

Leo: As I explained in the last blog post, explorer does not run elevated. It is not meant to run elevated. It only temporarily elevates sub processes when it needs to (IE to access files for moving/copying).

You can tell when Explorer is (accidentally) running elevated because the Run dialog will state that all subprocesses launched will be run elevated. Running Explorer elevated is possible

Also Leo ANY process can launch an auto-elevated subprocess. asf is correct, the magic probably happens in kernel land (otherwise my malware process could say “oh windows? auto elevate this process here, I checked the manifest, I swear it’s OK!!!” which is even stupider than what is currently happening.

Now about those other “interesting” processes. AFAIK mmc will only run “registered” snap ins and will not run any .msc file you throw at it. If registering an .msc file requires elevation (I bet it uses HKLM so it would) and replacing or modifying an existing .msc would cause MMC to reject it than MMC’s auto elevation isn’t such a big problem IMO (unless, Rafael, you were thinking of something else).

sdbinst seems to allow for the installation of a database file containing information about application compatibility stuff (the Compatibility tab on shortcuts) and it could modify it globally, keeping normal users from turning these settings off. Compatibility settings are ignored on any files in %WINDIR% and subdirectories (at least on MS files in those dirs) which really sucks when trying to make a command prompt shortcut auto elevate (fortunately Shift + Ctrl + click taskbar button ftw). Anyways I don’t see how this could be used to further the cause of malware, worst that happens is it screws around with a user’s third party apps making them all run in 640x480x8bit, elevate on run, turn off DPI scaling, turn off glass globally, force the app to run in Windows Classic theme, and think it’s running back on Windows 95 (installers that check for a newer version of windows would fail, otherwise apps which don’t check but blindly call XP-specific functions etc would be unaffected). That’s all more annoying than harmful, really.

I’ve finished my proof-of-concept code now.

This allows:

- Any *unelevated* process
- On an x64 or x86 Windows 7 with default settings
- To create elevated COM objects without any UAC prompts
- Using code injection into *any* process that is flagged for silent elevation.

If it needed to it could scan the running processes and pick a random one that had the appropriate manifest but at the moment it just uses Explorer.exe.

I think this demonstrates what I was trying to prove which is that removing the silent elevation flag from individual programs, e.g. RunDll32.exe, may make life a bit more difficult but not a lot more.

Here is a video:
http://nudel.kelbv.com/W7Elevate/W7Elevate.htm

That site seems pretty slow so here’s a mirror site that a friend quickly donated:

http://leo.lss.com.au/W7Elevate/W7Elevate.htm

Now do believe me? :-)

I will send the binaries to Rafael so he can independently confirm that the video isn’t fake.

At this point I’m not going to release the binaries or source publicly. While the source is quite short (if you ignore all the UI, error checking and clean-up code that malware wouldn’t bother with!) and it only uses techniques you can easily find on the web, I figure there’s little to be gained in making things easier for malicious people.

Obviously if MS or some other trusted party want to look at the source then I’ll help them as much as possible.

BTW, there is some goodish news:

It’s probably difficult for this attack to be performed via a buffer-overflow exploit, or similar, *unless* there exists a process that can do silent elevation and doesn’t have ASLR turned on. Hopefully no such process exists but I have not checked.

However, ASLR does *not* provide any protection against code loaded via an exe or dll. ASLR is switched on for Explorer.exe and that’s the process I am (arbitrarily) injecting into.

So in this case, unlike the other two exploits (remote controlling the control panel and the RunDll32.exe problem that Rafael found), Microsoft are probably right when they say the code already needs to be on the box. However, the code doesn’t require admin rights or installation. It’s just a standalone exe file that I copied to my Windows 7 VM and double-clicked on.

(Later in the video I run it as administrator just to demonstrate the different behaviour. That isn’t required.)

@asf: If you find a suitable COM object, yes you could execute something elevated. Or you could turn off UAC. The UAC control panel almost certainly uses a COM object to change UAC settings so someone with a debugger could work out which object and how to call it and then we have another way to disable UAC even if the other methods are fixed.

Besides which, a process that is able to copy files to restricted areas such as System32 and Program Files can take over the OS with just that ability by replacing files which will be run at the next reboot as admin with its own files. (Or by replacing a file that the user willingly runs as admin. For example, someone could replace the Process Monitor exe on my computer and the next time I thought I was running Process Monitor and confirmed the UAC prompt I’d actually be launching some other process with admin access.

So any non-elevated process can take over the system and, one way or another, gain full elevation.

Any COM object that is registered for elevation can be used, elevated, by any non-elevated process. (Ignoring low-integrity ones, i.e. IE7/8.)

I don’t plan to go hunting for more COM objects/interfaces as I think I’ve proven the problem exists.

And I don’t understand why you dismiss this as just “copying a file like Explorer.” With the default Windows 7 settings Explorer can modify folders that other processes shouldn’t be able to, yet here is a way which took one day to work out that allows any process to do the same thing, i.e. modify folders it isn’t supposed to be able to. Would you also not be worried about a non-elevated program that was “just formatting the disk like Disk Manager?” :-) It’d be trivial to modify the code so that it erased almost everything in System32, for example… I just made it copy a file as that is a nice, non-destructive example which proves the point without actually breaking the OS it runs on. From there you can extrapolate at the damage that someone malicious could do.

This unelevated process is copying a file like an administrator process. The System32 and Program Files (etc.) folders are protected for a very good reason. Anything with control over them has control over the whole machine, in the end.

I’ve written a page about the code-injection issue & proof-of-concept:

http://www.pretentiousname.com/misc/win7_uac_whitelist2.html

@Kevin:

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.

To add to what Jon write (which is all correct), there can’t be a COM object whitelist, at least not one which allows non-Microsoft applications to create the objects without prompts.

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.

@peter vd berg
I agree with your view!
@Rafael
Your correct on the common misconception’s about elevation….
Thankx for this Blog, it give’s one something to think about!

Leo is right. There is a problem with auto-elevation of COM objects. The problem though is not with the EXEs (all the MS signed ones) that have access to auto-elevation of the COM objects. The problem is with the mechanics of COM auto-elevation itself. Even if you restrict the the number of EXEs someway, you can still inject a thread in one of the remaining ones.
Now given the fact that explorer runs with medium integrity level (correct) and the IFileCopy auto-elevation is used to avoid prompts when managing files in restricted locations (C:\Windows, C:\Program Files, etc.), this means that the hole that Leo found will be always be exploited unless the mechanics of COM auto-elevation are drastically changed.
IMHO COM auto-elevation is intrinsically an hole. There is no way to walk the thread stack like it is possible with .Net Code Access Security.
Moreover: I think that in the rush of suppressing many prompts in Win7 confusion has been done. There are settings like the time-zone which rise a prompt (correct) but do not expose a security risk. Changing, replacing, deleting system files should be considered a different type of operation from changing the time-zone: I would these file operations would always trigger a prompt. Combined with relaxed ACLs in Program Files it would make things way better both from usability and security.

@Kevin Nguyen: It can get full admin access so it should be able to install anything it wants. The question of signed vs unsigned drivers is a side issue really… If the malicious software requires a driver then, yeah, it’ll have to be signed if the OS requires that, unless someone finds a separate way to bypass that requirement. I know very little about installing drivers though.

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.

Anyone interested in manifests see here :)
http://channel9.msdn.com/posts/jmazner/How-To-Tell-Vistas-UAC-What-Privelege-Level-Your-App-Requires/

sorry to bother you,but I deleted a Windows/System32/msdt.exe by wrong,Icannot connect to the internet now.Could you just be fine to send me one. Thanks a lot.
echoecho4@126.com