Understanding Windows Service Hardening

In Server 2008 and Vista, each service can have a service-specific SID. Administrators and service developers can use service-specific SID in ACLs to protect service-specific resources. In earlier Windows versions, if you use a built-in service account (e.g., the local system account, the network service account) to run a service and grant the service account access to a resource, you also implicitly allow all other services that run under the same service account to access that resource whether they need it or not. To avoid this problem, administrators typically create a custom Windows account to run their services. However, this practice creates additional account management overhead. When you create custom service accounts, you can't leverage the automated password management features Windows provides for built-in Windows accounts.

Because Server 2008 and Vista let you create a service-specific SID for services, you don't need to worry about the cumbersome process of creating and maintaining custom service accounts. The service-specific SID is linked to the service’s name (e.g., MyService), and not to the service account (e.g., LocalSystem) or to a custom Windows account. Thanks to service-specific SIDs, you can continue to use the built-in service accounts for authenticating your service while relying on the service-specific SID to set permissions on service resources.

If you want a service to have a service-specific SID, you must set the service’s SID type property to either unrestricted or restricted—I explain the difference between these two property types later in the section on write-restricted tokens. You can set a service’s SID type by using the SC command:

sc sidtype service_name unrestricted 

To query the current value of a service’s SID type property, enter

sc qsidtype service_name 

When your service has a service-specific SID, Windows automatically computes a SID and links it to the service. The next time the service starts, that SID is added to the access token of the process that hosts the service. Service-specific SIDs are local (i.e., machine-level as opposed to domain-level) SIDs.

The service-specific SID is constructed from the service name using the format S-1-5-80-{SHA-1(service name in uppercase)}. As you can see, the SID for a particular service is identical for all Vista and Server 2008 machines, which greatly facilitates resource permissioning for the service on different machines.

After you configure a service-specific SID, you can leverage the SID to restrict access to your service’s file system and registry resources. To refer to a service-specific SID when setting permissions on resources, use the syntax NT SERVICE\service_name.

Service-specific SIDs let administrators better control access to service resources. However, a service-specific SID can't prevent a service from accessing the resources to which its service account’s SID has access. For example, let's say MyService runs in the security context of the local service account and has a service-specific SID defined. In addition to having access to objects that the service-specific SID specifically grants access to, MyService can access all objects that the local service account can access. If MyService were compromised, an attacker could access non-service–related resources.

In Server 2008 and Vista, Microsoft tackles this problem by introducing write-restricted service-specific SIDs (which I'll refer to as restricted SIDs). You can make a service-specific SID restricted by setting its SID type property to restricted:

sc sidtype MyService restricted 

Developers can make a service’s SID write-restricted by including the WRITE_RESTRICTED flag in the service code. When a service has a write-restricted SID, an extra access-control check occurs when the service attempts to access a resource. The access-control check consists of two independent passes. For access to be granted, both passes must succeed.

The first pass is the typical access control pass that's always performed. During this pass, Windows evaluates whether a service should be denied or granted access to a resource according to the resource’s permissions and the information in the service’s hosting-process access token.

The second pass is an extra access control pass that normally doesn't occur. During this second pass, Windows explicitly checks whether the resource’s permissions give explicit write access to either the service-specific SID, or the predefined "Logon SID," "Everyone," or "WRITE RESTRICTED" SIDs.

You can use restricted SIDs only to restrict access to a service—not to broaden access. For example, if you enable a restricted SID for MyService, MyService cannot write to any of the objects to which the LocalService account can write unless those objects also explicitly grant write access to MyService's service SID.

Although write-restricted SIDs significantly improve security, they also require extra management. For a service to operate properly after it's been assigned a write-restricted SID, you must find all resources that the service needs write access to, then explicitly grant the service write permission to each one. (No pain, no gain!)

The Windows Firewall service (mpssvc.exe) is an example of a service whose SID is defined as write-restricted. It's hosted together with other services in a single svchost.exe process instance. The service account of the svchost.exe instance is the local system account. You can use the SysInternals Process Explorer tool to check the content of the svchost.exe instance’s access token. Open the properties of the Windows Firewall's svchost.exe instance and click the Security tab. You'll see an interface like that in Figure 5. The effect of defining the Windows Firewall’s SID as write-restricted is that only the Firewall service (not any other services that are also running in the security context of the local system account) is allowed to write to resources to which the Firewall service’s SID has been granted explicit write access. One such resource is the %System%\LogFiles\Firewall folder, which holds the Windows Firewall logs.

The final piece of Windows Service Hardening consists of the restrictions developers can put on a service’s network access. A common misconception about the new service network access restrictions is that they are integrated with the network restrictions defined in the Windows Firewall (the personal firewall that runs on every Vista and Server 2008 platform). In fact, they are not. Network access restrictions for services

• are evaluated before the Windows Firewall rules; 
• are enforced regardless of the status of Windows Firewall—even when Windows Firewall is turned off; 
• can be used only to restrict (deny) access for a service, not to grant (allow) access; 
• can be used for both inbound and outbound connections to services; and 
• can't be defined from the Windows Firewall with Advanced Security MMC snap-in or using the netsh advfirewall command—they must be defined programmatically using the INetFwServiceRestriction and INetFwRule programming interfaces.

Besides letting developers define custom network access restrictions for services, Server 2008 and Vista include a set of predefined network access restrictions for built-in services. You can't modify these predefined restrictions using the programming interfaces I mentioned above, but if you have administrator-level privileges you can modify them in the system registry. Both types of service network access restrictions are stored in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\ registry key. The predefined restrictions are stored in the Static\System key, as Figure 6 shows; custom restrictions are stored in the Configurable key.

Windows Service Hardening is a big and important step in Microsoft’s crusade to make Windows a fundamentally secure platform. I think Microsoft could have made the configuration of the features simpler, but they might have intentionally chosen not to: Locking down services is something that should be left to developers and security specialists. Nevertheless, it's important for every Windows administrator to have a good understanding of the workings of Windows Service Hardening.