Windows 7 Super Bar Enabling By Hubbak

Windows 7 auto-elevation mistake lets malware elevate freely, easily

As you probably know by now, Windows 7 introduces some new in-between modes for User Account Control (UAC). By default, Windows 7 (beta thus far) ships with UAC configured at the “Notify me only when programs try to make changes to my computer.” level. As the UAC helper text indicates, “this setting does not prompt when you change Windows settings, such as control panel and administration tasks.”

But how does Windows determine if an application should not prompt the user and simply auto-elevate? As Long Zheng alluded to, Windows checks the process’ image on disk for an embedded digital certificate. But this alone isn’t enough, otherwise instances of any Microsoft application (e.g. calc.exe) would automatically elevate. Leo Davidson did some initial investigative work and uncovered a clue direct from Microsoft:

[…] The change we made in Windows 7 default UAC settings is that any operation that is necessary to manage windows will not require an elevation - which in technical terms translates into a white list of trusted action / binaries which the user can make perform without UAC prompting from an elevation. This list does include windows file operations.

Don’t get wrapped around the term “list”. Rather than implement a real list, that would potentially become a management nightmare, Microsoft chose to implement a new, currently undocumented, application manifest flag.

<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings"> true

In every binary that Microsoft feels should have auto-elevation capabilities, a flag is added to its manifest and the executable (of which the manifest resides in) is digitally signed. I haven’t dug into the internals yet, but I’m hoping assuming that a) the manifest must be embedded (i.e. external manifests should not meet auto-elevation

requirements) and b) the image must be signed by Microsoft and Microsoft alone. Evidence to support the latter can be found in the same newsgroup thread pointed out by Leo:

You see a prompt […] because your binary is not an inbox binary - i.e. not an executable which ships with Windows. Hope that explains and clarifies. For security considerations, Windows 7 does not allow any 3rd party binary to be in the Windows trusted list. […]

Now understanding how applications are “white-listed”, there’s a problem.

This auto-elevation flag was applied to rundll32.exe, an executable that has and still ships with Windows today. Rundll32 (the 32-bit version of original Rundll) was a small internal-only tool later introduced in Windows 95/NT for general use by the public. Its debug-oriented purpose is simple – allow a user to load a library of choosing and call a specific function with parameters.

hmlBy now, you should see where I’m going with this.

As Long also pointed out, malware authors can exploit the fact that rundll32.exe is allowed to automatically elevate by separating their malware into two pieces – a proxy application and a payload (in the form of a library). The proxy application’s job is to invoke rundll32.exe, with the payload library as a parameter in a way that “requests” elevation. Windows will intercept the request and automatically elevate the process to High Mandatory Level, executing your payload wearing an administrative hat.

As a proof of concept, I created two programs. The proxy application, Catapult.exe is a one-line C# application (code) that uses the Process.Start method to launch an instance of rundll32.exe, requesting elevation with the little-known “runas” verb. Cake.dll is a multi-line C++ library (code) and our payload with a single WhereAmI exported function. This function simply reads the current process token, requests Mandatory Level information and shows a message box on-screen. In the real world, this would be the entry point of our malware.

As of today, there has been no official word from Microsoft regarding this issue. Birdies,

however, have told me this problem was fixed in later builds. We’ll just have to wait and see what Microsoft implemented. Removing of the auto-elevate flag from rundll32.exe would fix that process but what about mmc.exe that suffers from a similar problem?

Tomorrow I’ll post the list of auto-elevate-flagged applications.

Nitpicker’s corner: I understand rundll32 requires a specific function prototype/calling convention to not corrupt the stack upon completion of the invocation. This is merely a proof-of-concept. I frankly don’t care about rundll32.exe’s stack after I’m done. Malware can turn off UAC in Windows 7; “By design” says Microsoft committed to database on January 30, 2009 at 12:52 am Eastern Standard Time 34 comments digg this

MSFT buzz-phrases: By design and Won't Fix. New to Windows 7 is the ability to fine tune User Account Control (UAC), the infamously chatty feature introduced in Windows Vista to improve security.

As the Windows operating system cannot differentiate between a user clicking a button and a program clicking a button, UAC was initially implemented to always prompt the user via a dialog shown in the Secure Desktop, similar to the login screen.

Windows 7, however, now ships with UAC configured to hide prompts when users change Windows settings. While this mode still ensures normal applications can’t overwrite your entire registry hive, Microsoft made a boo-boo in allowing users to change any Windows setting without any prompts. Yes, you can even change UAC settings, allow applications free reign in elevated mode (after the required restart).

I’m not alone in scratching my head here – According to an envelope of Post-It notes received by Long Zheng, there have been multiple submissions of this very issue on Microsoft’s beta portal, Connect. Guess what happened. They were all closed — “by design”.

Oh hai, I'm a malicious script waiting to infect your PC. Love me.To quickly demonstrate

how easy it is to automate the disabling of UAC, I wrote some sloppy VBScript code (rename to .vbs), the kind you see in malware on P2P networks, using a combination of the SendKeys, Sleep and Run methods to automate the remote control of the UAC control panel applet and reboot of the system. A more enterprising piece of malware could, of course, move the UAC dialog off-screen, and/or install malware into the startup folder.

An obvious fix for this “issue” would be to force the adjustment of UAC parameters to be confirmed by a human. Until Microsoft addresses this “issue”, you can set UAC to its highest mode to kill any concerns you may have… but you’re not using this in a production environment anyway – right? Crash course on authoring Windows 7 Troubleshooting Packs committed to database on January 12, 2009 at 12:14 am Eastern Standard Time 4 comments digg this

Troubleshooting Pack IconNew to Windows 7 is the Windows Troubleshooting platform. This platform allows software developers to develop Troubleshooting Packs that automate the troubleshooting and resolution of problems without having to resort to painful technical support queues or documentation runs. In a nut shell, a software developer writes a bunch of PowerShell scripts to identify and resolve problems then packages them up and distributes the pack to end-users.

At the end of this step-driven course, you will have used the Microsoft Troubleshooting Pack Builder (TSPBuilder), written some PowerShell scripts, and learned of a way to distribute your compiled pack (hopefully).