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:
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).
[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.