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

<autoElevate>true</autoElevate>

</asmv3:windowsSettings>

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