Understanding Windows Service Hardening

Windows services have long been a favorite target of malware and hackers. This popularity is the result of a couple of factors. First, many Windows services are turned on by default and can communicate with the network. Second, quite a few services run in a highly privileged security context—for example, the local system account. If such a service is compromised, malware can do anything it wants on the system, including installing programs; viewing, changing, or deleting data; and creating new accounts.

The Blaster worm is one infamous example of malware that leveraged a highly privileged Windows service to harm IT infrastructures around the globe. Blaster exploited a vulnerability in the Windows remote procedure call (RPC) service to execute a buffer overflow that empowered the attacker to run programs and code with local system account privileges on the affected system.

In Windows Server 2008 and Windows Vista, Microsoft uses Session 0 isolation, new least-privilege restrictions for services, service-specific security identifiers (SIDs), write-restricted SIDs, and restricted network access to reduce the attack surface of services. Together, these changes are referred to as Windows Service Hardening.

Windows was designed as a multiuser system, which allows different users to use the OS in parallel and enables, among other things, simultaneous user access to file server data. Windows Session Manager (smss.exe) orchestrates this multiuser system, creating and managing terminal sessions (usually referred to as simply "sessions," but not to be confused with user logon or terminal server sessions) for users. Session Manager is one of the first processes to start when Windows boots.

Sessions offer some degree of isolation between services and applications that run in different sessions. Communication between processes that run in the same session occurs easily, but communication between sessions is more restricted and subject to certain security checks. (For details about the workings of Session Manager, see Mark E. Russinovich and David A. Solomon, Microsoft Windows Internals, Microsoft Press, 2005. A new edition is scheduled for release in November 2008.)

The first session created when the OS boots is referred to as Session 0, or the console session. In pre-Vista Windows versions, Session 0 runs services and the applications that are started by the first user who logs on to Windows interactively. However, using Session 0 for user applications is risky because it lets malicious user applications easily interfere with highly privileged services.

The Session 0 isolation feature in Server 2008 and Vista ensures that only Windows services can run in the console session. Applications that are started by the first user to log on interactively run in another session, named Session 1, and thus can't interfere with or affect highly privileged services. Figure 1 illustrates the differences between Windows XP's and Windows Server 2003's session-management architecture and that of Windows Server and Vista.

In Server 2008 and Vista, Session 0 is also marked as non-interactive, meaning that services can't directly communicate with users (e.g., services can't create dialog boxes that request user input). In the past, certain malware attacks leveraged interactive services’ user communication capabilities. Now, services—even those that are marked as interactive or have the Allow service to interact with desktop option enabled in their service properties—won't be visible to users. Although the services will be running, users won't see them in the Windows GUI.

You can see the effect of Session 0 isolation and the fact that this session is marked as non-interactive when you use the At command (at.exe) in Server 2008 or Vista to schedule interactive execution of a program. Because Task Scheduler runs in Session 0, it can't execute programs that interact with the user desktop. The scheduler informs you of this restriction when you schedule an interactive program, as Figure 2 shows.

The fact that Session 0 is marked as non-interactive doesn't mean that Session 0 services can't interact with users–some applications require this functionality. Developers can use secure interprocess communications tools such as named pipes and RPCs to let Session 0 services securely interact with the desktop. You can find more information on the effects of Session 0 isolation and how developers can deal with it in their applications, services, and driver software in the Microsoft white paper "Impact of Session 0 Isolation on Services and Drivers in Windows Vista" at www.microsoft.com/whdc/system/vista/services.mspx.

Microsoft also provides a workaround for the non-interactive nature of Session 0 for legacy services or services that your organization can't just rewrite on the fly. The workaround is the Interactive Services Detection service (ui0detect.exe). This service is turned off by default. When you turn it on (from the Services node in the Microsoft Management Console—MMC—Active Directory Users and Computer snap-in or from the command line using sc.exe), it enables legacy interactive services to interact with the user. When a service attempts to interact with a user, ui0detect generates a user approval prompt before displaying the actual service dialog box.

The Interactive Services Detection service workaround is both insecure (which explains why Microsoft turns it off by default) and temporary. Malicious software can leverage the service to interact with the user. Microsoft plans to remove the ui0detect service in the next major Windows release.

Additionally, the Interactive Services Detection service works only for Windows GUI–based services, not for console- or command prompt–based services. Turning ui0detect on doesn't re-enable the At command to execute interactive tasks.

Server 2008 and Vista include several least-privilege mechanisms that guarantee that a service gets only the privileges it needs to do its job—nothing less and nothing more. For example, Microsoft revisited the default permissions and rights assigned to the built-in Windows services and removed several unneeded service permissions and rights. Also, many services that ran on the local system in earlier Windows versions now run as either LocalService or NetworkService—the two less-privileged service accounts introduced in XP SP2 and Windows 2003.

Additionally, a brand-new mechanism specifies and enforces the rights that are assigned to a service. You can think of this mechanism as a User Account Control (UAC)–like least-privilege solution for services. (A Server 2008 and Vista least-privilege feature, UAC ensures that, by default, user applications execute with few privileges and that all users—including administrators—have only basic user-level privileges. For an introduction to UAC, see “Windows Vista’s Take on Least Privilege,” October 2006, InstantDoc ID 93300.)

Here's how the least-privilege mechanism for services works. The Service Control Manager (SCM) component assigns service privileges according to the privilege information specified in a service’s RequiredPrivileges registry entry. The SCM ensures that only the privileges specified in the service’s RequiredPrivileges entry are enabled in the access token of the process that hosts the service. The SCM also enforces the RequiredPrivileges settings beyond system startup by ensuring that a service can't be given additional privileges while it's running. All services’ configuration information is stored in the registry's HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services key, which has a subkey for each service that runs on your system.

Suppose I create a service called MyService and set it to execute in the security context of the local system account (i.e., MyService’s service account). On Server 2008 and Vista, I can specify that MyService requires only the Backup files and directories user right by including this right in the service’s RequiredPrivileges registry entry. When the SCM starts MyService, it will enable only the Backup files and directories user right in the access token of the process that hosts MyService. In earlier Windows versions, the hosting process had an access token that enabled all the default privileges given to the local system account. Because the local system is the almighty account on a Windows machine, that approach gave the service many privileges.

To set a service’s RequiredPrivileges registry entry and specify the rights that the service should have, you can use the SC command. For the MyService example, I could restrict MyService’s rights by running the command

sc privs MyService SeBackupPrivilege 

To get an overview of the required rights as they are specified in a service’s RequiredPrivileges registry entry, use the command

sc qprivs service_name 

where service_name is the name of the service whose rights you want to see. Figure 3 illustrates the required rights as they are specified in the registry for the remote management (WinRM) service.

To observe the effect of the SCM’s rights-filtering actions, you can use the Windows Sysinternals Process Explorer tool. (It's available at technet.microsoft.com/en-us/sysinternals/bb896653.aspx.) Start Process Explorer and right-click a process to open its properties, then click the Security tab. Figure 4 shows the security properties of the Winlogon process as they appear in Process Explorer. Note that even though Winlogon runs in the security context of the local system account (NTAuthority\System), its access token contains several rights that are disabled, thanks to the new least-privilege restrictions.