The Power in Power Users

Placing Windows user accounts in the Power Users security group is a common approach that organizations take to get users into a least-privilege environment while avoiding the many pains of running as a truly limited user. The Power Users group can install software, manage power and time-zone settings, and install ActiveX controls—actions that limited users are denied. However, this power comes at the price of true limited-user security. Many articles point out that members of the Power Users group can elevate themselves to fully privileged administrators, but I was unable to find a detailed description of these elevation mechanisms. I therefore decided to investigate. You can see the details of my investigation at http://www.sysinternals.com/blog/2006/05/power-in-power-users.html.

To summarize, I discovered that although Power Users can create files underneath the Windows directory, Windows configures default security permissions so that only members of the Administrators group and the Local System account have write access to them. But there's one glaring exception: ntoskrnl.exe. That's right, the Power Users group can replace or modify Windows' core OS file. Five seconds after the file is modified, however, Windows File Protection (WFP) will replace it with a 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.

But how could someone use this vulnerability to elevate privilege? The answer is via SeSinglePrivilegeCheck, the function that Windows uses for privilege checks. A user simply patches the function's entry point in the ondisk image so that it always returns TRUE, which indicates that a user has the privilege being checked for. Once a user is running on a kernel modified in this manner, the user appears to have all privileges, including Load Driver, Take Ownership, and Create Token, which the user can easily leverage to take administrative control of a system.

Replacing ntoskrnl.exe isn't the only way to punch through to administrative privilege via the Windows directory. Default permissions for schedsvc.dll allow modification by members of the Power User group. Schedsvc.dll is the DLL that implements the Windows Task Scheduler service. A member of Power Users could replace the DLL with an arbitrary DLL, such as one that simply adds the user's account to the Local Administrators group.

Next, I looked at Power Users' access to the Program Files directory and discovered that Power Users can modify any file or directory created in Program Files subsequent to those created during the base Windows install. Replacing these service image files is a quick path to administrator privilege.

When I looked at Windows services, I found that users with SERVICE_CHANGE_CONFIG write permissions can configure an arbitrary executable to launch when a service starts, and given WRITE_DAC access, they can modify the permissions on a service to grant themselves SERVICE_CHANGE_CONFIG access. I discovered that Power Users have write access to DComLaunch, which provides launch services for DCOM services and executes in the powerful Local System account. Thus, Power Users can simply change the image path of DComLaunch to point at their own image, reboot the system, and enjoy administrative privileges. The default permissions Windows sets on services created by third-party applications don't allow Power Users write access, but some third-party applications might configure custom permissions to allow them to do so.

Microsoft's newest OS, Windows Vista, closes down all the vulnerabilities I've described by neutering the Power Users group so that it behaves like limited users. But Microsoft can't prevent third-party applications from introducing new vulnerabilities. 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.