Windows NT is feature rich, but some of NT's features create security vulnerabilities. Many users and administrators don't understand how attackers use NT's security vulnerabilities to penetrate networks. You can underestimate a security flaw's seriousness if you examine it in isolation. For example, services running on the host or network can magnify security problems that seem benign. I will discuss various threats and attack methodologies that have been successful against NT and give you strategies you can use to protect your network. (For more information about NT security, see "Related Articles in Windows NT Magazine," page 140.)
Gathering Information
The first step in a concerted attack is gathering information. The information-gathering phase involves understanding the network's topology, acquiring host names and usernames, probing for available services, and looking for trust relationships. You need to be aware of this process to understand the danger of giving information to unauthorized users. Attackers use the following techniques to gather information about NT networks.
Anonymous connections (also called null sessions) are fundamental to gathering information about a network. Anonymous connections are part of NT's architectural design. Many privileged NT system services run under the context of the LocalSystem built-in user account, but the LocalSystem account does not have an associated password. When a system service needs to communicate with a remote NT host, it must establish a Server Message Block (SMB) connection. SMB sessions require authentication, which creates a problem because the LocalSystem account does not have a password. The LocalSystem account uses a null (empty) username and password to authenticate the connection. The null username and password are a special set of credentials that identify the built-in Anonymous account. Thus, the Anonymous account facilitates network communication for NT system services. If you use a null username and password in network authentication, NT establishes the session in the context of the Anonymous account on the remote machine. The Anonymous account's access is too widespread. Service Pack 3 (SP3) and several post-SP3 hotfixes limit this access, but they do not solve the problem.
Attackers can write a program that uses the NetUserEnum( ) API call to list a host's user accounts, or they can use the NT Server User Manager utility. The information retrieved includes the username, full name, description field, and User Manager account options. This information is available through anonymous connections by default. You must install SP3 and create a Registry value to change this functionality. Even after you disable account enumeration for anonymous users, an anonymous user can use the LookupAccountSid( ) API call to obtain users' account information. LookupAccountSid( ) also provides the name of the Administrator account, so renaming this account does not deter a dedicated attacker.
The NetUserModalsGet( ) API call provides information about the host. This API returns the host's password policy: minimum password length, minimum and maximum password age, and number of passwords in the history list; the host's role, whether standalone, member of a domain, Backup Domain Controller (BDC), or Primary Domain Controller (PDC); the name of the PDC; the domain ID; and the account lockout parameters. Anonymous users can obtain this information unless you install the Local Security Authority (LSA) 2 hotfix. (For more information about this hotfix, see the Microsoft Support Online article "Anonymous Connections May Be Able to Obtain the Password Policy," at http://support.microsoft.com/support/ kb/articles/q129/4/57.asp.)
For most of its functionality, NT networking uses NetBIOS as an abstraction layer from the underlying network transport protocol. Thus, attackers try to obtain hosts' NetBIOS information. On TCP/IP networks, an attacker can send a UDP packet to port 137 with a NetBIOS adapter status query message and listen for the response. (Request for Comments--RFC--1002 describes this message, which is the equivalent of issuing an NBTSTAT -A command.) The adapter status query obtains the host's NetBIOS name, the workgroup or domain the host is a member of, whether the host is a Windows Internet Naming Service (WINS) or Remote Access Service (RAS) server, whether the host is the master browser, and whether the host is a domain controller. The NetBIOS protocol provides little security, so attackers can play impersonation and name table poisoning games on networks. NT 5.0 Active Directory (AD) will help remove NetBIOS vulnerabilities in NT 5.0-only environments.
Some NT network protocols use system time to generate sequence numbers and challenges. Attackers can penetrate these protocols if they know the system time. An attacker can use the NetRemoteTOD( ) API call to determine the system time on a remote NT host. This API call returns the time of day to the hundredth of a second, plus the value of the millisecond (ms) timer that starts at system boot. This information is useful in attacks against time-synched authentication protocols (e.g., Kerberos and SecurID) and pseudo-random number generators that use time as a seed. Well-designed cryptography-based authentication protocols do not directly rely on the system time or system timers for security, but implementation mistakes in systems can cause such dependencies. For example, MIT Kerberos 4.0 had this problem in the session key generation routines.
The remote procedure call (RPC) Endpoint Mapper and Distributed Component Object Model (DCOM) Service Control Manager (SCM) listen on TCP and UDP port 135. Any user who can connect to port 135 can obtain information about which dynamic RPC and DCOM services are running and what ports they are listening on. To stop the Endpoint Mapper and SCM from listening on this port, you must disable the RPC Server service, which cripples NT.
If an NT host has Simple Network Management Protocol (SNMP) installed, anyone who knows the community name can obtain the same information that is available through the previously mentioned techniques. The community name defaults to the well-known name public. Anyone who can connect to the SNMP UDP port and guesses the community name can obtain usernames, group names, password policies, machine roles, services that are running, and other information to plan an attack. The Microsoft SNMP implementation does not provide a mechanism for disabling set requests, so denial-of-service attacks can occur if an attacker determines the community name. In some cases, settable values can facilitate domainwide attacks.
Gaining Access
Many successful penetrations of NT systems occur because of weak passwords. Subtle trust relationships, such as using privileged domain accounts to run services, let attackers penetrate far into NT networks. Thus, an attacker who cracks one password on a local account can gain access to the network.
A common attack scenario starts with information gathering, as I described previously. Servers are the primary targets of attacks, because management software that uses domain accounts is often installed on servers. However, domain workstations can also be easy targets. Based on the information gathered, an attacker identifies servers with weak passwords and lockout policies. The attacker then uses anonymous connections, and the other techniques I discussed, to identify privileged accounts (e.g., members of the Administrator or Server Operator groups, accounts with backup privileges) on the server. Attackers then use simple password guessing, and they often find a local Administrator account with a simple password or no password. Attackers query the SCM for installed services, especially services running under domain accounts. If a service is running under a domain account, the account password is stored in plain text in the Registry. A short program that calls the LsaRetrievePrivateData( ) API extracts the password from the Registry. Depending on the account's privileges, the attacker can use the account to access the PDC. An alternative is to look in the Registry for cached password hashes of domain users who recently accessed the server.
Systems administrators often create local accounts with one username and password for many machines. A user who logs on locally to one machine can access remote resources without supplying a username and password, regardless of whether the machines are in the same domain, a trusted domain, or an untrusted domain. If an attacker compromises one local account, the attacker can access other machines on which the account exists with the same password, but without knowing the password. This situation commonly occurs on NT local Administrator accounts.
Many variations of these attack methodologies exist. An attacker who can log on at the console can turn unprivileged NT accounts into local administrator accounts. Also, attackers can use publicly available utilities to subvert an NT system that is bootable from a 3.5" disk or CD-ROM. Users with local administrator privileges can obtain password hashes for domain users who access the host over the network.
Reducing Your Risk
Most NT break-ins occur through password cracking, remote Registry access by anonymous or unprivileged users, or unsecure Common Gateway Interface (CGI) or Active Server Pages (ASP) Programs on Web servers. The following tips will help you protect your NT hosts and network against various types of attacks.
Microsoft is patching security vulnerabilities as it discovers them. Thus, you need to stay up to date with hotfixes and service packs.
Enforce strong passwords: Use passfilt.dll or a custom password filter, the account lockout feature, password aging, and a minimum password length of eight characters. In the security account database, NT stores two versions of a user's password hashes: the LANMAN and NT versions. NT encrypts (hashes) the LANMAN version in a way that lets an attacker use a password-cracking tool such as L0phtCrack to recover the 8th through the 13th characters of the password. Your password policy needs to specify using punctuation and extended characters, with at least one of these characters beyond the 7th character of the password. Brute force password cracking on these passwords is difficult. Attackers can determine the values of most of these parameters remotely. In high-security environments, supplement logon passwords with token-based authentication systems such as SafeWord or SecurID.
Run only the services necessary to provide the intended functionality for a server or workstation. Disabling the Server, Alerter, and Messenger services helps prevent remote attacks. If you enable the Server service, enable the restrictions on the Anonymous account and limit remote access to the Registry to administrators only. (For more information about restricting the Anonymous account, see the Microsoft Support Online article "Restricting Information Available to Anonymous Logon Users," at http://support.microsoft.com/support/kb/articles/q143/4/74.asp.)
Limit network logons for privileged users. This practice helps prevent password guessing attacks against the Administrator account, and it minimizes the threat of an administrative account compromise. Also, limit network and local logons to users and groups that require access to a particular computer. This practice helps contain breached accounts because it limits the number of machines that an attacker can log on to and try to elevate the account privileges.
Do not use domain accounts for services. Otherwise, anyone with administrator privileges on the machine where you install the service can obtain the password and username for the account the service is running under. Use nonadministrative local accounts to run services that do not need administrative privileges. Microsoft is addressing the service password problem, but limiting services to local accounts helps contain the breach to one machine if the service is compromised.
Minimize implied trust relationships between machines: Give different passwords to local accounts that exist on different machines but have the same name. Explain to users that shared passwords compromise security.
If the administrator needs to log on remotely, use passprop.exe in the Microsoft Windows NT Server 4.0 Resource Kit to enable account lockout for the Administrator account. You can also create a different account with administrator privileges, enable account lockout, and disable network logons for the Administrator account.
If machines using file- and print-sharing services are running NT 4.0, upgrade to SP3 and require SMB message signing. Message signing protects the integrity and authentication of remote administration and file sharing, but it does not provide privacy (i.e., encryption). Use message signing if you perform remote administration of servers and workstations.
If a machine has available shares, make sure the underlying file permissions grant access to only appropriate users and groups. If you maintain appropriate file permissions, you reduce the risk of users inadvertently accessing restricted files.
Turn on auditing. In most environments, a good compromise between security and performance is to enable success and failure auditing of logons and logoffs; user and group management; security policy changes; and restart, shutdown, and system events. In high-risk environments, enable auditing for process tracking and selective file and object access.
You can tighten the default file and Registry permissions in NT 4.0. (For more information about securing NT installations, refer to Steve Sutton's Windows NT Security Guide, available at http://www.trustedsystems.com.) Set file and Registry permissions to limit access to users and groups that need access.
If physical security is less than optimal, disable the ability to boot from devices other than the fixed hard drive. Several boot disks and utilities let you edit data on the hard drive to change account passwords. Limiting the ability to boot from removable media helps prevent users from editing the data on the hard drive.
Protect Your Network
NT is a feature-rich environment for users, administrators, and attackers. Unfortunately, the features that make NT network-friendly provide attackers with vital information and avenues of attack. You might need to compromise ease of administration to maintain security. Enable only the features necessary to support business functions, and grant access only to users who need it. As Sun Tzu said, "Those skilled in war cultivate the Tao and preserve the laws and are therefore able to formulate victorious policies."