In-Depth

10 Vista Security Truths

There are a lot of misconceptions surrounding Windows Vista's security features. It's time to set the record straight.

Windows Vista definitely raises the bar against hackers and malicious exploits. Although it has already been successfully exploited to varying degrees, it's Microsoft's most secure operating system to date. With features like User Account Control (UAC), BitLocker, File and Registry Virtualization, Mandatory Integrity Controls and Internet Explorer (IE) Protected Mode, you can secure Vista at a system-wide or granular level.

There are many intricacies to Vista's security configurations that short marketing blurbs or misinformed bloggers can't fully explain. Consequently, there's some confusion surrounding Vista's security features and recommended configurations. Let's look into the top 10 misconceptions around Vista security and try to set the record straight.

1. The administrator account is disabled by default.
It's true that Vista will often disable the administrator account by default, but only if there are already other active defined members of the administrator group. It's more accurate to say that Vista tries to minimize the number of administrators by disabling the true administrator account if it detects other enabled admin accounts. On new Vista installs, the first new user account is added to the administrators group (just like in Windows XP and Windows 2000), but additional users aren't. Once the second administrator is added, Vista will disable the true administrator account.

It's important to note that the default disabled administrator account doesn't have a password. You should always set a complex password on that administrator account, even if it's disabled. If you're going to enable a disabled administrator account, set the password first -- then you can enable the account.

2. There are only four Mandatory Integrity Controls.
Mandatory Integrity Controls (MICs) are assigned, either explicitly or implicitly, to every user, object and process in Vista. Security principals of lower integrity can't modify objects of higher integrity, regardless of their NTFS permissions. There are four main MIC levels:

  • Low
  • Medium
  • High
  • System

Most users, including non-elevated members of the administrators group, run with Medium integrity. Here's how some other levels are assigned:

  • Kernel-level Windows files run with System integrity
  • User-level code, like Windows Explorer and Task Manager, runs with Medium integrity
  • The true administrator or an elevated member of the administrators group runs with High integrity
  • Internet Explorer (IE) in Protected Mode runs with Low integrity
  • If an object or resource doesn't have an explicitly assigned integrity level, then it has Medium integrity

MIC's primary role is to make it harder for normal users, programs and content downloaded in IE Protected Mode to modify system files. So even though a user might be a member of the administrators group, or even if a malicious program makes it through IE's initial security defenses, they'll have a harder time modifying Windows system files.

There are at least two other lesser-known MIC levels: Untrusted and Protected Process. Untrusted integrity is the lowest possible MIC level and is assigned to anonymous null connection sessions. Protected Process is the highest possible MIC level and is only used by the system when needed (see table for MIC levels).

Mandatory Integrity Controls (MICs) in Windows Vista
[Click on image for larger view.]

You might come across these MIC levels when exploring or troubleshooting, and you can be assured that malicious hackers will try to gain a Protected Process MIC level to make Windows compromises easier.

3. UAC decreases the number of administrators needed.
Vista requires that users obtain elevated rights and permissions to accomplish system tasks such as installing software, updating kernel drivers and so on. Vista also has new features that should require fewer administrative accounts, but UAC isn't one of them.

UAC specifically requires that users wishing to accomplish administrative tasks have membership in an elevated local group, like administrators or backup operators. UAC doesn't remove the need for administrative users -- it provides additional protection for users belonging to one of the elevated groups when performing non-administrative tasks like e-mail or Internet browsing.

When an elevated user (but not the true administrator) logs on, UAC assigns two access security tokens, known as a "split-token." The normal administrators' membership security token isn't available until the user elevates their access through the UAC consent interface. Otherwise, Vista takes the following action on that user's security token:

  • Vista removes the nine elevated privileges normally assigned to members of the administrators group
  • The user's MIC level downgrades from High to Medium
  • A deny-only SID is applied
  • UAC consent prompt may appear
  • File and registry virtualization applies

When the user elevates their session, those additional restrictions are removed. However, Vista still requires an administrator to accomplish many common system tasks. UAC protects both the system and user by removing the elevated rights and permissions until they're specifically needed. That way the administrative user isn't surfing the Internet and opening potentially malicious e-mail using their elevated security permissions.

Vista does decrease the number of required administrators in other ways. First, Vista has removed the administrative requirement to do many common system tasks, such as viewing or changing a time zone, configuring wireless networks, changing power management settings, creating and configuring a Virtual Private Network connection and installing critical Windows updates.

Second, Vista lets administrators define drivers, devices and ActiveX controls that non-admin users can install. So, for example, you can let your users install printers, network cards, USB devices and VPN software.

Third, for basic network re-configuration tasks, you can add non-admin users to the Network Configuration Operators group. Users in this group can release IP addresses, flush the DNS cache and accomplish other common network tasks. There are dozens of other ways to reduce the number of administrators you'll need. UAC just isn't one of them.

4. Only administrators can use UAC elevation.
By default, you can't input non-elevated accounts into the UAC consent dialog box. This means that if a user account doesn't belong to an elevated group, it can't be elevated by UAC. However, elevated status isn't the sole domain of administrators. Any account listed in the administrators, backup operators, network configuration operators and power users groups is considered elevated. You can use and list them as potential UAC credentials for appropriate elevation. You still can't use non-admin users for admin-only tasks, of course, but you can use those in elevated groups to perform other tasks.

For example, you may need users to run a program that requires slightly different permissions, but you don't want to give them admin credentials. You can create another user account with the appropriate permissions and place it in the power users group (which in Vista has no default privileges or permissions). When the user needs to "elevate" to run the application, they can use that new account in the power users group.

5. UAC is a security boundary.
UAC is not a security boundary or domain. Microsoft never intended for UAC to be a security boundary like a firewall, with defined security domains. UAC protects the user and system from certain types of malicious attacks when they're logged in with an elevated account. It's meant to be used as a crutch whenever the situation requires temporary admin access. With legacy applications, that's all too often.

UAC offers additional protection that previous versions of Windows did not. If you want real protection with promised security, the user shouldn't be logged in as an admin. It's that simple.

6. IE Protected Mode protects all downloaded content.
It's more accurate to say that IE Protected Mode provides additional protection to Internet content automatically downloaded during Web page rendering. The first exception here is that IE Protected Mode doesn't apply to all IE security zones. By default, IE Protected Mode doesn't apply to any Web site in the Trusted Sites zone. It's more than that, though.

IE Protected Mode gives you additional protection by running Internet Explorer with a Low MIC value. This also applies to most other IE objects, such as menu bars, browser helper objects and other add-ons. Content automatically downloaded by IE
Protected Mode is stored in Low-integrity file and registry areas, so it's unable to directly write to system files and the normal Medium-integrity user areas.

IE Protected Mode was specifically created to protect against "drive-by" downloads: those that happen without the user's expressed consent. If a user manually downloads a file or intentionally executes active content, it's marked with Medium integrity. Content approved by an elevated user (like installing an ActiveX control) runs with High integrity. Essentially, if the user is somehow tricked into downloading or executing content, IE Protected Mode doesn't apply.

7. All Windows executables are protected by Data Execution Prevention (DEP).
Iexplore.exe, the main IE executable, is excluded from default protection by Windows' DEP buffer overflow. Microsoft specifically chose not to enable DEP for Iexplore.exe because it caused problems for Java and many common browser plug-ins.

Because of this, even IE Protected Mode is still exposed to many common buffer overflow vulnerabilities. Once a buffer overflow exploit has been successful, though, the malicious payload will find it much harder to execute a meaningful hack. You can easily enable DEP for IE and keep it enabled if it doesn't cause problems.

8. File and registry virtualization blocks malicious file and registry writes.
File and registry virtualization does indeed block malicious writes, but only to a limited set of locations. By default, legacy application writes and reads to the following locations will be redirected to per-user virtualized areas (this is not a complete list):

  • \Program Files and subfolders
  • \Program Files (x86) on 64-bit systems
  • \Windows and all subfolders, including System32
  • \Users\%AllUsersProfile% \ProgramData
    (was \Documents and Settings\All Users in XP)
  • \Documents and Settings (symbolic link)
  • HKLM\Software

In addition to this limited list of write-blocked locations, the following objects are never virtualized:

  • Default Vista applications
  • Files with executable extensions, such as .EXE, .BAT, .VBS and .SCR. You can add additional file extension exceptions in HKLM\System\CurrentControlSet\Services\Luafv\Parameters
    \ExcludedExtensionsAdd
  • 64-bit applications and processes
  • Applications with a requested Execution Level directive in their executable manifest, like most Vista executables
  • Processes or applications running with administrative rights
  • Kernel mode applications
  • Operations not originating from an interactive log-in session, like file sharing
  • Applications modifying a registry key marked with the Don't_Virtualize registry flag

Regarding the last point, any key under HKLM\Software has three new registry flags you can reveal through Reg.exe:

  • Don't_Virtualize
  • Don't_Silent_Fail
  • Recurse_Flag

Any key marked as Don't_Virtualize won't participate in registry virtualization. You can use Reg.exe to set and reveal registry flags.

9. Windows Resource Protection (WRP) protects system files just like Windows File Protection (WFP) used to.
Vista's new WRP is often touted as a plug-in replacement for WFP. WFP was introduced in Windows 2000, and a similar System File Protection (SFP) was introduced earlier in Windows Millennium Edition. Both are similar to WRP, but vary tremendously in how they work and in what they do.

WFP only protects files. WRP protects critical files, folders and registry keys. WFP and SFP monitor changes to protected system files. If the change is unauthorized, it replaces the modified file with a legitimate backup copy of the original. Often the only warning that a WFP event took place was a quick alert message or an event written to the event log.

WRP tries harder to prevent changes to system resources in the first place. Administrators can't modify system resources. By default, only the Windows Trusted Installer security principal can make changes using the Windows Module Installer service (which is used by Windows Installer, Hotfix.exe and Update.exe).

One huge caveat here is that if an administrator or elevated user takes full ownership of a protected resource and gives themselves full control permissions, they'll be able to modify or even delete the protected resource. Unlike WFP and SFP, WRP won't automatically replace protected files with a legitimate backup copy. WRP only replaces system files critical to restarting Windows, and even then only during a reboot.

To have WRP replace all modified protected resources (which isn't a bad idea during a troubleshooting scenario), run the following command: sfc /scan now. If you need a protected file's original copy, you may have to supply the Vista installation files.

10. Windows Firewall doesn't block outbound connections by default.
Among other things, Vista added outbound blocking to Windows Firewall. Critics are quick to point out that Vista doesn't block any outbound connections by default, but this just isn't true. Vista blocks outbound traffic, by default, in several instances.

Vista blocks unnecessary or undesirable traffic originating from many default services. There are 82 default filters that prevent 34 services from outbound communication, other than through a very narrow set of defined ports and IP ranges. For instance, the P2P Grouping service is denied outbound access on any port other than its default of 3587. There are many other default outbound blocks, including those for Windows Defender, Session Isolation and SNMP Trap traffic.

Unfortunately, there's no graphical interface to configure or view the default filters. For read-only purposes, the default filters are listed in the registry at:

HKLM\System\CurrentControlSet\Services\SharedAccess\Parameters
\FirewallPolicy\RestrictedServices\static\system

Currently, the COM scripting tools are the main management interface.

Windows Vista has more default protection than most people realize. You need to look past the marketing blurbs and various blogs. Only with the proper configuration can you lock down Vista to the extent that you require.

comments powered by Disqus
Upcoming Events

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.