By Thomas C Greene
Published Thursday 2nd September 2004 10:48 GMT
We evaluated the security features of Windows XP SP2 on a test
machine, following a clean install of XP Pro with no configuration
changes and no third-party software or drivers installed. We
installed XP with the NTFS file system, choosing all of the factory
defaults, then patched it with each recommended security update
including SP-1 (required), before installing SP2.
While we found that there are indeed a few minor improvements worthy
of acknowledgment, in particular, some rather low-level improvements
that don't show to the admin or user, overall, SP2 did little to
improve our system's practical security, leaving too many services
and networking components enabled, bungling permissions, leaving IE
and OE vulnerable to malicious scripts, and installing a packet
filter that lacks a capacity for egress filtering.
The new Security Center utility with its frequent Security Alert
popups will certainly give users the impression that SP2 is a
security-oriented package, as Microsoft's PR boilerplate promises.
However, The Security Center does little beyond warning users that
the firewall is disabled, that automatic updating is disabled, or
that antivirus software has not been installed. It may look
impressive, but the SP2 package fails to provide several of the most
important, basic modifications required to run Windows safely on an
Internet-connected machine.
Windows Services
Microsoft has long enabled a number of services related to networking
by default, most of which are unnecessary, even dangerous, on
Internet-connected machines, and all of which a competent admin
should know well enough to enable as necessary. Turning them on by
default is a minor inconvenience to admins, who need to disable what
they don't need (but usually know how to go about it), and a major
source of trouble for home users, who can't be expected to know what
services they do and don't need, or how to harden their systems by
disabling superfluous ones.
SP2 does disable a few Windows services related to networking that
have not previously been disabled by default, which certainly is an
improvement. Unfortunately, too many services remain. And home users
are given short shrift.
According to netstat, our machine had the following services
listening on the Internet by default:
DCE endpoint resolution (epmap), port 135. This is basically the
UNIX/BSD/Linux portmap daemon, and unnecessary on home machines.
NetBIOS name service, port 137. This is the WINS (Windows Internet
Naming Service) server for a NetBIOS network, and unnecessary on home
machines.
NetBIOS datagram service, port 138. This is used by the SMB (Server
Message Block) browser service, and is unnecessary on home machines.
Microsoft-ds (Server Message Block), port 445. SMB can run directly
over TCP/IP, without NetBT by using this service, which is
unnecessary on home machines.
NetBIOS Session, port 139. This is used for Windows File and Printer
Sharing, unnecessary on most home machines, and extremely dangerous
on any machine connected to the Internet unless the owner knows how
to run it securely.
Error Reporting is on by default. However, there is no reason why a
machine should phone home every time it encounters an error. This is
better left disabled.
Automatic Update is off by default. Microsoft would very much like
everyone to enable it, and now urges users to do so every time
Windows Update is run manually; but it is never a good idea to let a
third party decide what software should be installed on your machine,
or when. This service should remain off, and users should update
Windows manually, though regularly, paying attention to the various
update options and their relevance to one's system.
Looking alphabetically at the Services dialog, we encountered the
following settings (Note: "manual" means that the service will be
started if invoked by a user, an application, or another service,
while "automatic" means that it will be started at boot time whether
it's needed or not).
ClipBook (used to store information, cut / paste, and share it among
computers) disabled. About time.
DCOM Server Process Launcher, automatic. The process launcher implies
that DCOM is enabled, as indeed it is (more below).
DHCP Client, automatic. Unnecessary on most home machines. Should be
disabled by default.
DNS Client, automatic. Unnecessary on most home machines. Should be
disabled by default.
NetMeeting Remote Desktop Sharing, manual. Unnecessary on most home
machines. Should be disabled by default.
Network DDE, disabled. About time.
Network DDE DSDM, disabled. About time.
Remote Access Connection Manager, manual. Unnecessary on most home
machines. Should be disabled by default.
Remote Desktop Help Session Manager, manual. Unnecessary on most home
machines. Should be disabled by default.
Remote Procedure Call (RPC), automatic. This is one of Microsoft's
greatest security holes. RPC enables one machine to execute code
remotely on another. On UBIX/BSD/Linux, it can be disabled safely. On
Windows, it cannot be disabled, as MS has made a plethora of
necessary services dependent on it. It's a huge security hole that
simply cannot be avoided. It must be blocked by a firewall.
Remote Registry, automatic (allows remote users to make Registry
changes). Unnecessary and dangerous on most home machines. Should be
disabled by default, and enabled only as needed.
Routing and Remote Access, disabled. About time.
Secondary Logon, automatic (enables starting processes under
alternate credentials). Unnecessary on most home machines. Should be
disabled by default.
SSDP Discovery Service (UPnP discovery), manual. Unnecessary on most
home machines. Should be disabled by default.
TCP/IP NetBIOS Helper, automatic (enables support for NetBIOS over
TCP/IP (NetBT) service and NetBIOS name resolution). Unnecessary on
most home machines. Should be disabled by default.
Telnet, manual. Unnecessary on most home machines and company
workstations. Extremely insecure. Should be disabled by default.
Those foolish enough to use it can enable it.
Universal Plug and Play Device Host, manual. Unnecessary on most home
machines. Should be disabled by default.
WebClient, automatic (enables Windows-based programs to create,
access, and modify Internet-based files). Unnecessary on most home
machines. Should be disabled by default.
Additionally, DCOM (Distributed COM) is enabled by default. It is
unnecessary on most home machines, and should be disabled unless
needed. It's the component that the Blaster worm exploited to get at
RPC.
Networking components
In addition to services, Windows also installs a number of networking
components that are unnecessary on the vast majority of machines,
especially home machines. SP2 has done nothing to change this.
Most home users don't know that TCP/IP is the only networking
component needed for an Internet connection to work. Nevertheless,
Client for Microsoft Networks, File and Print Sharing, and the QoS
Packet Scheduler are all installed by default, and SP2 does little to
address these issues - although, presumably, file and print sharing
are limited to machines on the same subnet. At least we hope so.
Furthermore, NetBIOS over TCP/IP is enabled, and that is never a good
thing on home machines.
Most absurdly, Remote Assistance ("allow script kiddies to control
this computer remotely?") is enabled by default, as is Remote
Registry ("allow script kiddies to modify your Registry remotely?").
The Remote Desktop "feature" was off, thankfully.
Windows Firewall
The new "Windows Firewall" packet filter is turned on by default,
finally. However, an exception for Remote Assistance connections is
enabled, which is preposterous, although file and printer sharing,
and UPnP, are blocked by the firewall as they should be. The
putatively new "Windows Firewall" is actually not much different from
its predecessor, the "Internet Connection Firewall", with all its
weaknesses. Indeed, the only improvements are that the Security
Center pops up a warning if the firewall is turned off, and the
firewall alerts users to software willing to accept an outside
connection.
Most importantly, the new packet filter, like the old, is incapable
of egress filtering, although there were numerous press reports
predicting such a capacity before its release, perhaps due to
aggressive blogging by overeager MS shills. This particular omission
is one of the greatest disappointments in SP2.
Because of the vast amount of malware, spyware, and adware plaguing
Windows, it is crucial that a packet filter warn users whenever a
program attempts to send data to the Internet. SP2 is of no value in
this regard. It does, however, warn users of third-party clients that
will accept incoming connections, and offers users an opportunity to
block or enable them individually.
Nevertheless, Windows users must monitor outgoing connections, and
must therefore continue to deploy a third-party firewall or packet
filter capable of egress filtering in order to run Windows XP safely.
Policies
Default security policies with SP2 are basically sensible. However,
there are exceptions. For example, to prevent NetBIOS null sessions,
which are extremely dangerous, the Security Accounts Manager (SAM)
should be configured to reject them. SP2 has done half the work. In
the Network Access policy settings, the option "Do not allow
anonymous enumeration of SAM accounts" is enabled, as it should be.
Unfortunately, "Do not allow anonymous enumeration of SAM accounts
and shares" is disabled, although it should be enabled. This arcane
setting is not something that a home user should even have to know
about, much less play with.
Permissions
If making Windows so dependent on RPC is one of Microsoft's greatest
security stuff-ups, allowing Windows XP to be set up as a single user
system is the most spectacular of all time.
Windows XP is the first genuine multiuser Windows system marketed to
home users, yet Microsoft has stubbornly declined to enforce, or even
encourage, its inherent security benefits. SP2 does nothing to
improve the situation.
The chief weakness of a single-user system is that whoever sits at
the keyboard is the administrator, or root in UNIX parlance, capable
of taking any action he pleases. He can install programs and delete
files or wipe out whole directories; he can alter system settings
with the same privileges as the owner.
This is bad in two ways. First, anyone with physical access to the
machine can reconfigure it and possibly destroy important files,
whether intentionally or accidentally. Second, when everyone is
automatically an administrator, any malware that a user picks up will
run with the administrator's level of access - that is, with
unlimited privileges.
Establishing less-privileged user accounts, even for the machine's
owner, is the single most productive step one can take towards
reducing the impact of malware. WinXP makes this possible, but,
unfortunately, not necessary.
The level of system access that a user is granted affects the
potential of malware, and vectors such as browsers, -mail, and IM
clients, to deliver and execute malicious code. It is generally,
though not universally, true that we can limit the impact of
malicious code by limiting the user's access to the system.
Generally, an unprivileged user will run unprivileged malware. This
is why even the sole user of a system should always work from a
limited-access account, except when performing administrative chores.
UNIX-compatible systems enforce this worthwhile discipline strictly;
Microsoft still does not even encourage it.
Internet Explorer
Windows attempts to control code execution with so-called "security
zones" for online clients like Internet Explorer and Outlook Express.
Since it's likely that everyone using the computer is an
administrator, the idea here is to categorize Web content and
software providers and their products as 'trusted' or 'untrusted.'
Thus the user decides whether or not to allow provider X or Web site
Y to run code on his machine, based on pure guesswork and vague
impressions.
For example, Internet Explorer allows a user to choose websites from
which potentially dangerous content like JavaScript and ActiveX
controls will be trusted. Content from 'untrusted' websites can be
assigned reduced privileges.
This approach is wrongheaded from the start. Users should not be
expected to know whose content can be trusted and whose can't, or
what code is safe to run and what isn't. And even when a user guesses
right, malware can, and often does, execute in the wrong zone, as we
have seen many times.
The default security settings for Internet Explorer are hardly
changed from the risky and confusing ones Microsoft has been urging
on users for years. Here's what we found:
ActiveX Controls: run and script functions are enabled by default if
the control is "marked as safe". Downloading signed ActiveX Controls
is enabled (no prompt), and unsigned ones are disabled (no prompt).
Binary and script functions are enabled. This is far too confusing:
ActiveX should have a simple on/off toggle, and should be kept off
unless needed for something useful like Windows Update.
"Access data sources across domains" is disabled, and enabled for
trusted sites. (We would leave it disabled.)
MetaRefresh is enabled. (We would leave it disabled.)
"Scripting of browser controls" is disabled for the Internet zone,
and enabled for trusted sites. (We would leave it disabled.)
"Script initiated windows without size or position constraints" are
disabled, but enabled for trusted sites. (We would leave it
disabled.)
Drag & drop / copy & paste are enabled. (We would leave it disabled.)
"Installation of desktop items" gets a prompt, and is enabled for
trusted sites. (We would require a prompt at all sites.)
"Launching programs and files in an IFRAME" gets a prompt, and is
enabled for trusted sites. Most users probably have no idea what an
IFRAME is. (We would leave it disabled.)
"Navigate sub-frames across domains" is enabled. (We would leave it
disabled.)
"Open files based on content, not file extension" is enabled. (This
is good.)
The pop-up blocker is enabled, but disabled for trusted sites. (We
would leave it enabled.)
Userdata persistence is enabled. (We would leave it disabled.)
"Web sites in less privileged Web content zone can navigate into this
zone" is enabled. (We would leave it disabled.)
JavaScript is enabled. (We would leave it disabled.)
"Paste operations via script" is enabled. (We would leave it
disabled.)
Scripting of Java applets is enabled. (We would leave it disabled.)
In the Advanced dialog, things are fairly sensible overall, with a
couple of exceptions:
"Check for server certificate revocation" is not selected. (We would
leave it enabled.)
"Do not save encrypted pages to disk" is not selected. (We would
leave it enabled.)
"Empty Temporary Internet Files folder when browser is closed" is not
selected. (We would leave it enabled.)
Enable Profile Assistant is selected. (We would leave it disabled.)
Outlook Express
The chief security problem with OE has been that it defaults to
viewing HTML automatically. Plain text should be the default, to cut
down on Web bugs and malicious scripts. However, we find that little
has changed with SP2:
"Automatically log on to Windows Messenger" is selected. Messenger
should not be enabled on most company workstations, although at least
now there is an option.
"Notify for each read receipt" is set. It would be better to turn
receipts off, to avoid accidentally confirming one's e-mail address
to spammers.
The send-format defaults to HTML, a great waste of bandwidth, and an
irritant to people, like myself, who force their -mail to display as
plain text.
The Outlook Express security settings are basically sensible.
Potentially dangerous file attachments can be blocked from being
saved or opened, and are in fact blocked by default. This feature is
good, so long as the mail client knows what to look for. It can
probably be fooled a number of ways, and certainly is no substitute
for antivirus software.
"Block images and other external content in HTML email" is selected.
This helps cut down on Web bugs and inadvertent spam confirmations.
However, an HTML off-switch forcing all email to display as plain
text would be a good deal more effective at this, and thwart
malicious scripts to boot.
Conclusions
Microsoft declined many opportunities to harden Windows XP in a
meaningful way; that is, by disabling unnecessary services, enforcing
the multiuser environment, setting sensible user and file
permissions, and installing a fully-functional packet filter. The
roster of missing security utilities, such as PGP, SSH, a proper wipe
utility, etc., is immense.
The home user is the one most in need of good security configurations
and tools, yet the one least served by SP2. Windows may be easy to
use, but it is extremely complicated and difficult to administer,
especially for security, with a tremendous number of hidden functions
and many complex configuration interfaces. It should be left to the
professional admin to enable services and understand their
dependencies, not left to the home user to figure out which ones are
risky, and which ones can safely be disabled.
The Security Center is a good idea, but as it's been implemented,
it's little more than a gimmick that will lead to a false sense of
security. Our test system remained vulnerable to a vast host of
online threats, especially those involving user interaction. And
that's a pity, because a Windows system can be hardened significantly
so that even careless users will have trouble infecting it - so long
as one knows how to go about it. The idea behind SP2 was to apply the
kind of security know-how that users aren't expected to have via a
major system update, so that people can venture onto the Internet
without worry.
Unfortunately, Windows remains a quite dangerous system to connect to
the Internet, and users are still very much on their own in terms of
security solutions. ®
Thomas C Greene is the author of Computer Security for the Home and
Small Office, a comprehensive guide to system hardening, malware
protection, online anonymity, encryption, and data hygiene for
Windows and Linux.
---
* Origin: [adminz] tech, security, support (192.168.0.2)
generated by msg2page 0.06 on Jul 21, 2006 at 19:04:06
search: