Home > Enterprise Desktop Tips > Windows desktop security tips > Service level security in Windows Vista and Windows Server 2008
Enterprise Desktop Tips:
EMAIL THIS
 TIPS & NEWSLETTERS TOPICS 

WINDOWS DESKTOP SECURITY TIPS

Service level security in Windows Vista and Windows Server 2008


Joel Scambray
08.05.2008
Rating: -3.00- (out of 5)


Advice for securing Windows
Digg This!    StumbleUpon Toolbar StumbleUpon    Bookmark with Delicious Del.icio.us    Add to Google


[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


Digg This!    StumbleUpon Toolbar StumbleUpon    Bookmark with Delicious Del.icio.us    Add to Google


RELATED CONTENT
Windows desktop security tips
Managing multiple passwords in Windows
Using System Center Essentials as a patch management tool
How Windows 7 stands up to security tests
Securing sensitive data on Windows-based laptops
Gathering and documenting your Windows desktop security policies
Windows desktop security standards documentation best practices
Desktop security preparation for a new wave of Windows apps
Four Internet Explorer 8 group policy security settings
The state of enterprise security and emerging threats in 2009
Why should Windows shops use Microsoft Baseline Security Analyzer?

Windows Vista security issues, updates and alerts
Ten ways to sell security to management
Improve Windows security with our top 10 tips
Windows Vista management tutorial
Minasi says Vista SP1 solves problems, adds new ones
Does Vista's strong security make it better than XP?
Are Windows Vista's features silencing critics?
Managing single sign-on security burdens in Windows
Top 10 ways to improve Windows Vista security
A Windows security checklist for IT managers
Unauthenticated vs. authenticated security testing

RELATED GLOSSARY TERMS
Terms from Whatis.com − the technology online dictionary
drive-by download  (SearchEnterpriseDesktop.com)

RELATED RESOURCES
2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems
Search Bitpipe.com for the latest white papers and business webcasts
Whatis.com, the online computer dictionary


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.


Rate this Tip
To rate tips, you must be a member of SearchEnterpriseDesktop.com.
Register now to start rating these tips. Log in if you are already a member.




DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.



Enterprise Desktop Security - Virus Protection, Malware Protection, Intrusion Detection
HomeTopicsITKnowledge ExchangeTipsMultimediaWhite PapersBlogs
About Us  |  Contact Us  |  For Advertisers  |  For Business Partners  |  Site Index  |  RSS
SEARCH 
TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations' technology projects - with its network of technology-specific websites, events and online magazines.

TechTarget Corporate Web Site  |  Media Kits  |  Site Map




All Rights Reserved, Copyright 2008 - 2009, TechTarget | Read our Privacy Policy
  TechTarget - The IT Media ROI Experts