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.
Follow Bryant on Twitter! 
This won’t go over too well.
they actually defined the proof of concept as malware… with its own name!
OR someone could have submitted the file to SpyNet as malware and MS Security approved it…
This strikes me as a good idea. IIRC the proof of concept code was distributed freely on the web. This prevents script-kiddies from copying/pasting it and using it. Sure, it doesn’t solve the underlying problem, but it prevents a well-known and widely-publicized exploit from being easily used against a system.
@Robert, the thing is, that doesn’t actually have any effect on the point of the post. The point is that Microsoft still classifies the proof-of-concept as malware and, by extension, the flaw as a vulnerability. They went through the effort of categorizing it and naming it accordingly, which they wouldn’t have done if they didn’t consider it an exploit of some sort.
@Ali, the code can be compiled into any application and fly undetected at the moment. The current signature only looks for the proof-of-concept process.
@Bryant – even so, if I were a system administrator, I would obviously not want people to be able to just download and run this application.
@Ali, you don’t get the point. Issuing a security patch that fixes the flaw entirely is preferable, but security software should pick up any binary that executes the specific type of malicious code, not just “the one that started it all”. Especially since a recompilation of the same source can mask it.
@Ali, the proof-of-concept application they are blocking doesn’t let you do much that you couldn’t already do using Explorer. The application was made to prove that an idea works rather than to be something which helps people use that idea.
If someone wanted to use the application in an automated way then they’d have to open its UI and send mouse/keyboard events to it. They could send mouse/keyboard events to Explorer to make it perform the same actions instead. (The fact that Explorer can be used to do this might be considered an issue but MSE isn’t detecting Explorer as malware… Maybe it should!
)
The *concept* behind the application can be used to silently elevate things (under Win7’s default settings) without any user interface or UAC prompt being displayed but the application itself cannot (or at least cannot be used to do anything you couldn’t also do using Explorer instead). The app displays a UI and requires user input to tell it what to run. It’s left up to the user’s imagination to understand that something could do the same thing without displaying a user interface.
The source code and ideas behing the application could be used to easily create such a tool but, as mentioned, if you compile your own variant of the program then the resultant exe is not detected.
For me the question is this:
If bypassing UAC does make something malware then shouldn’t Explorer.exe on Win7 be detected and blocked as well?
Haha, love that…
“It’s not an exploit… but it’s malware!”
[...] even released yet and a significant flaw is already out there with regard to how Windows 7 handles white listing in the UAC…or something like that. On the plus side, it seems that this kind of issue is something that [...]
message to microsoft: just fix that security flaw!!
message to leo davidson: great job!