P1: GSB/FFX P2: GSB/FFX QC: IML/FFX T1: IML
WL040C-63 WL040/Bidgoli-Vol III-Ch-64 June 23, 2003 16:45 Char Count= 0
800 WINDOWS2000 SECURITYby default. Anyone whose system was infected by Code
Red, Nimda, or another worm will appreciate the dangers
of running a vulnerability-ridden Web server, namely, the
Internet Information Server (IIS), by default. In other re-
spects, W2K is more secure than NT was by default. When
unprivileged access to Active Directory objects is neces-
sary, for example, access is by default granted to Authen-
ticated Users rather than the dangerous Everyone group.
The point here is that W2K may be somewhat more secure
than NT out of the box, but leaving W2K settings as they
are is a huge mistake if security is a consideration. W2K
systems need significant work to run securely.Major Types of Vulnerabilities
W2K has had more than its share of security-related
vulnerabilities. One of the most significant is a weak-
ness in the way password representations for each ac-
count are created. The encryption process produces pass-
word representations that, by default, are relatively easy
to crack using dictionary-based cracking techniques. If
Service Pack (SP) 1 or higher is installed, the syskey
utility is automatically installed. syskey adds a random,
initial 128-bit encryption step before password repre-
sentations are created, making password cracking more
difficult.
Another significant set of vulnerabilities concerns sus-
ceptibility of W2K systems to denial of service (DoS)
attacks. Programs for many W2K services are not particu-
larly well written. An attacker may send input to these ser-
vices that contains out-of-range parameters or that exceed
memory limitations. The result is often DoS—either the
programs or the W2K system itself—will crash. The W2K
telnet server, for example, has a bug that will cause it to
crash if certain types of input are sent to it. Similarly, mas-
sive Simple Network Management Protocol (SNMP) input
may cause the receiving system to go into a buffer overflow
condition in which there is too much input for available
memory. This problem will normally cause a W2K system
to crash, but if the excessive input is specially crafted, it
is possible to execute rogue commands and programs on
a system.
Some of the services that run in W2K systems pose
much higher levels of risk than others. W2K Terminal Ser-
vices, for example, provide a convenient way for users to
connect remotely to other systems if these services are not
properly configured, protected, and patched. The same
is true for the W2K telnet server, the IIS Admin Service,
SNMP, and many others.
Another vulnerability has been briefly mentioned ear-
lier in this chapter. The default Administrator account is
an attractive target for attackers in that by default it does
not lock after an excessive number of unsuccessful lo-
gons. Additionally, this is a well-known account—one with
a well-known name. Furthermore, being able to break
into this account provides superuser-level privileges to
attackers. Lamentably, many successful attacks on W2K
are attacks in which perpetrators have broken into the
Administrator account, which may not even have had a
password.
Other major types of vulnerabilities in W2K that have
been identified include the following:Bugs that result in privilege escalation; the conse-
quences are particularly severe if the attained privilege
level is Administrator
Flaws that allow impersonation of other users (e.g., by
allowing someone to run a process in another user’s con-
tainer)
Ability to exceed allocated disk quotas (e.g., by repeat-
edly appending content with a certain number of bytes
to files)
NetBIOS-related vulnerabilities (in Mixed Mode; this
layer of networking is beset with many security-related
problems, including providing a wealth of information
about systems, users, and current sessions to potential
attackers)
Bugs that can give attackers unauthorized access to Ac-
tive Directory objects
Poorly protected dial-in connections that require only
a “normal” password for access instead of something
stronger, such as smart card or biometric authentication
(unauthorized dial-in access is one of the greater threats
in any operating system, W2K included)Microsoft has fixed most of the vulnerabilities men-
tioned here, as well as others that have been posted to
newsgroups such as bugtraq. Microsoft generally initially
produces a hot fix to repair a vulnerability or sometimes
a set of vulnerabilities. Sometime later Microsoft releases
either a set of bundled hot fixes or an SP that incorporates
previously released hot fixes.
Now that we have explored the major types of vulnera-
bilities in W2K, let’s turn to another, related consideration,
namely, how secure W2K systems can be.How Secure Can You Make W2K Systems?
W2K has numerous features that can substantially boost
its security. As mentioned previously in this chapter, how-
ever, you’ll have to make a number of changes to W2K
if you want it to run securely. W2K has great security po-
tential, but to achieve that potential requires considerable
effort. The most important consideration is achieving a
baseline level of security.Baseline Security Measures
Establishing at least a baseline level of security is essential
if W2K servers and workstations are going to withstand
even the most basic kinds of attacks. Baseline security re-
quires implementing the most fundamental steps in secur-
ing a system or application, not implementing a complete
(more perfect) set of measures. The intention is to make a
system “just secure enough.” Implementing the following
measures in W2K systems will produce a baseline level of
security:Install W2K From Trusted Media—A
Vendor-Provided CD
Ensure that your system’s hard drive consists of a mini-
mum of two partitions, C: and D: Use C: as the installation
drive; this partition will contain critical system directo-
ries and files. Do not set up user shares to this partition.
In workstations and member servers use D: to hold other