Security WatchServices Hardening in Windows Vista

Wole Moses

Microsoft announced its Trustworthy Computing Initiative in early 2002, in the aftermath of several high-profile viruses and worms that wreaked havoc on Windows systems, paralyzed IT departments, and cost businesses and consumers enormous sums to remediate. With this initiative, Microsoft issued a

mea culpa regarding its security track record and made a swift course correction and paradigm shift from developing software with an emphasis on rich features and usability to prioritizing around software security and integrity. The Blaster worm struck in August 2003, adding further impetus to the security initiative. (For the Blaster story, see the sidebar "Attack of the Clones.")

The tenets of the trustworthy computing initiative are Secure by Design, which speaks to the secure coding philosophies; Secure by Default, which is about ensuring that components of Windows® default to the most secure setting possible; and Secure in Deployment, which has to do with the creation of tools and prescriptive guidance to help businesses and consumers secure their Windows infrastructure.

Overall the Trustworthy Computing Initiative resulted in major improvements in security; unfortunately, Windows XP could never fully benefit as it was released two years before the initiative took off. (Though Service Pack 2, SP2, made great strides to incorporate these philosophies, Windows XP could not be completely retrofitted into this initiative.)

Thus, Windows Vista™ is the first Microsoft desktop operating system that is fully compliant with the goals of Trustworthy Computing. Windows Vista Services Hardening, a specific implementation of the Trustworthy Computing Secure by Default principle (see Figure 1), is an important new capability that is designed to thwart errant service behavior that much of today's malware can currently perform. Service Hardening helps Microsoft take huge steps in changing the default behavior and security profile of Windows services.

Figure 1 Secure by Default: Windows Services

Risky Services

Windows services, formerly known as NT services, are long-running executable applications that run in their own Windows sessions. Services can be started automatically when the computer boots, can be paused and restarted, generally don't show any user interface, and can run in the security context of an account that is different from either the logged-on user or the default computer account. Windows services are thus a great facility for certain types of application development and for end users who need to use these applications. However, because of their power and flexibility, Windows services have traditionally been vulnerable to exploitation-for several reasons.

First, in the past, Windows services have generally run in highly privileged Windows accounts such as the Local System account. If a service running in the Local System account is compromised by malware, the malware has a great chance of doing absolutely anything it desires on that system. Consider, for example, the remote procedure call (RPC) service in Windows XP. Prior to Windows XP SP2, the RPC service ran under the Local System account, which is what enabled Blaster, Welchia, and other worms to perform administrative tasks once the RPC vulnerability was exploited.

Second, many services are network-facing, which provides an opportunity for malware to exploit them by creating inbound connections to them over the network, and for an infected service to make an outbound connection to infect other systems or perform some other illicit activity such as forwarding monitored keystrokes. Most of today's worms and malware infections occur through some method of network connection.

Finally, services are typically long-running, which is to say that they run from the time a system boots up until it is shut down. This is attractive to malware writers because it means they can probe that service for flaws for as long as the system is up-ultimately providing malware plenty of time to perform its nefarious activities.

Attack of the Clones

It could be his greatest triumph. If everything went according to plan, he might soon control hundreds of thousands of Windows systems around the world, issue virtually any instruction to them, and then kick back and watch them obediently carry out his every command.

Persistent yet elusive in his methods, he started by surreptitiously probing several computer systems, looking for a vulnerable entry point. It didn’t take long to find exactly what he was looking for—an unpatched system suffering from a known vulnerability he knew exactly how to exploit.

What made this particular vulnerability so sinister was that by successfully exploiting it, he could gain full administrative access to the system. He wasn’t taking control of just any account: he was manipulating the most powerful administrative account in Windows. Whatever he did next was limited only by his imagination.

After a few moments of reflection, he tested his rogue code against the unpatched and vulnerable machine—and it worked! As simple as that, he now had unlimited privileges to the computer. He used his administrative access to force the machine to download and install Trojan horse code, make registry modifications, and then reboot, turning the infected system into a surrogate ready and willing to carry out his commands. The registry modification caused the malicious software to run every time the computer restarted.

Now his intentions became clear. Upon infection, any contaminated machine would probe specific network ports of all other machines on the network. If that network port was open, and the machine was vulnerable, the Trojan horse code would be downloaded and installed to this new machine. The same registry modifications would occur. The cycle would recursively repeat itself and thus a swelling army of attack clones was created. By the end of the day, thousands of Windows systems around the planet were part of his sinister clone army, unresponsive to any commands issued by anyone else in the world.

As if that were not enough, he then turned his sights on the Microsoft Windows Update site and instructed all of his clones to perform a Denial of Service Attack on August 15, 2003 in an attempt to prevent any computer anywhere in the world from downloading the vulnerability fix that, interestingly enough, had been available for months.

By now you probably realized that I just described the MS Blaster worm pandemic that, in August 2003, struck Windows computers in every corner of the globe. Blaster was arguably one of the most serious attacks on Windows ever, causing billions of dollars in damage. The irony is that although MS Blaster had enormous power over machines it infected, it was remarkably simple in its implementation.

How Blaster Works

Blaster and its derivatives use a vulnerability in the Windows RPC service to execute a buffer overflow. An attacker who successfully exploits this vulnerability would be able to run code with Local System privileges on an affected system, enabling him to take any action on the system: install programs, view, change, or delete data, and create new accounts with full privileges.

In the case of Blaster, the worm automatically scans networks looking for computers with open TCP port 135. When it finds a victim, Blaster attempts to exploit the RPC vulnerability. If successful, it then connects to port 4444 on the target and instructs the victim computer to launch Trivial File Transfer Protocol (tfpt) and download a copy of the worm, called MSBLAST.EXE, from the infected system. (Tftp is included as part of the operating system in Windows 2000, Windows XP and Windows Server 2003.) The attacking system then instructs the newly infected computer to launch MSBLAST.EXE, and the victim computer becomes a new attacker. Blaster also wrote code to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft \Windows\CurrentVersion\Run Registry key, enabling itself to run every time the computer started.

Services Hardening

Services have been hardened and secured in Windows Vista in four ways: running services with Least Privilege, Service Isolation, Restricted Network Access, and Session 0 Isolation. I'll discuss each of these in detail.

Running with Least Privilege Many Windows services have previously run in the context of the Local System account-the most powerful account in Windows. The Local System account has user rights and privileges such as the ability to access almost any system object or another user's profile, impersonate users, open sensitive registry keys such as: HKLM\SECURITY, and to present the computer's credentials to remote servers. Since malware writers would love to have this level of access and control of Windows, any service running in the Local System Security context is sure to become a juicy target.

It turns out that although a number of Windows services have been configured to run under the Local System account, many of them need only a small subset of the privileges that are unique to the Local System account. Unfortunately Windows XP and previous versions of Windows operate in an "all or nothing" manner, which is to say they provide no mechanism to pick and choose needed privileges. Thus, many Windows services inevitably end up running with unnecessarily excessive security privileges.

Windows Vista Service Hardening addresses this issue by introducing the concept of least privilege to services configuration. Least privilege enables services to run with the minimum privileges necessary to function, instead of forcing them to run with all of the default privileges assigned to the account they use to log on.

For example, a service may need to be able to act as part of the operating system but doesn't need to be able to create a security token. With least privilege, you can remove the create-token privilege. As a result you lower the damage an attacker could do should that service become vulnerable to an exploit in the future. Developers can use command-line tools such as SC.exe (see Figure 2) or use programmatic methods to define and specify the privileges their particular service needs. Out of the box, Microsoft has applied least privilege to reduce the default privileges on all pre-installed Windows Vista services.

Figure 2** SC Command Options Define Windows Vista Service Privilages **(Click the image for a larger view)

Service Isolation In versions of Windows prior to Windows Vista, when a service needs to access a privileged object (such as a sensitive registry key or file), the services gain access via one of three methods: using the Local System account to access the object; decreasing the security on the registry key or file to enable a lower-privileged service account to gain access; or creating an account specifically for the service and allowing access to the objects only for that account.

While these approaches all work, there are basic problems with each. The first two are inherently risky and the last one introduces the headache of having to manage passwords manually on the new accounts.

Suppose, for example, an antivirus program installs a service that needs access to several sensitive system objects, such as the virus signature file and registry entries pertaining to the antivirus software. If the antivirus service was configured to use the Local System account or, for that matter, any of the other built-in security accounts, to access its objects, this would mean that if any other Windows service that used that account became infected by malware, that malware could potentially access and modify the antivirus signature files, alter registry settings that affect the way the antivirus software works, or simply shut down the antivirus service altogether. As a matter of fact, today's malware uses some of these exact techniques to keep itself hidden and functional.

Windows Vista addresses these security and manageability concerns with service isolation, which enables a service to reserve an object for its exclusive use by securing the resource-such as file or registry key access-with an access-control entry that contains a service Security ID (SID). Thus, the antivirus service described in our example could run in a low-privilege account but would still have access to sensitive signature files or registry keys. To enable this access, the antivirus service (running in this low-privileged account) would have a SID assigned to it by Windows Vista. After the SID was assigned, the antivirus program could then modify the access control lists (ACLs) of its file system and registry objects to give access exclusively to the antivirus service.

Here's another example. Back in 2003 the Welchia worm started taking advantage of an RPC vulnerability to write itself to %System%\Wins\Dllhost.exe. It also added keys to HKLM\SYSTEM\CurrentControlSet\Services in order to install its own services to the infected Windows system. Today, however, Windows Vista could thwart Welchia by restricting access to both locations to specific appropriate services and by using low-privilege accounts to grant those services access.

Restricted Network Access Windows Vista includes a new firewall that builds upon the capabilities delivered in the Windows XP SP2 firewall. Key new capabilities include outbound filtering and IPsec integration. The new firewall also integrates with Windows Vista Services Hardening to make it more difficult for malware running within an exploited Windows service to perform certain improper network activities.

In the Windows Vista firewall, Windows services are assigned network firewall policies that provide limitations and restrictions on service behavior. For example, a service like Plug and Play, which may never need to communicate over a network port, can be assigned a "no network access" restriction. With this restriction in place, an exploit designed to target that particular service could never reach the service via some network-based approach. Any attempt, inbound or outbound, by that restricted service to communicate would be blocked by the firewall. Other services that have legitimate needs to access a network can be configured to use only specific ports. Developers can take advantage of this capability to restrict their service's network access.

The network restrictions combine with Service Hardening to provide a robust defense against potential service based attacks, which is a big improvement over previous versions of Windows. Previously, there was no way for Windows to decide how, where, and which services were allowed to communicate via the network. However, by using the Windows Vista Firewall Network restrictions against the RPC service, we could prevent viruses such as Blaster, Sasser, or Welchia from using infected services to communicate with other machines.

Session 0 Isolation Fast User Switching in Windows XP accommodates simultaneously logged on users by putting each user in a different Windows session. Session 0 is created during startup, with more sessions added as required. Services have always run in Session 0 and, before Windows Vista, user applications have also been able to run in Session 0. However, there are risky security implications to running user applications and Windows services in the same session because services run at elevated privilege and are therefore targets for malicious software looking for a means to elevate its own privilege level.

Windows Vista addresses these security risks by reserving Session 0 exclusively for services, running applications in other sessions, and by making Session 0 noninteractive (which means that a service can't create a user interface, such as a dialog box or prompt, that an end user can access.) Because of these changes, Session 0 Isolation will impact application compatibility for anyone developing Windows services or drivers.

Summary

Windows Vista is the first complete Trustworthy Computing desktop operating system release from Microsoft and includes significant advancements that will go a long way towards protecting Windows users. Computer security is, of course, an evolving discipline and there is no doubt that malware writers are constantly looking, probing, and researching for new ways to exploit Windows. However, the new Service Hardening features in Windows Vista significantly raise the bar by enhancing default security settings and reducing the potential surface area for an attack. See microsoft.com/whdc/system/vista/Vista_Services.mspx for more information on these substantial improvements.

Wole Moses is a Microsoft Regional Windows Lead and an eight-year Microsoft veteran. Currently based in Istanbul, Turkey, Wole works with the largest emerging market customers in the Middle East and Africa to help them envision and design Microsoft-based solutions that optimize their IT infrastructure while maximizing security.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.