Sysinternals Freeware - Mark Russinovich & Bryce Cogswell

Mark's Sysinternals Blog

The Power in Power Users

Placing Windows user accounts in the Power Users security group is a common approach IT organizations take to get users into a least-privilege environment while avoiding the many pains of truly running as a limited user. The Power Users group is able to install software, manage power and time-zone settings, and install ActiveX controls, actions that limited Users are denied.

What many administrators fail to realize, however, is that this power comes at the price of true limited-user security. Many articles, including this Microsoft Knowledge Base article and this blog post by Microsoft security specialist Jesper Johansen, point out that a user that belongs to the Power Users group can easily elevate themselves to fully-privileged administrators, but I was unable to find a detailed description of the elevation mechanisms they refer to. I therefore decided to investigate.

Before I could start the investigation, I had to define the problem. In the absence of a security flaw such as a buffer overflow privilege escalation is possible only if an account can configure arbitrary code to execute in the context of a more-privileged account. The default accounts that have more privilege than Power Users include Administrators and the Local System account, in which several Windows service processes run. Thus, if a Power Users member can modify a file executed by one of these accounts, configure one of their executables to load an arbitrary DLL, or add an executable auto-start to these accounts, they can obtain full administrative privileges.

My first step was to see what files and directories to which the Power Users group has write access, but that limited users do not. The systems I considered were stock Windows 2000 Professional SP4, Windows XP SP2, and Windows Vista. I'm not going to bother looking at server systems because the most common Power Users scenario is on a workstation.

The brute force method of seeing what file system objects Power Users can modify requires visiting each file and directory and examining its permissions, something that’s clearly not practical. The command-line Cacls utility that Windows includes dumps security descriptors, but I’ve never bothered learning Security Descriptor Description Language (SDDL) and parsing the output would require writing a script. The AccessEnum utility that Bryce wrote seemed promising and it can also look at Registry security, but it’s aimed at showing potential permissions weaknesses, not the accesses available to particular accounts. Further, I knew that I’d also need to examine the security applied to Windows services.

I concluded that I had to write a new utility for the job, so I created AccessChk. You pass AccessChk an account or group name and a file system path, Registry key, or Windows service name, and it reports the effective accesses the account or group has for the object, taking into consideration the account’s group memberships. For example, if the Mark account had access to a file, but Mark belongs to the Developers group that is explicitly denied access, then AccessChk would show Mark as having no access.

In order to make the output easy to read AccessChk prints ‘W’ next to the object name if an account has any permissions that would allow it to modify an object, and ‘R’ if an account can read the object’s data or status. Various switches cause AccessChk to recurse into subdirectories or Registry subkeys and the –v switch has it report the specific accesses available to the account. A switch I added specifically to seek out objects for which an account has write access is –w.

Armed with this new tool I was ready to start investigating. My first target was a Windows XP SP2 VMWare installation that has no installed applications other than the VMWare Tools. The first command I executed was:

accesschk –ws “power users” c:\windows

This shows all the files and directories under the \Windows directory that the Power Users group can modify. Of course, many of the files under \Windows are part of the operating system or Windows services and therefore execute in the Local System account. AccessChk reported that Power Users can modify most of the directories under \Windows, which allows member users to create files in those directories. Thus, a member of the Power Users group can create files in the \Windows and \Windows\System32 directory, which is a common requirement of poorly written legacy applications. In addition, Power Users needs to be able to create files in the \Windows\Downloaded Program Files directory so that they can install ActiveX controls, since Internet Explorer saves them to that directory. However, simply creating a file in these directories is not a path to privilege elevation.

Despite the fact that Power Users can create files underneath \Windows and most of its subdirectories, Windows configures default security permissions on most files contained in these directories so that only members of the Administrators group and the Local System account have write access. Exceptions include the font files (.fon), many system log files (.log), some help files (.chm), pictures and audio clips (.jpg, .gif, and .wmv) and installation files (.inf), but none of these files can be modified or replaced to gain administrative privilege. The device drivers in \Windows\System32\Drivers would allow easy escalation, but Power Users doesn’t have write access to any of them.

I did see a number of .exe’s and .dll’s in the list, though, so I examined them for possible exploits. Most of the executables for which Power Users has write access are interactive utilities or run with reduced privileges. Unless you can trick an administrator into logging into the system interactively, these can’t be used to elevate. But there’s one glaring exception: ntoskrnl.exe:



That’s right, Power Users can replace or modify Windows’ core operating system file. Five seconds after the file is modified, however, Windows File Protection (WFP) will replace it with a backup copy it retrieves, in most cases, from \Windows\System32\Dllcache. Power Users doesn’t have write access to files in Dllcache so it can’t subvert the backup copy. But members of the Power Users group can circumvent WFP by writing a simple program that replaces the file, flushes the modified data to disk, then reboots the system before WFP takes action.

I verified that this approach works, but the question remained of how this vulnerability can be used to elevate privilege. The answer is as easy as using a disassembler to find the function that Windows uses for privilege checks, SeSinglePrivilegeCheck, and patching its entry point in the on-disk image so that it always returns TRUE, which is the result code that indicates that a user has the privilege being checked for. Once a user is running on a kernel modified in this manner they will appear to have all privileges, including Load Driver, Take Ownership, and Create Token, to name just a few of the privileges that they can easily leverage to take full administrative control of a system. Although 64-bit Windows XP prevents kernel tampering with PatchGuard, few enterprises are running on 64-bit Windows.

Replacing Ntoksrnl.exe isn’t the only way to punch through to administrative privilege via the \Windows directory, however. At least one of the DLLs for which default permissions allow modification by Power User, Schedsvc.dll, runs as a Windows service in the Local System account. Schedsvc.dll is the DLL that implements the Windows Task Scheduler service. Windows can operate successfully without the service so Power Users can replace the DLL with an arbitrary DLL, such as one that simply adds their account to the Local Administrators group. Of course, WFP protects this file as well so replacing it requires the use of the WFP-bypass technique I’ve described.

I’d already identified several elevation vectors, but continued my investigation by looking at Power Users access to the \Program Files directory where I found default permissions similar to those in the \Windows directory. Power Users can create subdirectories under \Program Files, but can’t modify most of the preinstalled Windows components. Again, the exceptions, like Windows Messenger (\Program Files\Messenger\Msmgs.exe) and Windows Media Player (\Program Files\Windows Media Player\Wmplayer.exe) run interactively.

That doesn’t mean that \Program Files doesn’t have potential holes. When I examined the most recent output I saw that Power Users can modify any file or directory created in \Program Files subsequent to those created during the base Windows install. On my test system \Program Files\Vmware\Vmware Tools\Vmwareservice.exe, the image file for the Vmware Windows service that runs in the Local System account, was such a file. Another somewhat ironic example is Microsoft Windows Defender Beta 2, which installs its service executable in \Program Files\Windows Defender with default security settings. Replacing these service image files is a quick path to administrator privilege and is even easier than replacing files in the \Windows directory because WFP doesn’t meddle with replacements.

Next I turned my attention to the Registry by running this command:

accesschk –swk “power users” hklm

The output list was enormous because Power Users has write access to the vast majority of the HKLM\Software key. The first area I studied for possible elevations was the HKLM\System key, because write access to many settings beneath it, such as the Windows service and driver configuration keys in HKLM\System\CurrentControlSet\Services, would permit trivial subversion of the Local System account. The analysis revealed that Power Users doesn’t have write access to anything significant under that key.

Most of the Power Users-writeable areas under the other major branch of HKLM, Software, related to Internet Explorer, Explorer and its file associations, and power management configuration. Power Users also has write access to HKLM\Software\Microsoft\Windows\CurrentVersion\Run, allowing them to configure arbitrary executables to run whenever someone logs on interactively, but exploiting this requires a user with administrative privilege to log onto the system interactively (which, depending on the system, may never happen, or happen infrequently). And just as for the \Program Files directory, Power Users has default write access to non-Windows subkeys of HKLM\Software, meaning that third-party applications that configure executable code paths in their system-wide Registry keys could open security holes. VMWare, the only application installed on the system, did not.

The remaining area of exploration was Windows services. The only service permissions AccessChk considers to be write accesses are SERVICE_CHANGE_CONFIG and WRITE_DAC. A user with SERVICE_CHANGE_CONFIG can configure an arbitrary executable to launch when a service starts and given WRITE_DAC they can modify the permissions on a service to grant themselves SERVICE_CHANGE_CONFIG access. AccessChk revealed the following on my stock Windows XP SP2 system:



I next ran PsService to see the account in which the DcomLaunch service executes:



Thus, members of the Power Users group can simply change the image path of DComLauncher to point at their own image, reboot the system, and enjoy administrative privileges.

There can potentially be other services that introduce exploits in their security. The default permissions Windows sets on services created by third-party applications do not allow Power Users write access, but some third party applications might configure custom permissions to allow them to do so. In fact, on my production 64-bit Windows XP installation AccessChk reveals a hole that not only Power Users can use to elevate themselves, but that limited users can as well:



I’d now finished the major phase of my investigation and just confirmed what everyone has been saying: a determined member of the Power Users group can fairly easily make themselves full administrator using exploits in the operating system and ones created by third-party applications.

My final step was to see how Microsoft’s approach to the Power Users account has evolved over time. This 1999 Microsoft Knowledge Base article documents the famous screen-saver elevation vulnerability that existed on Windows NT 4, but Microsoft closed that hole before the release of Windows 2000. The KB article also shows that Microsoft was apparently unaware of other vulnerabilities that likely existed. Windows 2000 SP4 also includes holes, but is actually slightly more secure than the default Windows XP SP2 configuration: Power Users don’t have write access to Ntoskrnl.exe or the Task Scheduler image file, but instead of write-access to the DComLauncher service they can subvert the WMI service, which also runs in the Local System account.

Windows XP SP1 added more Power Users weaknesses, including write access to critical system files like Svchost.exe, the Windows service hosting process, and additional services, WMI and SSDPSRV, with exploitable permissions. Several services even allowed limited users to elevate as described in this Microsoft KB article from March of this year.

Microsoft’s newest operating system, Windows Vista, closes down all the vulnerabilities I’ve described by neutering Power Users so that it behaves identically to limited Users. Microsoft has thus closed the door on Power Users in order to force IT staffs into securing their systems by moving users into limited Users accounts or into administrative accounts where they must acknowledge end-user control over their systems.

The bottom line is that while Microsoft could fix the vulnerabilities I found in my investigation, they can’t prevent third-party applications from introducing new ones while at the same time preserving the ability of Power Users to install applications and ActiveX controls. The lesson is that as an IT administrator you shouldn’t fool yourself into thinking that the Power Users group is a secure compromise on the way to running as limited user.

posted by Mark Russinovich @ 11:01 AM

Comments:
Mark,
Great article. One question though. You say "note that the Power Users group doesn’t exist on server operating systems like Windows 2000 Server and Windows Server 2003". But the "Power Users" group definitely does exist on server OSs (at least on mine they do). Perhaps you're referring to Domain Controller installs of the server OSs?
 
Another way has to do with the Power Users right's to Backup and Restore files.
During the Restore Operation the Power User has to create the ACL for restored object.
During this process the to Power User is granted something called a Program Right? This right allows them to modify the ACL to whatever it was when the file was backed up in spite of the fact they may not have permissions to the current object or file.

Internal Microsoft Support has a tiny .Exe that mimics this situation and allows you to change the permissions on files and objects at will as if they were being "restored from tape".
 
Perhaps you're referring to Domain Controller installs of the server OSs?

Correct, thanks. I've changed the text to clarify.
 
Another way has to do with the Power Users right's to Backup and Restore files.

Power Users does not have backup or restore privileges.
 
The Macromedia issue is supposed to have been fixed:
http://www3.ca.com/securityadvisor/vulninfo/vuln.aspx?id=33043
 
Although you are certainly right in that Power Users does not stop a focused attack, it certainly helps limit *accidental* damage (often well meaning) by users, which is a large part of what IT departments deal with. In that respect, it remains a useful comprimise.

Of course, the difference between preventing fraud and preventing error is rarely differeniated by vendors, making it difficult to assess the use of many features
 
Although you are certainly right in that Power Users does not stop a focused attack, it certainly helps limit *accidental* damage

All you need is a piece of malware to accidentally take advantage of the elevation path.
 
@Aaron Margosis:

There are several other unfixed third-party services:

- Adobe License Manager (Photoshop and Co. - wooh, I needed a crack to make it run without AdobeLM)
- Novell NetDrive (damn, I liked it)
- under certain conditions: Superior SU
- Apple's Bonjour
- VMware has already been named
- even the SafeDisc CD Copy Protection driver that is shipped with Windows will be messed up after being updated by any modern game (even after uninstallation)
 
I found a very nice GUI tool to edit DACL's on services: http://msdn.microsoft.com/msdnmag/issues/05/03/SecurityBriefs/
 
The downside of limiting access is that it makes removing malware more difficult. On the one hand, you're making it more difficult for malware to take hold, and on the other, more difficult to remove the ones that get in. The problem remains the same: The design of Windows is severely flawed as far as security is concerned. They should've kept it simpler by segregating the registry better, ditching COM and IE from the core OS functionality. Now, it's just a hodge-podge of tweaks to close this hole or that hole The cheese remains swiss:-) Good article.
 
jason star-

Difficult removal of malware that takes hold in a user account is news to me. Isn't it as simple as logging on to a local Administrator account (obviously not by an end-user) and continuing with normal malware removal techniques?
 
All you need is a piece of malware to accidentally take advantage of the elevation path.

Not all security is about malicious attacks. In fact, quite a large amount of security is about preventing errors. In this context, the Power Users account makes some sense; it is not useless at all. In addition, it provides *some* level of defense against attacks, but reducing the number of available attack vectors and blocking/limiting numerous known attacks.

I am not defending the limitations of using it, simply pointing out that it has its uses in the evironment that we are stuck with at this time. For TRA purposes, it closes some problems over Administrator and may be work the risk for some. That said, I do look forward to improved windows security in Vista, but I am not holding my breath.
 
Thus, members of the Power Users group can simply change the image path of DComLauncher to point at their own image, reboot the system, and enjoy administrative privileges.

Pardon me for being ignorant, but I just don't understand the above concept. What is image path? How can I change it?

Can someone, please, enlighten me or just put me in the right direction.

Thank you very much.
 
the Power Users account makes some sense; it is not useless at all.

I agree. It's nice to be able to perform some administrative tasks (installing programs, changing some system settings, etc.) without logging on as an administrator. Like Mark pointed out, some exploits could count on an administrator logging on interactively.
"Run as" takes care of some of this though (esp. in XP) and Vista's "User Account Control" will hopefully take care of the rest. If it does, then Power User will be truely useless, if not, then I will miss it quite a bit.
 
Paul - take a look at this analysis done by eWeek:

http://www.eweek.com/article2/0,1759,1891447,00.asp

In it, they compared the vulnerabilities picked up when running XP and 2000 as User, Power User, and a local Administrator. The reality is that it provided almost no protection. The Power User group is far too close to an Administrator (which is what Mark's analysis really showed) to do much good. The use of Power Users (and the fact that the group exists) generally provides a false sense of security. Take a look at Jesper's post - linked from within Mark's post here - which will point out that even in a senior Microsoft Security expert's opinion, a Power User is an Administrator who hasn't made themselves one yet.
 
Again a useful investigation Mark,

As has already been mentioned by a few other posters, the Power Users account also helps to prevent shooting oneself in the foot. I think you would have to be living on a different planet to think that the Power Users concept was bulletproof, but you would have to agree that you are 'safer' under power users than under administrator. While it doesn't prevent someone on a mission to elevate themselves, I believe it is better than nothing when it comes to somewhat restricting access to average computer users.

Until you can change the time and switch power modes, limited user accounts are simply too impractical for a lot of people (especially laptop users) every day use.

Is there any technical reason that anyone other than the administrators group would need access to the kernal? I can't think of one.

Adam
 
Note that the eWeek study shows that most malware writes to the Run key in HKLM\Software and the \Windows directory and so doesn't work in a limited-user environment, but does in Power Users. That will change over time, especially after the release of Vista, as malware adapts to a limited-user environment.

The study does not reflect the fact that malware can take control of the system using the techniques I outline.

Just another reason not to run as Power Users.
 
There is a policy which can be modified to allow accounts - including users - to change the system time. If users honestly need to modify the power configuration on a regular basis, the ACL for the power configuration key in the registry can be loosened to allow it. Neither is a strong enough reason to blow holes in security and have users run as Power Users.
 
Mark, I really appreciate the way you "think out loud" for lack of a better description. It helps clarify my own thought processes and increases my problem solving ability.

Please keep it up. :-)
 
Thanks Mark! That was very insightful and interesting...

Regards,

Michael
 
The Idea behind using Power Users isn't about stopping malware or other unwanted code.

It is about preventing user errors. In some cases you simply can't have the users running as users. Then the alternatives are power users or administrators.

Even though malware can exploit power users it still is better then making them admins in the first place.

in this matter I'm not worried about users that know how to elevate themselfes, I'm worried about the users that doesn't have any clue about that they are doing. Here the few restrictions on power users will save us some work
 
"a Power User is an Administrator who hasn't made themselves one yet."

I know I have :)

seriously, if you install a service standard on every desktop that runs as localsystem, make sure the user can't replace it with their own. In this case PCAnywhere.
 
Mark,
After reading this, I investigated my PC (XP with SP2 integrated into the install files), and discovered something worrying about the first account that is created.

That first account is by default a member of the Administrators group, and even after changing it to a Limited User, the account retains many write privileges to files in \WINDOWS\Driver Cache\i386 and \WINDOWS\system32 - presumably owner rights?
 
Anyone know if adding a user to all groups would limit a user's permissions even though they are in the administrator/power user groups. Do lower groups take any precedence if they are in more than one?
 
No. Group memberships don't behave that way. If the user is an administrator, they are an administrator.
 
For interest I had a look at a couple of popular anti-virus services and some exhibit similar permission problems.

In particular TrendMicro PCCillin makes it very trivial for any normal user (not even PowerUser) to obtain admin permissions. I knocked up a quick service replacement for tmntsrv.exe that grants a nominated user administrative privileges and without even needing a restart. As a normal user I was able to stop the real service, replace the service EXE with the new one, restart the service and was easily granted admin permissions (tmntsrv.exe runs as System). Extremely trivial to accomplish. Why normal users have change permissions to the EXE in Program Files is a concern.
 
For interest I had a look at a couple of popular anti-virus services and some exhibit similar permission problems.

I think the easiest way is to open up the Windows task manager and look for those processes run as system. On my machine I can easily replace several of these third party services with my own to run as system and administrative privilege is obtained.
 
It seems to me that the Power User group is frequently abused as a shortcut to making a program work that merely requires write access to a badly placed INI file.

It should be possible to set the folder permissions to allow a writable INI yet still lock down all executable file permissions within the folder to prevent substitution. Problem is: someone has to do it.

One of the things that strikes me as ironic is how certain popular anti-spyware and antivirus programs require the user to have administrator privileges. Sort of a 'we’ll protect you from 70% of burglars if you allow them all unrestricted access to your house' policy.

I wonder what proportion of malware can be blocked by running as a standard user account?

I also wonder if this question is never asked because it is bad for sales?
 
Same Anonymous user from a few posts ago:

Our desktop mgr had our desktop group added to all groups because some techs in other depts were removing us from local admins and he wanted to insure that we had some rights on the machines (I don't know why but he included us in the pwr usr group as well as users, bckup ops, and guests)
With us added to the guests group it wouldn't allow us to run Windows Update site even though we were in the local admin group. Should Guests permissions supercede Local Admin rights like that?
 
This was Digg-ed before - but it deserved front page status...

Let's try again. The Article and the Comments are quite helpful

Digg Article
 
The following services are exploitable from every account:

Adobe LM Service
Macromedia Licensing Service
Autodesk Licensing Service


Here is an example for AutoCAD 200? users:

sc stop "Autodesk Licensing Service"
sc config "Autodesk Licensing Service" type= own type= interact
sc config "Autodesk Licensing Service" binpath= "cmd /c start cmd"
sc start "Autodesk Licensing Service"

Now run pwdump2 or pwdump3 & after that LC4.

If you get the admin password there is no need for:
net localgroup administrators your_user_account /add

Have fun.

Thanks Mark for the article.
 
Post a Comment

This page is powered by Blogger. Isn't yours?

RSS Feed

RSS
    2.0

Index

Full Blog Index

Recent Posts

Why Winternals Sued Best Buy
The Case of the Mysterious Driver
Running as Limited User - the Easy Way
Using Rootkits to Defeat Digital Rights Management
Inside the WMF Backdoor
Rootkits in Commercial Software
The Antispyware Conspiracy
Sony Settles
Circumventing Group Policy as a Limited User
Premature Victory Declaration?

Archives

March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006

Other Blogs

Raymond Chen
Dana Epp
Aaron Margosis
Wes Miller
Larry Osterman
Bruce Schneier
Larry Seltzer