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

[darkassain]

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.

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

via http://www.withinwindows.com/2009/0...n-mistake-lets-malware-elevate-freely-easily/