As those involved in the Windows 7 community may know, Microsoft has failed to fix a crucial flaw in the User Account Control feature of the operating system which allows a specific whitelist of applications to inject code that can allow any application to silently elevate. The code was released about a month ago as a proof-of-concept by Leo Davidson showcasing the flaw elevating a command prompt window using the whitelisted explorer.exe process.

The company stands by UAC in its final form, but they’re taking it a step further by blocking the program that causes the exploit using their own security software.

Today, I just happened to download the zip file that causes the exploit when Microsoft Security Essentials greeted me with a nice dialog telling me that what I just downloaded is malware, specifically HackTool.Win32/Welevate.A and HackTool.Win64/Welevate.A (depending on architecture). While I’d agree that this can be considered a form of malware, it’s just a very bad way of dealing with the situation. However, Leo noted that Windows Defender in Vista did not detect this exploit, and Bryant confirmed that the same is true for Windows 7 (where the trick would actually work), so this seems to be exclusive to Microsoft Security Essentials.

It’s not clear what method the signatures take to detect it, but I promptly recompiled the source code under the Visual C++ 10.0 toolkit using VS 2010 Beta and the application ran undetected. Not a very good solution if it actually hash checks for the specific applications.

Leo, and I (or Bryant) will update our respective pages accordingly as we discover more. Bryant is seeking official word from Microsoft on what’s going on. Meanwhile, you can see the VirusTotal report here and grab the exploit here.

Update (~Bryant): let’s take a look at what’s going on here from a different approach. Microsoft says that the vulnerability here is not actually a vulnerability and is, in fact, by design. However, they’ve also classified Leo’s proof-of-concept as malware. Logically speaking, if a process whose sole purpose is to exploit a perceived vulnerability is marked as malware, then it’s reasonable to assume that the perceived vulnerability is indeed a significant problem. Basically, Microsoft contradicted themselves by listing the proof-of-concept as malware.

Update 2 (~Bryant): A friend of mine proposed one particular argument as a potential explanation to this issue, whereby this is a bug within Microsoft Security Essentials. The reasons I don’t believe this to be the case are:

• This exploit was specifically named as HackTool:Win32/Welevate.A (A quick googling shows only three links; one is to the aforementioned virustotal link, the second and third to a Microsoft encyclopedia entry.
• This particular label only applies to this specific proof-of-concept
• A reasonable vulnerability assessment (”Medium”) was applied to this particular proof-of-concept, which makes sense given that this security vulnerability in UAC is only really an issue if either a user runs a malicious application or if some other internet-facing application were to be compromised. I covered the latter in an older post of mine where I explain how this flaw essentially raises the vectors of attack many-fold.

Leo and Bryant contributed to this post.