[TABLE]Just as Windows XP and WindowsServer 2003 took great strides in reducing risk by limiting the number of enabled services and the privileges they possess, Vista and Server 2008 have taken service level security even further with Windows Service Hardening, which includes the following:
In the event an application, service or account becomes compromised, one of the first things you start to ponder is just how bad bad is going to get. Suppose an attacker compromises a Web service in your DMZ: where can she go from there? Does the Web service pull information from a database that sits behind your internal firewall? What permissions does the account used by the Web service have on the database? Can it execute extended SQL procedures such as xp_cmdshell to compromise the database server? If you entertain this thought line long enough, you may start to notice similarities between your security controls and a set of dominos.
Let's take this concept and apply it locally to a single machine. Many services execute using the same local account, such as LocalService. If one of these services is compromised, the integrity of all other services executing as the same user is in jeopardy as well. An attacker can jump from service to service. To compound this, services typically store configuration information in areas of the operating system that are accessible only to highly privileged principals. An artifact of this is a higher number of services executing as SYSTEM. What we are left with is a group of fairly low-privileged services that are capable of compromising each other and another group of services that operate under a highly privileged context to store configuration information securely. Not cool. To address this, Vista and Windows Server 2008 mesh two technologies:
• service-specific SIDs
• restricted SIDs
By assigning each service a unique SID, service resources, such as a file or registry key, can be ACL
To continue reading for free, register below or login
To read more you must become a member of SearchEnterpriseDesktop.com
ed to allow only that service to modify them. This gets us a bit closer to executing services with lower privileges while protecting their configuration data.
To determine the SID assigned to a given service, we can lean on new functionality that has been added to sc.exe: showsid. We can take this one step further and identify the principal name associated with the service SID by running psgetsid.exe. The following listing demonstrates how to obtain the SID and the principal name of the WLAN services:
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
C:\>
NOTE> PSGetSid is available for download from Microsoft TechNet.
This alone will not prevent a compromised service that is running as LocalService from modifying the resources of other services executing as the same principal. To achieve this, write-restricted SIDs are used: the service SID, along with the write-restricted SID S-1-5-33), is 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 will access be granted. This prevents restricted services from accessing any object that does not explicitly grant access to the service SID.
For example, assume we have two services, A and B, which execute under the context of LocalService (and thus have LocalService as their enabled token SID). These services store configuration information in the registries under HKLM\System\CurrentControlSet\Services\ServiceA and ServiceB, respectively. The DACL on both registry keys grant LocalService the ability to write to the keys. Additionally, each DACL grants write access to the appropriate service SID. At this point, if either service is compromised, it can modify the configuration information of the other service. This is because both service processes contain the LocalService SID.
However, if these services are hosted in different processes and each process has its respective service SID in the restricted SID list, the services cannot modify each other's registry values. This is because the process tokens do not have the LocalService SID added to the restricted SID list.
To determine whether a service is restricted or not, simply run sc.exe with the qsidtype option. The following listing demonstrates the results of querying unrestricted and restricted services:
C:\tools>sc qsidtype wlansvc
[SC] QueryServiceConfig2 SUCCESS
SERVICE_NAME: wlansvc
SERVICE_SID_TYPE: UNRESTRICTED
C:\tools>sc qsidtype bfe
[SC] QueryServiceConfig2 SUCCESS
SERVICE_NAME: bfe
SERVICE_SID_TYPE: RESTRICTED
C:\tools>sc qsidtype sysmain
[SC] QueryServiceConfig2 SUCCESS
SERVICE_NAME: sysmain
SERVICE_SID_TYPE: NONE
C:\tools>
By creating service-specific SIDs and coupling them with restricted SID lists, the probability of a compromised service successfully attacking another service that executes as the same principal is greatly reduced.
