In the late 1980s, Microsoft and IBM were jointly developing, marketing, and selling OS/2. When the venture disintegrated, Microsoft continued development of a 32-bit operating system, and Windows NT was the result.

Windows NT supports peer-to-peer networking between client workstations, and client-server communications between Windows NT Workstation and Windows NT Server systems. Windows NT was the first 32-bit Microsoft operating environment, and it provides a powerful network server for Windows 3.x clients. A few years ago, as Microsoft introduced 32-bit software for low-end systems via Win32S (an adjunct to Windows) and Windows 95, its commitment to Windows NT fell into doubt. But the power and stability of Windows NT made it a very popular product and it is a flagship product of Microsoft today.

The backing of Microsoft and the prevalence of Windows 3.x/95 (and the impending Windows 98) on the desktop have combined to make Windows NT a formidable entry in the NOS marketplace. NT has become popular because of its relatively easy installation and administration, intuitive and familiar graphical user interface, and presumed stability. On the LAN, once-dominant Novell NetWare is rapidly losing market share, mostly to Windows NT. And while most of the servers on the Internet have been and still are Unix-based, an increasing number of Web, ftp, Domain Name System (DNS), DHCP, and other servers are running on Windows NT platforms.

Security Mechanisms

Like any operating system designed for servers and/or the Internet, Windows NT has built-in security mechanisms to authenticate users, and to protect network and system resources. According to Microsoft, "Windows NT Server was designed from the ground up with a sound, integrated, and extensible security model. It has been certified at the C2 level by the U.S. government and the E3 level by the U.K. government and has a robust security model that enforces granular access control on all resources, as well as requiring user authentication through passwords."

C2-level security is a widely touted feature of Windows NT, but what is it? The Department of Defense's National Computer Security Center specifies a spectrum of security protections in the "Orange Book," more formally known as the Trusted Computer System Evaluation Criteria (TCSEC). The Orange Book defines the criteria by which network and host operating systems are evaluated from a security perspective. But C2 is, in fact, about the lowest security level defined in TCSEC and is oriented toward standalone systems rather than networked computers.

Security Requirements

Requirements for an operating system providing C2-level security (and the relevant Windows NT mechanisms) include:

Object security: Any data that need to be shared or protected are stored as objects. Examples of objects include windows, menus, processes, user data, and files. As an example of object security, Windows NT protects memory so that information cannot be read after memory blocks are unallocated by a process. All NT objects can be assigned varying levels of access protection.

Identification and authentication: In Windows NT, identification and authentication are achieved by use of logon names and passwords (described in more detail later). Each user has a Security Identifier (SID) tied to a network domain; although a user may operate in more than one domain, each domain will have a SID for this user. In addition, a SID can refer to a group rather than an individual. Each domain maintains a Security Account Manager (SAM) database containing all SIDs for that domain.

Access control: The owner of a resource (such as a file or directory) must be able to control access to the resource. Windows NT accomplishes this with Access Control Lists (ACLs) for objects. Each object's security descriptor contains the owner's SID, a Discretionary ACL (DACL), and a System ACL (SACL). The owner sets the DACL entries. For example, the owner of a directory ("folder" in Windows NT vernacular) can specify what access other users have to this directory, and to files within the directory. The owner also can change the ownership of files and/or directories to other SIDs (so that ownership can be transferred to any of the owner's groups). The SACL specifies which operations on the object are audited by the operating system.

Auditing: Network, system, and user actions must be audited so that the system administrators can detect and track security-related events. Access to the audit data is limited to authorized administrators to prevent an attacker from "covering their tracks." Windows NT auditing is controlled by the SACL.

Password Security

The primary Windows NT security feature that keeps unauthorized users out of the system and binds legitimate users to resources for which they are authorized is the Network Logon Security mechanism. When a user logs on to an NT server, the server creates an access token, which is composed of two parts. The first part is a User Rights mask, indicating the network resources to which the user has access. The second part is the set of SIDs associated with any local or network user or group to which this user is a member. The access token also is assigned to any child processes spawned by this user.

When users log on to an NT server, they must supply a username, password, and domain name. Passwords may be up to 14 characters in length and are case-sensitive. All user-related authentication information, such as usernames and passwords, is stored in the SAM part of the NT registry on the server. The SAM does not contain the password nor even an encrypted version of the password, but instead stores a hash value created from the password.

A hash function is a mathematical operation that takes an arbitrary input string and creates a (usually) fixed-length hash value; it essentially is impossible to derive the input string from the hash value. The SAM stores two 16-byte hash values, one using the LAN Manager scheme and one that is particular to Windows NT. LAN Manager uses a 14-byte (112-bit) password to form two 56-bit values, each of which is used to encrypt a fixed (known) 8-byte number using the industry-standard DES; the two DES values are concatenated to form a 16-byte hash value. Native NT uses the Internet-standard Message Digest 4 (MD4) hashing algorithm to generate a 16-byte hash of the password.

The NT Scheme

When logging on across a network, user passwords are never exchanged between the workstation and server; this prevents network "sniffing" attacks. Instead, NT uses a challenge/response scheme (Figure 1). When the user logs on to the client system, the hash value of the password is calculated. When the client connects to a server, the username is sent across the network in plaintext (1). The server generates an 8-byte random value that is sent back to the client (2). The client encrypts the random value with DES, using the hash value of the password to generate the DES key (3c), and returns the encrypted value back to the server (4). Using the password information in its password database, the server performs the same calculation (3s). A match results in a successful logon (5). (This explanation is a slightly simplified version of what really happens; there are actually three DES keys generated from the password hash value so that the 8-byte challenge stimulates a 24-byte response.)

Finally, it is worth noting that despite the best measures, password-based authentication schemes are weak, primarily because users generally choose bad passwords, write them down, share them with other users, or have other bad habits. Furthermore, it only takes a single password to give an attacker the entry needed to get into a system. Thus, high-security environments augment passwords (a "what you know" scheme) with other security mechanisms such as smart cards ("what you have") or fingerprint scanners ("what you are").

Security processes at any facility must combine technology with policies guiding behavior, and it is generally the latter that is harder to implement. Even the best security features of an operating system can be defeated by users, which is why "what you know" schemes are so vulnerable to attack.

Other Security Features

An increasing number of companies support remote access to their networks via the dial-up network. In Windows NT, RAS provides remote node access, meaning that the calling host appears to be directly attached to the network. RAS supports the use of IP, IPX, and NetBEUI. RAS client software is available for Windows NT Workstation, Windows 95, Windows for Workgroups, and Windows 3.1.

RAS supports a variety of different products for remote-user authentication. Initially, CHAP is used by the RAS server to determine the most secure authentication protocol supported by both the client and the server. Options include:

NT client/RAS server: If the client system is a Windows system, DES will be employed.

NT client/non-RAS server: If a RAS client is communicating with a non-RAS server, the Message Digest 5 (MD5) hash function may be used. MD5 is commonly employed with PPP.

NT client/Shiva server or Shiva client/ RAS server: Shiva's (Bedford, MA) LAN Rover is one of the most common remote node access devices in use today. Shiva clients and servers employ the Shiva PAP (SPAP) for authentication. SPAP also can be used in the NT environment between a Windows NT client and Shiva LAN Rover or between a Shiva client and a Windows NT remote access server.

None of the above: PAP sends unencrypted passwords between the client and server, and is the least secure password scheme. Nevertheless, it is supported by RAS because some clients may not be able to use any other method. The system administrator can disable the use of PAP, however, ensuring at least a moderate level of password security. In fact, it is recommended that PAP be disabled unless absolutely required because it is a security liability.

Finally, Windows NT security mechanisms are available for third-party applications via Microsoft's Security Support Provider Interface (SSPI). SSPI is a common API for obtaining such security services as authentication, message integrity, message privacy, and security quality of service for any distributed application. Application protocol designers can use this program interface to obtain a variety of security services without modification to the application protocol itself.

Security Vulnerabilities

All Internet servers, regardless of the underlying operating system, run the TCP/IP suite and are, therefore, susceptible to the vulnerabilities of those protocols. Intrusions and denial-of-service attacks using IP address spoofing, SMTP address spoofing, and other schemes are possible against almost any TCP/IP-based system, including those employing Windows NT. Therefore, the generic schemes that can be employed to protect TCP/IP servers (for example, proxy servers) can be used to protect an NT server running TCP/IP.

However, most servers on the Internet run over the Unix operating system and Unix adds a host of additional vulnerabilities, such as buffer overflow problems, the documented vulnerabilities of sendmail, and numerous other obscure and not-so-obscure Unix services. Windows NT usually is not thought to be susceptible to these flaws and often is considered a more secure operating system. In addition, NT's graphical interface makes it easier to administer than Unix's somewhat cryptic command line interface. The truth is, however, that NT versions of many of the Unix services are, indeed, prone to the same vulnerabilities, such as some versions of sendmail for NT.

Although NT is relatively secure, there are security weaknesses and vulnerabilities in all operating systems. Many weaknesses are caused by actual flaws in the protections, while others are caused by errors in the coding. As an example of the former, Windows NT security mechanisms are constrained somewhat to maintain backward compatibility with LAN Manager. NT, then, is susceptible to a number of the same weaknesses associated with NetBIOS in LAN Manager, including the relatively weak cryptographic protection scheme, small cryptographic key sizes, and a vulnerable password system. As an example of the latter, the beta release of NT 4.0 contained an error that allowed unauthorized users to obtain full control of network files and directories. This error almost found its way into the first general release. It is illustrative to describe a few of the other reported NT security vulnerabilities.

The Everyone Group

In early 1997, for example, NTsecurity.com (Columbus, OH) reported a bug that would allow any user anywhere to log on to an NT server. This flaw became known as the RedButton Bug because of the program written to exploit the flaw.

To log on to a remote NT system, a user needs either a username and password or can use the Guest account. Windows NT also defines a group called Everyone. Most NT system administrators assume that this group automatically includes all registered users at a given server or within a given domain. The definition of the Everyone group is not explicitly stated in any NT documentation, however. According to NTsecurity.com's Web site, the "...Everyone group includes any user from anywhere. Everyone is everyone." This means that any user can remotely log on to an NT server and be granted the same access rights and privileges as those assigned to the Everyone group. This would allow anyone to log on without a username and password, whether the Guest account is enabled or disabled, and access resources.

NTsecurity.com developed a program called RedButton to demonstrate the flaw. The proposed solution is that system managers should define a new group (NTsecurity.com suggests EveryUser) that explicitly includes all legitimate users for this NT domain; this probably is what the system administrator wanted anyway and it ensures that the administrator explicitly knows about the usernames on the system. By replacing the Everyone group with the new group name in all registry keys and file system rights and permissions, the RedButton attack will be blocked. NTsecurity.com's Web site contains a complete description of the problem, a frequently asked questions list, the proposed solution, and a utility to implement the solution.

Microsoft did not publicize the flaw and announce a patch until some time after it was announced by NTsecurity.com. In addition, Microsoft downplayed the significance of the flaw by stating that it was not a big problem because it only allowed an intruder to view portions of the registry and log files, but not modify them. The company quickly followed this up by posting information about its response and proposed solutions on its Web site. Microsoft announced that enhancements to Windows NT to block this type of anonymous attack would be built into subsequent NT 4.0 service packs and NT 5.0.

OUT-OF-BAND BUG

In May 1997, another problem surfaced that affected Windows for Workgroups (Windows 3.11), Windows 95, and Windows NT (3.51 and 4.0). The Out-of-Band (OOB) Bug can be used to launch a denial-of-service attack against any Windows system listening on TCP port 139, which is one of the ports that is used by NetBIOS. Turning port 139 off, however, is not sufficient to protect a server from this problem because it is also known to affect port 53 (DNS) and port 80 (HTTP), and might affect other ports as well.

With an OOB Bug attack, an attacker establishes a TCP connection to a legitimate service on an NT server. The attacker then sends a TCP segment containing an invalid sequence number, invalid window size, and the Urgent (URG), Finish (FIN), and Reset (RST) flags all set (an invalid combination); this is the so-called OOB data. The operating system doesn't know how to handle this OOB information, so it becomes confused and unusual things happen. In Windows NT, in particular, the so-called Blue Screen of Death (BSOD) appears and the server freezes. Rebooting is the only way to get the system back on-line.

This particular attack is insidious because it appears to have few protections. Proxy servers might be secure, but some firewalls will pass the OOB data. Microsoft has supplied patches to Windows 95 and Windows NT, but critics say that the company knew about the problem for weeks before supplying any such patches. More information about the OOB Bug can be found at The NT Shop's Web site, www.ntsecurity.net/security/oob.htm. The WinNuke Testing Ground Web page at pobox.leidenuniv.nl/~ewit/winnuke/ also describes the problem and supplies a program called WinNuke so that you can test your own site's susceptibility to the attack.

BE AN ADMINISTRATOR

In July 1997, a program called getadmin.exe made the rounds. It allows anyone to add users to the Administrators group. No special permissions are required to execute the program, and it can be run through a telnet session. It appears that a wide variety of domains and accounts could be compromised with this program. Microsoft rapidly supplied a hot fix for the problem, but the vulnerability persisted until another hot fix came out in late August. More information about this exploit can be found at the NTsecurity.com Web site.

Perhaps more seriously, an e-mail to the Windows NT BugTraq mailing list in October 1997 suggested that there were basic flaws in the Windows NT kernel and in the way in which system calls were handled. The discussion went on to state that fixing individual problems wasn't enough; buggy code or deliberate attacks can reportedly bring a server down. At the time of this writing, there was no official response by Microsoft to this claim.

Despite the reports of problems, all is not doom and gloom. Other flaws have been announced which, although serious, may be less real. For example, in late August 1997, a program that reportedly could crash an NT system was circulated. Appropriately called crashnt.exe, the program attacked the NTFS and could be used to crash both servers and workstations. This program, however, does not appear to affect NT systems loaded with all of the Microsoft recommended hot fixes, which is reason enough to monitor and install patches as they appear, and to appreciate why there has been no specific Microsoft response to this problem (as of this writing).

PREVENTIVE MEASURES

Windows NT is relatively secure using the default settings with which it is shipped, and is relatively easy and intuitive to administer. Nevertheless, there are a number of security policies that a variety of sources recommend be put in place to make the system even more secure. These include:

Disable NetBIOS over TCP/IP: Failure to do so can allow any attacker running TCP/IP (which is everyone on the Internet!) to access all print, file, and application sharing services on your network.

Use NTFS, not FAT: NTFS volumes can be protected with the ACLs applied to files and directories, as well as permissions on shared directories. DOS-based FAT volumes do not provide this range of protection.

Disable the Guest account: Although Guest ordinarily has limited privileges, it can still be used by an attacker to hurt you. This account should be enabled only if there is an overriding reason to do so. If the system is a server, one could argue that all user accounts should be disabled or restricted.

Rename the Administrator account: Windows NT, like most operating systems with passwords, employs a "blacklisting" feature that thwarts password-guessing attacks by blocking an account after some number of failed logon attempts. The administrator's account, however, is exempt from this blacklisting, making it vulnerable to a brute-force, password-guessing attack. Because you can't delete or disable this account, try renaming it to some obscure name; an attacker then has to guess the name of the administrator's account even before trying a password-guessing attack.

Disable the Everyone group: As described above with the RedButton attack, the Everyone group can be the cause of many headaches. Disabling this group must be done carefully. Failure to test this thoroughly can cause all sorts of other problems because several server applications are sensitive to the status of the Everyone group.

Disable mapping for .BAT and .CMD files: Many Web servers, including Microsoft's NT-based Internet Information Server (IIS), allow improper access to batch (.BAT) and command (.CMD) files through the Web server interface. Disabling the mapping to these file types at the server prevents users from accessing them via the Web server. In addition, these types of files should never be used to launch Common Gateway Interface (CGI) scripts.

Don't use the ftp or telnet server applications: ftp and telnet servers are well-known vulnerabilities in any environment because they allow attackers to pound away at usernames and passwords until they accidentally find one that works. Only enable these server applications if they are deemed absolutely necessary. If one or both of these services is essential, consider establishing separate partitions for them.

Think twice before using the Web server as a file server: Using a Web server as a file server potentially allows attackers access to corporate data. Having corporate information on your externally accessible Web server is the basis for extranet services, however. Only do this if you are sure that it is necessary and be sure to restrict access to these files.

Remove unused program files: Remove unused, executable files from your server to keep attackers from doing more damage to your network in case they do find a hole in which to access the system. Some programs, such as ftp.exe, telnet.exe, and rasdial.exe, should be removed if they are not being used. If the programs are not used, they are probably not configured or restricted (why would they be if they're not being used?), and, therefore, are doubly dangerous if accessed by an attacker.

Create separate partitions for NT and Internet data: Although this suggestion requires a lot of effort and planning, it is based on the observation that if each group of files is in a separate partition, there is a reduced risk of exposure if one application is compromised. For example, NT data, Web pages, CGI scripts, ftp downloadable files, and the ftp upload area might all be placed in separate partitions.

SECURITY AWARENESS

Other suggestions designed to fend off attackers include:

Only log on as administrator in order to perform specific administrative tasks; otherwise, log on as a normal user.

Do not allow a Windows NT server to be accessible from the Internet for common file and print services; this will decrease the vulnerability for remote attacks with modified clients.

Turn on auditing so that you know when you are being attacked (it is not turned on by default).

Change the headers in server applications, where you can, so that applications don't announce the server's operating system or application version. A user of your organization's Web server, for example, shouldn't care at all that you are running over NT; only an attacker would care.

Educate your user population about security! Have users enable the security features of browsers and electronic mail readers. In particular, Java, ActiveX, and other applications should not be allowed to automatically execute any downloaded code, and such code should only be downloaded from trusted sites. Also, teach your users how to choose good passwords; if possible, the system administrator should use tools to verify that passwords are not easy to guess. (See the next section for such a tool).

Security Tools

Several software tools are available to help the NT system manager track and maintain security.

L0phtcrack from the L0pht Group (www.l0pht.com), Secure Networks' (Calgary, Alberta) NT Crack, and NT Crack from the Nomad Mobile Research Centre (www.nmrc.org/files/nt) are all NT variants of the Unix crack program and can recover passwords from the registry or network sniffer logs. In general, crack and its variants work by hashing a list of words (for example, from a dictionary) and comparing the hash values with an NT password database.

And how do you obtain the hash values of the passwords? Tools such as pwdump from Nomad (www.nmnrc.org/files/nt) read the SAM database, and write the user identifiers and password hash values into a file. These programs are generally very fast. NT Crack, for example, reportedly can match an 860,000-word list to a SAM database containing 1,000 users in approximately five minutes on a common PC. These programs generally require administrative privilege and may be used, ostensibly, by system managers to test their own password file against obvious password-guessing attacks. Attackers, of course, can use the same program.

Milkyway Networks' (Ottawa, Ontario) SecureIT Audit and Internet Security Systems' (Atlanta) SAFEsuite Internet Scanner are commercial products that test NT systems for weaknesses and vulnerabilities based on the system's configuration, and are conceptually similar to the now-infamous SATAN program. These products probe Internet TCP/IP host systems for known vulnerabilities and offer recommendations to the system manager on how to fix any weaknesses that are discovered.

WebStalker, from Haystack Labs (Austin, TX), is a Web server logging and monitoring program. This software resides on the server and monitors and logs usage. It also can protect server files by enforcing local security policies. WebStalker can notify the network manager if certain events occur and can shut the server down when it thinks the server is under attack. Internet Security Systems' RealSecure and Intrusion Detection's (New York City) Kane Security Monitor also provide automated, real-time "attack" protection for an NT server by detecting potential attacks and automatically responding to them.

The L0pht Group Web site also has a program available that can view the contents of .ASP, or Active Server Pages, files. These files contain server-side scripts, which are meant to execute transparently to the user. The script files may contain sensitive information such as SQL Server passwords. Because the files are not visible to the user, this is usually not a problem. This tool, however, makes the contents visible to the user.

Information Resources

The most common place on the Internet to hear about Internet security incidents, problems, and solutions is from the CERT Coordination Center (www.cert.org) at Carnegie-Mellon University (Pittsburgh). But, nearly every CERT advisory seems to have something to do with some vendor's version of Unix and it is a rare one that addresses Windows NT. This is not by design, however, because CERT's charter is to deal with any Internet security-related incident. Instead, it is a result of the fact that it is more common within the Unix community to share this kind of information and CERT provides an excellent central facility for such communication. Windows NT problems, in particular, tend not to get reported at CERT because only Microsoft can do anything to fix any reported problems. Thus, Microsoft tends to be the location for NT-related security reports and fixes.

Critics often claim that Microsoft is slow to respond to security weaknesses in NT and/or does not take the reported problems seriously. Microsoft employees claim that they respond as quickly as necessary and that they don't publicly discuss operating system problems without also presenting a solution. Here, of course, is the obvious double-edge sword of security problems: by advertising risks, you inform the owners of NT systems, but also the attackers of NT systems. Because all owners won't install all safeguards, you might actually be helping the situation by being silent about a problem. At least that's one theory. The other theory observes that the NT attacker community certainly isn't being quiet about the problems, so forewarned is forearmed.

BE PROACTIVE

To be appropriately prepared to protect your NT server, get a book about NT security. A number of these books that have appeared within the last year or so are listed. But don't stop there. By their nature, books are not dynamic and, in this fluid topic area, cannot be totally up-to-date. For that reason, visit Windows NT Web sites related to security issues; these are listed as well. Some of these sites market products as well as provide information, but all are informative and educational.

Finally, there are two Internet discussion lists that deal with NT security issues. The NTBugtraq security mailing list is one where it's proper to disclose details of security holes so that you can assess your own exposure. To subscribe to NTBugtraq, send a message to listserv@listserv.ntbugtraq.com with subscribe ntbugtraq firstname lastname in the message body; the archive for this mailing list can be found on the Web at listserv.ntbugtraq.com. The NT Security list covers security topics relating to Windows NT, Windows 95, and Windows for Workgroups. To join this list, send e-mail to request-ntsecurity@iss.net and place the line subscribe ntsecurity in the text of your message.

Gary Kessler is the director of information technology at Hill Associates, a telecommunications training, education, and consulting firm in Colchester, VT. He is the co-author of ISDN (3rd edition, McGraw-Hill) and the author of more than 40 articles. He can be reached at kumquat@hill.com.