Defeating UAC with a two-stage malware attack

Defeating UAC with a two-stage malware attack

Summary: An independent security researcher has released details on a two-stage malware attack against Windows Vista to show how easy it is for non-privileged code to replace shortcuts on the Start Menu and intercept UAC (User Account Control) privilege elevation prompts.


An independent security researcher has released details on a two-stage malware attack against Windows Vista to show how easy it is for non-privileged code to replace shortcuts on the Start Menu and intercept UAC (User Account Control) privilege elevation prompts.windows_vista_sm.gif

Rob Paveza's proof-of-concept (.pdf) uses a regular Trojan horse program as a "proxy infection tool" that does not prompt for a UAC roadblock warning because it doesn't make any suspicious system changes.

This tool then becomes a crucial part of the second stage of the attack. Symantec's Ron Bowes explains the basic outline of Pavesa's theoretical attack:

The attack the researcher outlines involves the construction of the Start menu. A user's Start menu is built from at least two locations. One is the user's Start menu folder and the other is global. These two locations are merged to create the Start menu that the user sees. If the same shortcut exists in both the user's folder and the global folder, the user's is used.

The proxy infection tool, which is run by the user, writes to the user's Start menu folder and reads from the global Start menu folder without requesting elevated permissions. The program searches the global Start menu folder for all programs that require elevation, and creates duplicates in the user's folder that point to the malicious code. This is the second stage of the attack.

When the user attempts to run a program that has been duplicated, they see a UAC prompt. Because the program already required elevated permission, the user wouldn't be alarmed. The malicious program, with elevated privileges, executes the intended program, fooling the user into thinking everything is normal. Meanwhile, the malicious program can clean up any trace that it had piggy-backed, and install itself somewhere with permanently-elevated privileges.

Dennis Fisher believes this "has the potential to cause serious damage if it’s executed successfully."

In his research paper, Paveza argues that the design of the Windows user interface does not provide a viable solution to this exploit but he is recommending a few changes to the UAC mechanism to give the end user a clue about these types of attacks.

Some of Paveza's suggestions:

  • A fifth UAC dialog box could be introduced, alerting the user if the shortcut was started from the user’s Start Menu list rather than the All Users list, and if the executable in question is in a non-UAC-protected location.
  • A fifth UAC dialog box could be introduced, alerting the user to unique circumstances each time an unsigned executable is started with administrative privileges for the first time. This would alert the user to the unusual situation, particularly if an application which has been run as an administrator consistently in the past (such as games that require updates) suddenly display the new dialog.
  • The Start Menu could display both Start Menu entries, which would likely be seen as unusual by the user.
  • Disable reads from UAC-protected areas by applications that do not exist in the same protected path (so that applications that do not run from c:\Program Files could not read within c:\Program Files by default).
  • Disable .NET Framework compilation in non-elevated processes by default, although this would not protect from similar attacks made from other languages, such as C, and could present difficulty for some applications which utilize dynamic compilation for extensibility.

While I was reading this paper, which is purely theoretical, I was reminded of a talk by Microsoft technical fellow Mark Russinovich at the CanSecWest security conference last month where he stressed that malware authors will evolve to do damage on Vista (even with UAC enabled).

This new research is just one example of the kinds of things we'll be seeing in a Vista world.

Also see this excellent Channel 9 interview with Russinovich (.wmv) where he talks about UAC and the other security technologies that make Vista Microsoft's most secure OS ever.

Topics: Malware, Operating Systems, Security, Software, Symantec, Windows

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Holy shyte!

    Now that is slick. ]:)
    Linux User 147560
    • no kidding!

      pretty darn clever.
    • Agreed

      I agree that is very clever.

      The problem with the UAC messages is that they are always popping up and the fact is that most people will not read them. So, the message could say something like "This application is requesting higher privileges so it can modify system settings." and very few people would care. I am sorry to say but the way that OSX handles this situation is much better in my opinion. (I do not wish to get into an OSX v. Windows debate, just pointing out my opinion on this one issue).
      • nor do I.....

        but I get no UAC prompts when just using my machine, I only get them when operating some control panel applets or adding a route via cmd promt or something.

        Anyhow, how does OSX handle it better? I ask because I don't see how its better, mainly because of my OSX ignorence.

        - Sam
        • Answer

          I get them all the time, but it may be because I use development tools and no just Office or the like.

          OSX requires elevated permissions on install only, then no application (at least none that I have ever used) run (or require) elevated permissions, period. It may be because OSX has been designed differently from the ground up, not sure about the base architecture.
          • I use development tools too

            (VS2005) and I never get the UAC prompt. I see below someone has pointed you to the SP1 that gets rid of the UAC prompt for VS2005 so you should certainly get that one. If any other tool requires UAC, that is hardly the fault of Windows and more a fault of the tool. And yes, that holds even if the tool was built by MS.
          • Administrator?

            Are you running VS2005 as Administrator as suggested by MS?
          • you misunderstand or are mistating the MS suggestion...

            the MS suggestion is to run VS2005 as an elevated Admin to gain access to all features in MS2005.

            This mean you can run VS2005 as a user or admin and it WILL run WITHOUT UAC prompts, but some features will be unavailable. To gain access to the full suite, they recommend you right click on the VS2005 icon and choose to "Run as Administrator" which WILL make a UAC prompt pop up, but does not make VS2005 an attack vector for the exploit contained in the article.
          • No

            [i]Are you running VS2005 as Administrator as suggested by MS?[/i] No, I'm running with restricted rights. As joemama correctly pointed out, you only need elevated permissions for a very specific, small list of functions that I suppose I've never needed to use. If you need to use one of those functions, then it is because that function is going to administer something on the machine and administrative rights [b]should[/b] be required.
          • One such application would be ONYX .

            Onyx can be used from the Administrator mode , not from Limited mode . Anyways even when you are using ONYX from Administrator mode, you have to type in the password , if not the application quits .
          • Anything that requires system-level access in OS X

            REQUIRES that you log in as administrator, either when starting the program or when you log into the computer itself (and most of the disk tools and other utilities I use require both).
          • Not really

            You may have to authorize as an administrator, but that's different than having to log
            in as an administrator.
    • Would something similar work with Linux?

      I'm not at a Linux box now so I can't test it but would the following work:

      1. First stage of attack, add ~/.malware/ to the front of the user's path. Create that folder and add an executable file called "mount" (and any other commonly used admin tools) to that folder. None of this would require any permissions above what the user already has.
      2. On my Ubuntu boxes, I always call "sudo mount ..." (or sudo <admin command>, whatever) to run the command with root privileges. Wouldn't that then have the same effect: running the planted executable with root permissions?

      I'm not as familiar with how KDE/Gnome store their shortcuts but wouldn't something similar be possible?
      • The short answer is, Yes.

      • The real answer would be NO . What would No-Axe know , he's a Win zealot

        • You demonstrate your ignorance of Linux

          And my use of it.
          • So enlighten us then Don

            Which Linux distro are you using and what's the syntax of your sudoers file?
            Robert Crocker
          • Well let Microsoft know you are using Linux also ,

            so they can sue the clothes off your back , you two faced bold liar .
          • Microsoft won't go after everyone...

            ...they'll just go after everyone that doesn't use Microsoft.
        • Geezus son...

          You could pull an attack like this on ANY OS. ANY OS. Let me say this again. ANY OS.

          It's just that Windows is an easier target to crack with all of those users that just click on "Yes", "Continue", or "I Agree" to make the computer happy. Everyone knows this happens.