List of Windows 7 (beta build 7000) auto-elevated binaries

[...] from Within Windows has published a list of executables which can automatically elevate themselves through User Account Control in Windows 7 (Build [...]

Good on you and Long for continuing to research this issue. Keep up the good work!

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. :) )

Hm, taskmgr.exe, so you could send alt+f,n,”someconnand”,enter

@Leo: I still don’t understand why you keep talking about injection, CreateRemoteThread/WriteProcessMemory etc will not work in a elevated process when your process is Medium IL

@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, do you really think the non elevated process is the one doing the manifest checking? Its probably deep down in kernel land

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 640×480x8bit, 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.

*Running explorer elevated is possible accidentally if you restart it using an elevated Task Manager by accident.

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.)

@Leo: I still don’t get it, yes you can copy a file like explorer, but can you EXECUTE cmd.exe elevated for example?

@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.

@Dan: “Also Leo ANY process can launch an auto-elevated subprocess.”

Um, what???

If that’s true — which I assure you it isn’t supposed to be — then remind me what the point of UAC is again, please?

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

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

@Leo:

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

@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.

@Rafael: I’m a friend of Leo’s and have seen the code. I think maybe you’re misunderstanding what is happening in his P-O-C.

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…

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.

this gets to be like communism, a good idea but impossible to implement because it assumes humans to be consistent in their actions.

@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!

With very little time/effort I was able to extend my previous proof-of-concept code into something that can run any command with elevation and do things like wipe out the OS. This is without using the SendKeys or RunDll32 tricks.

(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?

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.

@Leo:
Can a program (say an “innocent” setup file), install a driver or rootkit WITHOUT getting a UAC prompt with this flaw?

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.

@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.

[...] week, I published a list of auto-elevate flagged binaries shipped with the Windows 7 beta. Analysis of the recently leaked [...]

[...] ‘admin’ mode without asking for permission. Except for “some” please read approximately 70, and for “core utilities” think calculator. -Anyway, have a look at this video by Leo [...]

Please excuse my ignorance as I’m not a devloper but for the MS apps such as calculator am I correct to assume that the maifest embeded in the file requests Admin rights?

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??

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

Have there been any changes in the RC (build 7100)?

[...] able to auto-elevate without actually prompting the user. Click after the jump for the actual list. Back in February, I posted a list of applications that have the authority to automatically elevate without prompt in [...]

[...] the new Windows 7 UAC behavior). An example is sysprep.exe. The name of the dll must correspond to one that’s not on the “known dlls” [...]

[...] http://www.withinwindows.com/2009/02/05/list-of-windows-7-beta-build-7000-auto-elevated-binaries/ Categories: Microsoft, Security, Windows 7 Tags: Comments (0) Trackbacks (0) Leave a comment Trackback [...]

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

Interesting, thanks for sharing.

[...] is the list of about 70 processes published on Rafael’s Within Windows blog. (Update: New list for RC1 build 7100.) If you run [...]