“AlwaysInstallElevated” is Equivalent to Granting Administrative Rights

When removing administrative rights from end users, it’s important to ensure that there are no easy paths by which a user (or malware running as the user) can gain administrative rights. For example, don’t relax default permissions on system resources such as files, folders and registry keys, and don’t grant users any “admin-equivalent” privileges such as the Backup, Restore, Debug, or Load Driver privileges. On Windows XP, don’t put end users in the Power Users group. And always be on the lookout for and patch Elevation-of-Privilege (EoP) bugs in desktop management, anti-malware, firewall and other products. These EoP paths will be exploited by end users and by malware, defeating the purpose of removing admin rights and losing all the benefits of doing so.

I recently became aware of another setting that gives the end user admin-equivalent control over the computer. It’s a Group Policy setting for Windows Installer that, if enabled, runs any Windows Installer Package (.msi file) that the user launches under the all-powerful Local System account. The idea behind this setting is to allow users to install applications that they need, without directly granting the user administrative rights. However, it makes no distinction between a management-approved, digitally-signed installer of a business-critical application from a trusted publisher, and an unsigned MSI wrapper around a malicious script. That’s a real problem. Anybody can create an MSI – it doesn’t take deep knowledge, expensive developer tools or admin rights. In an environment with this setting, any user who wants admin rights can get them, and any malware that runs can silently take over the whole system.

This is a setting that appears to have managed somehow to fly under the radar of all of us security experts since its introduction in Windows 2000. Has it been exploited for evil purposes? That’s hard to know. Hopefully now that attention is drawn to it, we can close this hole before it is exploited by explicitly disabling the policy setting.

How easy is it? Well, if a picture is worth a thousand words, here’s an eight-thousand word essay.

Here’s a Windows 7 computer. I’m logged on as Toby, a Standard User. As you can see in the screenshot, the only members of the Administrators group are Abby and Administrator.

This computer has the AlwaysInstallElevated policy applied. It’s in both Computer Configuration and User Configuration, Windows Components \ Windows Installer, “Always install with elevated privileges”. It needs to be set in both Computer Configuration and User Configuration, and on this computer it is.

 

In a few minutes I built an MSI file called “AlwaysInstallElevatedTakeover.msi” containing the following script which will run as a custom action. (Yes, I like vi as a text editor. Too many brain cells committed to memorizing its commands to give it up.) This script prompts the user to enter a new user name and password, defaulting to “NewAdmin” and “Pass@word1”. It then creates a new local account with that user name and password and adds that new user to the Administrators group. It then opens a new Command Prompt with custom colors, lists the new membership of Administrators, and then awaits further instructions.

Here’s the MSI on my desktop, ready to go.

I run the installer, and after a moment it prompts me for a user account name. I use the default.

I also go with the default for the password.

And here’s the Command Prompt, running as Local System. It shows me that the membership of Administrators now includes the NewAdmin account!

And what the heck – as long as I have a Command Prompt with System privileges, I’ll add my Toby account to the Administrators group too, which will take effect the next time I log on. And I also have that NewAdmin/Pass@word1 account at my disposal.

Bottom line:  in 2011, "AlwaysInstallElevated" is not how you want to do enterprise software deployment.

Comments

• Anonymous
  January 25, 2011
  Do you know if there is mention of this setting in FDCC/USGCB? [Aaron Margosis] Not yet, but I have alerted them to this issue.

• Anonymous
  January 25, 2011
  man I've looked at this setting a thousand times and was always amazed that it was even there as a possible gpo setting, you'd think it would be a sub setting under signed only etc at best.

• Anonymous
  October 18, 2011
  Nobody wants to use 'AlwaysInstallElevated', but it's often the only way. What's your alternative? Novell ZenServer? Hiring armies of desktop techs to run around and manually install applications? [Aaron Margosis]  I had meant to include a "what do I do instead" section.  It's vital to remove admin rights from end users, but you still need something to perform those administrative tasks.  What you select should beenterprise-ready.  We recommend SCCM, but there are lots of other offerings available.

• Anonymous
  January 20, 2012
  I deploy Acrobat Reader to our users through Group Policy software deployment.  In Adobe's documentation, they specify that you need to set 'AlwaysInstallElevated' on the computer configuration side.   So as long as both computer and user are not set, everything is good right? [Aaron Margosis]  I searched for that documentation on Adobe's site and elsewhere and coulnd't find it, although I saw it discussed in various forum posts.  In any case, I would recommend against setting it in Computeror User configuration.

• Anonymous
  June 11, 2012
  Just want to point out this is not fully set by USGCB 1.2 (since this came up under the USGCB tech blog).  USGCB 1.2 set in computers but not users and it is my understanding from Microsoft's own documentation that both need to enabled.  I am thinking though this may have been set in an earlier USGCB version or even as far back as an early FDCC version. [Aaron Margosis]  This setting has never been covered by USGCB so far, although I believe it should be.  As I mentioned in the post, this is a setting that has been overlooked by the security community.  USGCB covers both Computer and User settings; disable this in either one and the feature can't be used.  It would be best to disable it in both just to be sure.

• Anonymous
  March 06, 2014
  It does not works, CMD says
  "Access Denied
  System Error 5 have Occured" [Aaron Margosis]  What?  I don't understand what you're trying to do.

• Anonymous
  December 31, 2014
  he means the program didnt work and cmd didnt let a new account be created