Service Resource Isolation
Many services execute in the context of the same local account, such as LocalService. If any one of these services is compromised, the integrity of all other services executing as the same user are effectively compromised as well. To address this, Microsoft meshed two technologies:
• Service-specifi c SIDs
• Restricted SIDs
By assigning each service a unique SID, service resources, such as a file or Registry key, can be ACLed to allow only that service to modify them. The following example shows Microsoft’s sc.exe and PsGetSid tools (microsoft.com) to reveal the SID of the WLAN service, and then performing the reverse translation on the SID to derive the humanreadable account name:
C:\>sc showsid wlansvc
NAME: wlansvc
SERVICE SID: S-1-5-80-1428027539-3309602793-2678353003-1498846795-3763184142
C:\>psgetsid S-1-5-80-1428027539-3309602793-2678353003-1498846795-3763184142
PsGetSid v1.43 - Translates SIDs to names and vice versa
Copyright (C) 1999-2006 Mark Russinovich
Sysinternals - www.sysinternals.com
Account for S-1-5-80-1428027539-3309602793-2678353003-1498846795-3763184142:
Well Known Group: NT SERVICE\Wlansvc
To mitigate services that must run under the same context from affecting each other, write-restricted SIDs are used: the service SID, along with the write-restricted SID (S-1-5-33), are added to the service process’s restricted SID list. When a restricted process or thread attempts to access an object, two access checks are performed: one using the enabled token SIDs and another using the restricted SIDs. Only if both checks succeed is access granted. This prevents restricted services from accessing any object that does not explicitly grant access to the service SID.
Least Privilege Services
Historically, many Windows services operated under the context of LocalSystem, which grants the service the ability to do just about anything. In Vista and later, the privileges granted to a service are no longer exclusively bound to the account to which the service is configured to run; privileges can be explicitly requested.
To achieve this, the Service Control Manager (SCM) has been changed. Services are now capable of providing the SCM with a list of specific privileges that they require (of course, they cannot request permissions that are not originally possessed by the principal to which they are configured to start). Upon starting the service, the SCM strips all privileges from the services’ process that are not explicitly requested.
For services that share a process, such as svchost, the process token contains an aggregate of all privileges required by each individual service in the group, making this process an ideal attack point. By stripping out unneeded privileges, the overall attack surface of the hosting process is decreased.
As in previous versions of Windows, services can be configured via the commandline tool sc.exe. Two new options have been added to this utility, qprivs and privs, which allow for querying and setting service privileges, respectively. If you are looking to audit or lock down the services running on your Vista or Server 2008 (and later) machine, these commands are invaluable.
If you start setting service privileges via sc.exe, make sure you specify all of the privileges at once.
The tool sc.exe does not assume you want to add the privilege to the existing list.
Service Refactoring
Service refactoring is a fancy name for running services under lower privileged accounts, the meat-and-potatoes way to run services with least privilege. In Vista and later, Microsoft has moved eight services out of the SYSTEM context and into LocalService. An additional four SYSTEM services have been moved to run under the NetworkService account as well.
Additionally, six new service hosts (svchosts) have been introduced. These hosts provide added flexibility when locking down services and are listed here in order of increasing privilege:
• LocalServiceNoNetwork
• LocalServiceRestricted
• LocalServiceNetworkRestricted
• NetworkServiceRestricted
• NetworkServiceNetworkRestricted
• LocalSystemNetworkRestricted
Each of these operates with a write-restricted token, as described earlier in this chapter, with the exception of those with a NetworkRestricted suffix. Groups with a NetworkRestricted suffix limit the network accessibility of the service to a fixed set of ports.
This article is an excerpt from Hacking Exposed 7: Network Security Secrets & Solutions published by McGraw Hill. Visit Amazon to purchase the book.
All information in this article is copyrighted by McGraw Hill and is reprinted here by express permission of the publisher.