Security in Windows NT

Gary C. Kessler
November 1997

An edited version of this paper appeared with the title "SPECIAL REPORT: How to Improve Windows NT Security" in the February, 1998 issue of Network VAR.

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 to low-end systems via Win32S (an adjunct to Windows) and Windows 95, their commitment to Windows NT fell into doubt. But the power and stability of Windows NT made it a very popular product and NT is a flagship product of Microsoft today.

The backing of Microsoft (http://www.microsoft.com, Redmond, WA) 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 network operating system (NOS) marketplace. NT has become a popular product 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 marketshare, mostly to Windows NT. And while most of the servers on the Internet have been and still are Unix-based, an increasing number of World Wide Web (WWW), File Transfer Protocol (FTP), Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), and other servers are running on Windows NT platforms.

NT Security Mechanisms

Like any operating system designed for servers and/or the Internet, Windows NT has built-in security mechanisms to authenticate users, and 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 U.S. Department of Defense's National Computer Security Center (NCSC) 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 level security defined in TCSEC and is oriented towards stand-alone systems rather than networked computers.

The 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. Windows, menus, processes, user data, and files are all examples of objects. As an example of object security, Windows NT protects memory so that information cannot be read after memory blocks are deallocated by a process. All NT objects can be assigned varying levels of access protection.
  
  
• Identification and Authentication: System resources must be protected on a user-by-user basis and users must be able to uniquely identify themselves. In Windows NT, identification and authentication are achieved by use of logon names and passwords (described in more detail below). Each user has a Security Identifier (SID) tied to a network domain; while 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 (ACL) for objects. Each object's security descriptor contains the owner's SID, a discretionary access control list (DACL), and system access control list (SACL). The owner sets the DACL entries; for example, the owner of a directory ("folder" in the Windows 95 and NT vernacular) can specify what access other users have to this directory and files within the directory; the owner can also 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 are limited to authorized administrators to prevent an attacker from "covering their tracks." Windows NT auditing is controlled by the SACL.

Password Security in NT

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 Security Identifiers (SIDs) associated with any local or network user or group to which this user is a member. The access token is also 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, are stored in the Security Accounts Manager (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, and it is essentially 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 password (112 bits) to form two 56-bit values, each of which are used to encrypt a fixed (known) 8-byte number using the industry-standard Data Encryption Standard (DES); the two DES encrypted 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.

    NT DOMAIN SERVER                                  CLIENT

  ------------                             (1)
  |  hashed  |<-- username <------------------------- username | password | (2)
  | database |    random number  ----------------------->  random number 
  ------------     |                                                   |
      |            |                                 hashed password   |
      | |----------|                                               |   |
      V V                                                          |   |
     -----                                                         |   |
(3s) |DES|--> expected response                                    V   V
     -----                                 (4)                     -----
                                  <------------------ response <--|des| (3c)
                                                                   -----
                                            (5)
                         ACK/NAK  ------------------->

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 onto 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, at best, primarily because users generally choose bad passwords, write them down, share them with other users, or practice other bad habits. Furthermore, only a single bad password can give an attacker the entree he or she needs 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

More and more companies are supporting remote access to their networks via the dial-up network. In Windows NT, the Remote Access Service (RAS) provides remote node access, meaning that the calling host appears to be directly attached to the network. RAS supports use of the Internet Protocol (IP), Novell's Internetwork Packet Exchange (IPX) protocol, and NetBEUI (NetBIOS Extended User Interface). 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, the Challenge Handshake Authentication Protocol (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 (i.e., Windows for Workgroups, Windows 95, or Windows NT), 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 the Point-to-Point Protocol (PPP).
  
  
• NT client/Shiva server or Shiva client/RAS server: Shiva's LAN Rover is one of the most common remote node access devices in use today. Shiva clients and servers employ the Shiva Password Authentication Protocol (SPAP) for authentication. SPAP can also be used in the NT environment between a Windows NT client and Shiva LAN Rover or between a Shiva client and Windows NT remote access server.
  
  
• None of the above: The Password Authentication Protocol (PAP) sends unencrypted passwords between 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. Use of PAP, however, can be disabled by the system administrator, thus ensuring at least a moderate level of password security; it is recommended that PAP, in fact, be disabled unless absolutely required because it is so unsecure.

Finally, Windows NT security mechanisms are available for third-party applications via Microsoft's Security Support Provider Interface (SSPI). The 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.

Examples of Windows NT Security Vulnerabilities

All Internet servers, regardless of the underlying operating system, run the Transmission Control Protocol/Internet Protocol (TCP/IP) suite and are, therefore, susceptible to any and all of the vulnerabilities of those protocols. Intrusions and denial-of-service attacks using IP address spoofing, TCP SYN hangups, Simple Mail Transfer Protocol (SMTP) address spoofing, the "Ping-of-death," 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 (e.g., firewalls and proxy servers) can be used to protect an NT server running TCP/IP.

But most servers on the Internet run over the Unix operating system and Unix adds a host of additional vulnerabilities, such as buffer overflow problems and the documented vulnerabilities of sendmail, and numerous other obscure and not-so-obscure Unix services. Windows NT, not being Unix, is usually not thought to be susceptible to those flaws and is often considered to be 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.

While NT is relatively secure, there are security weaknesses and vulnerabilities in all operating systems, many due to actual flaws in the protections while others are due to 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 (Network Basic Input/Output System) in LAN Manager, including the relatively weak cryptographic protection scheme, small cryptographic key sizes, and 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, as well. It is illustrative to describe a few of the other reported NT security vulnerabilities.

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

To logon 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 logon 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 logon without a username and password, whether the Guest account is enabled or disabled, and access such network resources as files, printers, and the Registry.

NTsecurity.com developed a program called "RedButton" to demonstrate the flaw, which they posted on their Web site. Their proposed solution is that system managers should define a new group (they suggest EveryUser) that explicitly includes all legitimate users for this NT domain; this probably is what the system administrator wanted anyway and ensures that the administrator explicitly knows about the user names 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. They quickly followed this up by posting information about their response and proposed solutions on their Web site, and 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.

In May 1997, another problem was discovered 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; it is also known to affect port 53 (DNS) and port 80 (Hypertext Transfer Protocol, HTTP), and may 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 with an invalid sequence number, invalid window size, and with 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 online.

This particular attack is insidious because it appears to have few protections. Proxy servers may be secure but some firewalls will pass the OOB data. Microsoft has supplied patches to Windows 95 and Windows NT but critics said that they knew about the problem for weeks before supplying any such patches. More information about the OOB Bug can be found at http://www.ntsecurity.net/security/oob.htm. The WinNuke Testing Ground web page at http://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.

In July 1997, a program called getadmin.exe was making the rounds, allowing anyone to add users to the Administrators group. No special permissions are required to execute the program and it can also 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 hotfix for the problem, but the vulnerability persisted until another hotfix came out in late August. More information about this exploit can be found at NTsecurity.net's Web site.

Perhaps more seriously, an e-mail to the Windows NT BugTraq mailing list in October 1997 allowed 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 allow that fixing individual problems wasn't enough; buggy code (all large programs are complex and all complex programs have errors!) 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.

The paragraphs above are not meant to be all doom and gloom. And there have been other flaws announced which, while 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 NT File System (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 hotfixes, 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).

Additional NT Server Security Recommendations

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 systems even more secure, including:

• Disable NetBIOS over TCP/IP: Failure to do so can allow any attacker running TCP/IP (i.e., 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 access-control lists (ACLs) applied to files and directories, as well as permissions on shared directories. DOS-based file allocation table (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 and 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 log-on attempts. The administrator's account, however, is exempt from this blacklisting, thus making it vulnerable to a brute-force password-guessing attack. Since you can't delete or disable this account, try renaming it to some obscure name instead; thus, an attacker has to guess the name of the administrator's account before even 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. But be very careful when disabling this group as it must be done carefully; failure to test this thoroughly can cause you 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 type 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 precautions 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 not used, they are probably not configured nor restricted (why would they be if they're not being used?), and are then doubly dangerous if accessed by an attacker.
  
  
• Create separate partitions for NT and Internet data: Although this suggestions 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.

Other suggestions for the administrator:

• Only logon as administrator in order to perform specific administrative tasks; otherwise, logon 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.

Finally, 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 below for such a tool).

Tools and Information Resources for the NT System Manager

There are several software tools to help the NT system manager track and maintain security, including:

• L0phtcrack (http://www.l0pht.com), Secure Networks' NT Crack (http://www.secnet.com, Calgary, Alberta), and NT Crack from the Nomad Mobile Research Centre (http://www.nmrc.org/files/nt) are 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 (e.g., from a dictionary) and comparing the hash values with an NT password database. And how does one obtain the hash values of the passwords? Tools such as pwdump (http://www.nmrc.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, can reportedly match an 860,000 word list to a SAM database containing 1000 users in approximately 5 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, may be able to use the same program.
  
  
• Milkyway Networks' (http://www.milkyway.com, Ottawa, Ontario) SecureIT Audit and Internet Security Systems' (http://www.iss.net, Atlanta, GA) 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 programs probe Internet TCP/IP hosts systems for known vulnerabilities and offer recommendations to the system manager on how to fix any weaknesses that are discovered.
  
  
• WebStalker, from Haystack Labs (http://www.haystack.com, Austin, TX), is a Web server logging and monitoring program. This software resides on the server, monitoring and logging usage; it can also protect server files by enforcing local security policies. Finally, 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 (http://www.intrusion.com, New York, NY) Kane Security Monitor also provides automated, real-time "attack" protection for an NT server by detecting potential attacks and automatically responding to them.
  
  
• The L0pht 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. Since the files are not visible to the user, this is usually not a problem; this tool, however, makes the contents visible to the user.

The most common place on the Internet to hear about Internet security incidents, problems, and solutions is from the CERT Coordination Center (CERT/CC, http://www.cert.org) at Carnegie-Mellon University (Pittsburgh, PA). 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, since 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 the sole vendor of Windows NT -- i.e., Microsoft -- can do anything to fix any reported problems. Thus, Microsoft has tended 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 do not take the reported problems seriously. Microsoft, for their part, claims 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-edged sword of security problems; by advertising risks, you inform the owners of NT systems -- and the attackers of NT systems. Since 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 quite about the problems so forewarned is forearmed.

To be appropriately prepared to protect your NT server, get a book about NT security; Table 1 lists a number of such books that have appeared within the last year or so. But you can'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; some are listed in Table 2. 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 http://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.


About The Author: Gary Kessler is the Director of Information Technology at Hill Associates (http://www.hill.com), a telecommunication training and consulting firm with headquarters in Colchester, VT. His e-mail addresses is kumquat@hill.com.