The Tao of security
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.
Previous
Register
