“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.