The Power in Power Users

The Power in Power Users

  • Comments 4
  • Likes
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.

Originally by Mark Russinovich on 5/1/2006 11:01:00 AM
Migrated from original Sysinternals.com/Blog
Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • PingBack from http://winblogs.security-feed.com/2006/05/01/the-power-in-power-users/

  • Comments Archive:

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    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?

    5/1/2006 12:55:00 PM by Kevin Dente

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

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

    5/1/2006 12:58:00 PM by Adam Gates

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    Perhaps you're referring to Domain Controller installs of the server OSs?

    Correct, thanks. I've changed the text to clarify.

    5/1/2006 1:01:00 PM by Mark Russinovich

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    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.

    5/1/2006 1:03:00 PM by Mark Russinovich

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    The Macromedia issue is supposed to have been fixed:

    http://www3.ca.com/securityadvisor/vulninfo/vuln.aspx?id=33043

    5/1/2006 3:16:00 PM by Aaron Margosis

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    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

    5/1/2006 3:19:00 PM by Paul Kierstead

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    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.

    5/1/2006 3:21:00 PM by Mark Russinovich

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    @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)

    5/1/2006 4:54:00 PM by Anonymous

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    I found a very nice GUI tool to edit DACL's on services: http://msdn.microsoft.com/msdnmag/issues/05/03/SecurityBriefs/

    5/2/2006 7:45:00 AM by Anonymous

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    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.

    5/2/2006 9:27:00 AM by Jason Star

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    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?

    5/2/2006 12:21:00 PM by Sean P. Kane

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    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.

    5/2/2006 4:00:00 PM by Paul Kierstead

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    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.

    5/2/2006 5:44:00 PM by Anonymous

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    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.

    5/2/2006 9:30:00 PM by jsminch

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    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.

    5/2/2006 9:47:00 PM by Wes

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    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

    5/2/2006 10:53:00 PM by Anonymous

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    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.

    5/3/2006 8:04:00 AM by Mark Russinovich

    --------------------------------------------------------------------------------

    # re: The Power in 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.

    5/3/2006 8:47:00 AM by Wes

    --------------------------------------------------------------------------------

    # re: The Power in 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. :-)

    5/3/2006 1:06:00 PM by Anonymous

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    Thanks Mark! That was very insightful and interesting...

    Regards,

    Michael

    5/3/2006 8:43:00 PM by Michael

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    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

    5/4/2006 2:40:00 AM by mats

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

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

    5/4/2006 8:32:00 AM by Anonymous

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    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?

    5/4/2006 1:45:00 PM by Michael Gibson

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    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?

    5/5/2006 11:35:00 AM by Anonymous

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    No. Group memberships don't behave that way. If the user is an administrator, they are an administrator.

    5/5/2006 3:49:00 PM by Wes

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    same guy as 2 above:

    I'd agree but my mgr recently added an account for desktop personnel to all other groups (pwr users, bckup ops, remote desktop, guests, users, etc) so other depts that had local admin rights who deleted our local admin permissions may not restrict all of our permissions on the pc's.

    I don't know why he chose to do that, but in light of it when we log on we our now unable to use Window's Updates site. Once we removed our group out of the Guests local group it worked. It seems the Guest group superceded other local permissions.

    5/8/2006 4:38:00 PM by Anonymous

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    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.

    5/8/2006 6:04:00 PM by Anonymous

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    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.

    5/9/2006 12:57:00 AM by stephen

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    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?

    5/9/2006 6:56:00 AM by Paul Coddington

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    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?

    5/9/2006 1:05:00 PM by jawz101

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    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

    5/9/2006 9:48:00 PM by http://search-engines-web.com/

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    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.

    5/10/2006 10:28:00 AM by Eric T

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    Eric T., thank you very much for information and step-by-step instructions.

    5/10/2006 12:35:00 PM by Anonymous

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    Hi Mark,

    This is a great article. If I may, I'd like to point people to a couple of security bulletins that were published about a year ago that provide fixes for the issues you note in Macromedia and Adobe Systems products.

    The Adobe License Manager bulletin and update are available here: http://www.adobe.com/support/techdocs/331688.html

    The Macromedia License Manager buletin and update are available here: http://www.adobe.com/devnet/security/security_zone/mpsb05-04.html

    There is also a list of all current security bulletins and a signup page for notifications available from http://www.adobe.com/support/security

    Regards,

    Adrian Ludwig

    PSIRT@Adobe.com

    Secure Software Engineering

    Adobe Systems, Inc

    5/11/2006 11:08:00 AM by Adrian Ludwig

  • Comments Archive:

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    @Adrian Ludwig:

    If I may, I'd like to point people to a couple of security bulletins that were published about a year ago …

    Yeah, yeah first release a crippleware then waits someone to say “ouch, there is a security problem here” & after that issue fixes. Again and again the picture is the same.

    1. Why use a service for licensing purposes?

    2. How many SOHU users read security bulletins for 3rd party products?

    Interestingly when MS will incorporate in the OS an automatic patch management system for 3rd party products?

    5/11/2006 1:41:00 PM by Eric T

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    Interestingly when MS will incorporate in the OS an automatic patch management system for 3rd party products?

    Only after they will stop distributing unpatched software on their own /downloads website.

    For example Microsoft Excel 20003 viewer directly downloaded from microsoft.com/download after installation automaticaly trigger critical security update.

    5/12/2006 11:49:00 PM by Anonymous

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    @Adrian Ludwig:

    This is untrue. Photoshop CS2 still suffers from exactly that problem, and I'm afraid to tell you we had to use a crack to make this legally purchased product get running (and it runs fine without AdobeLM). And when will you fix that damn installer? There's absolutely no need for the dependency on IIS Virtual RootFolders components.

    > Only after they will stop

    > distributing unpatched software on

    > their own /downloads website.

    Like MSIE? :-)

    5/15/2006 10:56:00 PM by Anonymous

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    Hello Everyone, I was also curious about image paths being a noob...? AF

    Mark, another great article! thank you...oh hey, can I look in your window internals book to find this answer?

    5/25/2006 10:57:00 AM by Anonymous

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    Cool writing! I'll definitely be looking into writing services the next week!

    - KRundern

    th ej or ak |AT| gm ai l. co m

    PS: @Anonymous:

    Guest "privileges" superseed Admin privileges because it has the DENY setting set, and DENY "is greater" than the ALLOW setting that the Admins have. If the Guest group didn't have the settings tagged at all, your Administrator privileges would superseed, but as the DENY flag is set, it doesn't.

    Unlucky you, have fun and go slap your "guru"...

    Privilege Escalation, you said? Surprisingly easy at these times...

    I just tried the old GetAdmin exploit (first exploit I ever used), and - it worked!

    Windows XP sp2, fully patched (I turned off my antivir that blocked it :)

    Elegant and easy

    >getadmin.exe johnny

    # Johnny has admin privileges

    5/26/2006 11:09:00 AM by KRundern

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    Adam wrote: 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.

    There are several reasons to not ever allow domain users (and one might argue especially for mobile users) to change their system time - not the least of which is keeping a consistent time across all systems (synched with a central time server) in your enterprise for log and event correlation. Additionally, Kerberos can get really whacked out (technical term ;-) with significant time changes, and many replication-enabled programs can be thrown into disarray with erratic time changes (future, then back to past across replication events).

    However, most importantly from a security standpoint, if a user is allowed to change his or her system time, forensic time stamps for breach or abuse cases becomes invalid: E.g. A user wants to steal intellectual property from your organization (engineering documents, source code, etc.) and then take that information to a competitor during a job change (even if the competitor has no knowledge of this), the user can change the system time to some point in the past (say, 3 years) to hide the data copy event then change it back. Thus, a forensic analysis of the disk and copy activity would not show a correlation between that data copy event and the time frame in question (job change).

    Since it is out-of-scope for this topic, we won't get into the ability to boot from CD (protected via BIOS password and boot order configuration) for a user to reinstall Windows or otherwise wipe a machine to blow away forensic evidence, but those are real systemic issues to consider when allowing users to change their own system times.

    5/28/2006 11:38:00 AM by KevFrey

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    There are always things that will be critical on some systems and not a concern on others. I do not deny the need to control who has access to change the time, in fact my software is time critical. Of course the time provided by the client workstation is automatically corrected when they change it ;), but I think my point was somewhat missed possibly because I was not clear enough.

    It is a bad thing for users to log themselves in as administrators, (or as discussed in the article and comments even power users). As developers, it is our responsibility to assist users and admins correct these bad habits.

    To do this effectively, I put forward that we the developers must take a dose of our own medicine. If we are limited users when we develop, then we are less likely to encounter problems when we deploy, and our support departments will not have to issue workarounds that involve elevating privileges.

    I simply isolated two areas of running as a limited user that really ticked me off. I will mention at this point that I am now able to change the system time and change power modes whilst still being a limited user. This involved changing the security to several registry keys as well as enabling some policy rules. I do not have a problem with these actions being denied by default (although I still can not see why power mode is relevant), the point is that administrators need an easier way to allow it.

    Btw, no version control system worth having would trust a client provided timestamp for tracking, and certainly no software solution is going to stop someone flicking a few jumpers on a motherboard.

    But that is beyond the point here. I need to change my system clock constantly to simulate various things which is why I needed it enabled.

    I have found the next annoyance if anyone is interested. When logged in as Admin/Pwr user and windows update does its thing, you get the choice to restart now or later. As limited user, you get 5 minutes with no option to cancel. I will shutdown after work and it can do its thing tomorrow morning when I boot up. I am never in a hostile environment, I do not have a wireless card in my laptop, I have both software firewalls and hardware firewalls wherever it is docked, and I am running as a limited user. I'll take my chances thankyou.

    Adam

    5/29/2006 9:58:00 PM by Anonymous

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    @KRundem:

    really wondering what "version" of GetAdmin you used. I tried three of them and neither one worked on my Windows XP SP2 fully patched.

    Would, please, someone explain what is image path and how to change it. Thank you...

    5/30/2006 5:40:00 AM by Anonymous

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    No doubt the Vista team has read the blog and signed the obligitory check to Mark once again.

    6/1/2006 8:15:00 PM by Anonymous

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    Nice article, Mark. That helped me out tremendously because I've noticed several compromised workstations. Run an MD5 hash check and I see one thing you pointed out - ntoskrnl has been modified from the original. Now I know where to start, I'm going to do a full re-imaging of all compromised machines and start running keyloggers on them to figure out who's doing what. On a side note, EMI has just released some new P2P service, and their software replaces tcpip.sys in Windows. Do you have any idea what this modified TCPIP file does? EMI just tells joe sixpack to wantonly click through all warnings. I have suspicions about this.

    6/7/2006 11:00:00 AM by KhyberKitsune

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    Great article, its great to see this type of system-assisted hacking still in use. I remember the good old NT4 days when all you needed to do was rename logon.scr and copy cmd.exe and rename it to logon.scr and then play the waiting game.

    I'm also pleased to see this type of open dialogue on security and even more pleased to see we've sorted this in Vista

    6/8/2006 4:26:00 AM by William Gunaratne

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    William Gunaratne,

    there is no cookie for you..

    Move out to a supermarket, or a bar nearby to pick up some for the night

    6/8/2006 6:33:00 AM by Anonymous

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    Greate article Mark

    I miss you new articles, make some more

    6/8/2006 6:38:00 AM by Anonymous

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    @Adam

    Here's how to prevent Windows from automatically rebooting after installing updates when running as a limited user:

    1. Open gpedit.msc from the Run dialog box.

    2. Right click on Administrative Templates under Computer Configuration and choose Add/Remove Templates.

    3. Press the Add button.

    4. Browse to the C:\WINDOWS\Inf directory. (It should default to this location automatically.)

    5. Double-click on wuau.adm

    6. Click the Close button.

    7. Now back in the Group Policy window expand the Administrative Templates folder, followed by the Windows Components folder. You should see a Windows Update folder.

    8. In the Windows Update folder is a group policy option called "No auto-restart for scheduled Automatic Updates installations." Set this option to enabled.

    Note that these steps won't work on XP Home edition due to the lack of Group Policy control. (gpedit.msc won't work) It should still be possible to get the same thing done on XP Home with a little research though. If you can figure out what registry changes the group policy setting makes you could manually apply them to a XP Home system since group policy settings are nothing more than registry modifications.

    Enjoy!

    6/9/2006 9:30:00 PM by Anonymous

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    Funny part you are all missing is why arent you locking things down in the first place.

    A few pointers:

    Get to know Subinacl.exe and review the default OS permissions on registry services,files and folders, and drop power-users down to size if you think its such a threat.

    ( easy to write a subinacl.exe script to remove power users rights on all services and registry and make them as weak as the users group)

    Secondly, you can use security templates via GPO's to drop the required NTFS permissions you want on files and folders, and audit modification of them from a central utility. Again baseline hardening, you don't do it up front, you bound to pay in the end.

    HTH

    EZ

    6/17/2006 8:47:00 PM by Anonymous

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    @EZ:

    >Funny part you are all missing is why arent you locking things down in the first place.

    There is no “in the first place” for buggy third party applications. Do you expect every Small Office/Home User to become IT security paranoid – rechecking the security of its PC(s) after each software installation or even after each software update?

    @EZ:

    >Get to know Subinacl.exe and review the default OS permissions on registry services,files and folders ...

    Thanks for this pointer. SubInACL is available for download from: http://www.microsoft.com/downloads/details.aspx?familyid=9d467a69-57ff-4ae7-96ee-b18c4790cffd

    The version of SubInACL that is included in Windows Server 2003 Resource Kit Tools is buggy (version 4, 0, 1, 1604) – it may not parse the command line arguments correctly.

    To display the security settings of all services:

    subinacl /verbose=1 /nostatistic /service *

    c or f grant permission for Everyone in some service probably signifies a problem.

    6/19/2006 12:03:00 PM by Eric T

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    Ops, I posted wrong url. The correct is: http://www.microsoft.com/downloads/details.aspx?FamilyID=e8ba3e56-d8fe-4a91-93cf-ed6985e3927b

    6/19/2006 12:23:00 PM by Eric T

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    A few posters have asked what is an image path. The image path is a registry entry called ImagePath, under the registry key for a service. The ImagePath controls the executable that's launched when a service starts. E.g, for the DComLauch service, the registry key is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DcomLaunch and the ImagePath setting is (on Windows 2003): %SystemRoot%\system32\svchost.exe -k DcomLaunch

    so when you start the DComLaunch service, it's like typing: c:\winnt\system32\svchost.exe -k DcomLaunch at a command line (I'm oversimplifying, but I hope you get the point).

    6/19/2006 5:10:00 PM by John M

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    Good article. One thing that I've used many times on customer's computers is to copy cmd.exe over top of logon.scr as pretty much any power user and then log out. Wait 10-15 minutes and you get a command prompt running as SYSTEM. Type explorer and you get your basic windows desktop while running as the user SYSTEM. From here I can do anything I need to fix the system.

    6/19/2006 10:45:00 PM by ytjohn

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    You have to have administrative powers to begin with to replace logon.scr. Here's the output of Accesschk:

    C:\windows\system32\logon.scr

    R BUILTIN\Users

    R BUILTIN\Power Users

    RW BUILTIN\Administrators

    RW NT AUTHORITY\SYSTEM

    6/20/2006 8:04:00 AM by Mark Russinovich

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    Nice article. This is further proof to me that Microsoft OS products continue to serve as nice examples of how *not* to design a computer operating system. You just can't patch security into an operating system. Will Vista finally get this right?

    6/24/2006 2:24:00 AM by Anonymous

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    Interesting. Fear of Power Users had led CIS and others to remove that Power User ACL wholesale (or as much as they could find) throughout the system. This caused massive application compatibility issues for XP. I'm often steering customers away from that and towards use of Restricted Groups--place Power Users in the Restricted Groups--to block use of that security group altogether. That seems to alleviate the application compatibility issues and accomplish the same thing a lot more simply. What do you think of this approach?

    6/27/2006 6:49:00 AM by Anonymous

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    >>On a side note, EMI has just released some new P2P service, and their software replaces tcpip.sys in Windows. Do you have any idea what this modified TCPIP file does?

    I'm not really qualified to tell you exactly what that application does to tcpip.sys, but I know of at least one legitimate change that can be made. Hard-coded into the stock version is a limit to the number of simultaneous outbound connection attempts that can be made in one second. Several patches I have seen allow users to change this value, and the changes do trigger a warning from Windows about it being changed. See http://www.lvllord.de/?lang=en&url=tools for example.

    I do not know if a power user is given write access to tcpip.sys by default.

    6/29/2006 11:44:00 PM by Anonymous

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    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.

    7/9/2006 5:27:00 AM by Brugte biler

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    Nice article Mark. Just one note, IIRC Power Users can execute AT.EXE command. Or am I wrong? It's trivial to elevate privileges using AT command...

    7/9/2006 10:37:00 AM by Anonymous

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    test

    7/20/2006 7:10:00 AM by Mark Russinovich

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    to Anonymous(previous): you may try to change privilegies with system accounts, but at many (all, as I tried) time you will cannot do it. SYSTEM is a kernel 'administrator' with personal rights, which even not fully showed in NTFS.

    Anyway, you will not be able to change local user`s privilegies to administrator role without change some files (or put them) and had logon of "real" Administrator.

    7/21/2006 1:07:00 PM by rex

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    Mark,

    Great article (as usual), very instructive about how to think about priviledge excalation.

    Regarding your June 20th post (apparently) answering June 8th Will Gunaratne's remark about logon.scr: I understand Will was speaking about NT4; and on NT4, AccessChk definitively shows RW access (including for Everyone):

    C:\WINNT\system32\logon.scr

    RW BUILTIN\Administradores

    RW Todos

    RW BUILTIN\Opers. de servidores

    RW NT AUTHORITY\SYSTEM

    7/24/2006 9:46:00 AM by Antoine

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    Regarding PatchGuard in XP x64, PatchGuard does a conditional jump if there is a kernel debugger present and skips activation. A hexedit could turn the conditional jump into an unconditional jump.

    Original article:

    http://www.uninformed.org/?v=3&a=3

    8/1/2006 7:19:00 PM by andreyvul

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    If you have physical access to a computer you can get in and do anything you want.

    What you want to prevent is a program running as user or power user from getting administrator rights and doing anything it wants. (spy/adware keylogers worms)

    Mark used to sell a nice utility called locksmith that did a fine job of changing the administrator password.

    And with a PE disk you can do anything to the file system because your system

    There are ways to secure your physical computer. But most places don’t bother.

    If you are an “End user” at a corporation and you are thinking about trying anything in this posting you better have a backup job. At my company we have fired employees for much less rooting there box.

    8/1/2006 9:52:00 PM by Chris Thornton

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    At school, I had to install dlportio (turing parallel port driver). It required admin priveleges, so I pooped in a password recovery floppy to copy the hashes. The weaknesses of the NT LM hash allowed me to "un-hash" the passwords.

    If the computer has a floppy, the password is recoverable (loginrecovery.com)

    You could also try putting the image onto a USB key.

    8/3/2006 2:35:00 PM by andreyvul

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    There is a simple way for a Power User to create a local admin account, if they can use the MMC, which worked for me on an XP-SP1 machine. Mark's technique is interesting but likely to be useful only to those who don't really need it, whereas my technique could be used by a child. Which is why I won't post it. A serious problem with User accounts that we have here at the (big) bank is that the local support staff keeps elevating them to admins. So the IT department doesn't know, or doesn't know the extent, that their account policies are not being enforced. The attempt to lock down the desktop here is quite a farce, given that Microsoft Office is installed everywhere, not to mention WSH, etc. Since the IT department has demonstrated that they can't get the apps to install and run consistently for Users, it would be best to just make everyone a Power User. If the end user is truly incompetent, which some are, they can be demoted to User. And if they elevate to Admin on their own, they can be shown the door.

    --

    Allan

    (Snail) Mail specialist

    9/26/2006 5:28:00 PM by Anonymous

    --------------------------------------------------------------------------------

    # re: The Power in Power Users

    Love the article. Is there a way to use Accesschk with a domain group? I try it and I get 'The specified user does not exist'. If not does anyone know of one?

    Thanks,

    Eric

    9/26/2006 6:14:00 PM by eric

  • A little over a year ago I set out to determine exactly why, prior to Window Vista, the Power Users security