Shameless Plug

[MyndFyre]

In a blog by iago about me, he talks about a security vulnerability I disclosed to Bugtraq regarding a Trojan-style exploit that takes advantage of the composition of the Start Menu to effectively trick a user to elevate a proxy program to administrative privileges.  See the blog entry and related whitepaper for the details. ;)

[Chavo]

Very interesting read

[Skywing]

I'm on the fence as to whether you'd really call this a security vulnerability than more of a social engineering attack.

Furthermore, once you have already run malicious code with (even limited) write access, you can by definition not trust anything that the code could have written to.

Code signing can mitigate this, but it still isn't foolproof (e.g. could replace a new version of an app with an old version that has a security hole).  More to the point, you shouldn't be elevating programs sourced from a location that is writable to plain users in the first place.

You can look at UAC in two lights:

1) As a way to make it more convenient to run as a plain user, by providing a seamless elevation path for known-good administrative tools run from a secure location, as opposed to having them just fall over and die when you run them.
2) As a diaper for those "Oh, shit, I just ran malicious code" moments.  This isn't something you should be relying on anyway (consider that your secret documents on that user account are -already- toast and copies are already on their way to China or who knows where, after your local copies have been deleted).

Some people market UAC as a security feature.  In as much as it helps users run with lesser privileges, this is good, but if you value your data more than your system files, you still need to be careful (or run untrusted things in an isolated user account that doesn't have read access to your personal data).

[iago]

I'm on the fence as to whether you'd really call this a security vulnerability than more of a social engineering attack.

I think it's more of a social engineering attack, but it allows a malicious user to bypass UAC's protection.

You're right that people shouldn't run untrusted code in their profiles, but in the real world people do, every day. And because of attacks like this, UAC isn't going to save them.

[Skywing]

Yes, and UAC is not supposed to save you if you run malicious code as your user.  That's a misunderstanding of what the technology allows.  Think of it more as what sudo does for unix; just because it's there doesn't mean that you are supposed to run any old untrusted program you can find.

UAC (and the filesystem/registry virtualization technology) is an attempt towards making it possible for every day users to work as a limited user.  It is not designed to make you immune to negative effects if you run malware as your account.  There are other measures that attempt to do that, though they won't prevent someone from stealing data, only deleting it.

There is a reason why UAC isn't considered an anti-malware/anti-exploit feature by SWI.

(Disclaimer: Yes, there are marketing droids out there that will try to sell UAC as something that blocks malware.  I'll remind everyone that marketing droids neither design nor implement product features in the typical scenario.)

[iago]

I understood that UAC was supposed to help prevent viruses and such. If it doesn't, then I had misunderstood the problem.

It can, however, still do more to help prevent malware from potentially exploiting this (would never be 100%, though).

[MyndFyre]

What's the point of running at a lower-than-administrator privilege level?  In every security book and article I've ever read, it's (and this is paraphrased) so that the entire system doesn't get fucked up when you do something stupid.  Why run services in session 0 and users in session 1 and above?  So that it's harder to implement an escalation-of-privilege attack.

UAC is designed to:
1.) separate the user from running all the time with administrative credentials.
2.) allow the user a convenient experience to provide a program with administrative credentials.
3.) ensure the user knows when administrative credentials are being requested by a program.
4.) help the user decide whether to grant administrative access to a program.

I think of this more as an exploit/attack.  It most certainly requires user intervention to get it to work.  But I guarantee you that one day or another, something on your start menu will need to be run with administrative privileges.  Getting the stuff there is going to be just as common as the old days, too; as I said in my blog, "What happens when Aunt Gladys gets a new photo gallery from her favorite son in law and it turns out to be a Trojanned executable, but the message is believable enough to be run (all of you have Aunt Gladys in your family; don't deny it)."

UAC helps to sandbox the effects of malicious code.  This exploit bypasses that sandboxing by injecting the malicious code into a position for it to be elevated without the user's knowledge, thus circumventing the 3rd and 4th design points of UAC above.

I don't see a logical separation between running as a limited user and a security feature.  Microsoft lists running-with-least-privilege as a security design point in "Writing Secure Code" (Microsoft Press).  For Windows, UAC makes that happen.  To not call it a security feature is like denying an orange is a fruit.

[Skywing]

The point of running with less than administrative permissions is so that you can provide a baseline level of security against attacks by isolating things a compromised account can effect.  By running as a "plain user", damage is limited to just the account that is compromised and not the system as a whole.

Everything that can be written to by that account should be regarded as suspect and potentially compromised as well, however.

UAC is a convenience to make it easier to live with running with less than administrative permissions.  It doesn't provide any additional security beyond that conferred by running as a limited account.

Note that if you are using a single-user computer and do not take steps to isolate tasks you do into different user accounts, then for all intents and purposes, a compromise of that account is as dangerous as a compromise of an administrative account (save that you are potentially spared the relatively minor part of reinstalling the operating system, compared to something attacking your data).

UAC does provide some basic guidance in the elevation user interface as to whether a program requesting administrative access has been signed or not.  What this means to the user is that it provides a quick mechanism to gauge whether they are launching the program they think that they are launching and not something else.  Of course, if the program isn't signed, and the path isn't one that you know is not writable except by administrators, then you really don't have any guarantee that someone without administrative permissions isn't trying to trick you into running their program elevated.

If the program is signed, then you (as the user) need to make a decision as to whether you trust that whoever signed the program hasn't lost their private key, and that they won't sign malicious code, and that they have never in the past signed malicious code or code with security vulnerabilities that would allow a medium integrity process to succefully attack a program that is launched with administrative permissions, and that no CA your computer trusts has been compromised.

It would also be a good idea to check the command line of the program in question (from the "Details" drop down) to ensure that someone isn't trying to do something evil via a known trusted program.

If you don't follow these steps, then you're leaving yourself open to being tricked into turning a plain user account compromise into an administrative account compromise.

As far as the "Aunt Gladys" case goes - sure, she's likely to get herself into trouble there, just as if UAC wasn't there.  Keeping your computer from being fully compromised requires a detailed knowledge of how lots of parts of your operating system work, something that most end users aren't going to grok fully enough to protect themselves against every clever style of attack out there.  Security is still hard; UAC may save some time and frustration here and there with respect to running things as a limited user, but it doesn't absolve the end user from having to be vigilant and suspicious of each and every elevation prompt and exercise their gray matter in order to make a determination as to whether to grant or deny the request.

Your attack is certainly one that will likely prove effective if users aren't careful, and I'm not trying to downplay that by any means.  However, it is difficult to claim that it is a security vulnerability when it relies upon users not making use of the tools made available to them (which is required to ensure that elevation requests for a malicious program aren't accidentally granted).

[iago]

This story was picked up by a ZDnet blogger: http://blogs.zdnet.com/security/?p=203

From a quick glance, the post seems really well done. Much better than mine! :)

[Newby]

Damn. BOTH of you got mentioned! Incredible. :)

[MyndFyre]

This story was picked up by a ZDnet blogger: http://blogs.zdnet.com/security/?p=203

From a quick glance, the post seems really well done. Much better than mine! :)

Spiffy, thanks!

[MyndFyre]

Here are some new stats on it.

Referrers:
http://blogs.zdnet.com/security/?p=203
http://www.eweek.com/article2/0,1759,2131595,00.asp
http://news.softodrom.ru/ap/b1794.shtml
http://www.techamok.com/?pid=2670
http://www.astalavista.com/index.php?section=directory&cmd=detail&id=8221
http://www.idg.se/2.1085/1.108439
http://www.pcmag.com/article2/0,1895,2132120,00.asp
http://www.neowin.net/index.php?act=view&id=40355
http://www.itmedia.co.jp/news/articles/0705/17/news070.html
http://www.extremetech.com/article2/0,1697,2132173,00.asp
http://www.thevista.ru/page.php?id=8569
http://www.techworld.com/security/news/index.cfm?newsid=8873
http://www.security.nl/article/16069/1/Nieuwe_aanval_op_Vista's_User_Account_Control_gepubliceerd.html
http://www.pcworld.com/article/id,132016-pg,1/article.html
http://elladodelmal.blogspot.com/2007/05/cuidado-con-lo-que-ejecutas.html
http://kopalniawiedzy.pl/wiadomosc_2719.html

Sadly the Symantec Security Response weblog was kind of low on the list by total hits -- 29. :-/

Cool thing is the whitepaper has had almost 6500 downloads.  The PoC has had 245.

[iago]

That's actually pretty impressive!

I'll submit it to Slashdot tomorrow morning and link to the best article I see (possibly zdnet, it looked really good). They didn't take it last time, but you never know!

[MyndFyre]

Incidentally, I found another one that seems to be copy-pasted: http://vista.blorge.com/2007/05/21/researcher-reveals-2-step-microsoft-vista-uac-hack/

I'm rather disappointed in the number of copies I've seen.  I guess news doesn't have to be original, but a LOT seems to be word-for-word duplicates.

Kind of bizarre I thought....

[iago]

Yeah, I hate to break it to you, but that's pretty much par for the course. A lot of news people are lazy.

Just think of it as a mini version of the associated press. If the AP runs an article, you'll see literally 100's of identical copies of it everywhere.

By the way, you should read the comments on ZDNet. Some of them are really insightful. Others, of course, are stupid. But specifically, what do you think of this one? Could you wait for programs to be downloaded and modify them, without UAC prompting?

I realize that, like Skywing said, this isn't what UAC is intended for, but in reality it's being used in this way. Is this another potential attack?