Password protection is a glaring weakness of Windows NT security. Administrators who are migrating their systems from NT to Windows 2000 need to know how password policy will change when they adopt the new OS. Although Win2K protects passwords better than NT does, Win2K's password protection isn't perfect. Programs that let users crack NT user passwords don't work as well in Win2K, but you still need to carefully watch for password vulnerabilities in Win2K.
Cracking Passwords
Several years ago, the elite hacker group L0pht Heavy Industries released L0phtCrack, software that lets you crack NT password hashes in a short time. L0phtCrack is effective because it takes advantage of vulnerabilities in the hashing algorithm that NT uses to support the NT LAN Manager (NTLM) network authentication protocol. (For information about LAN Manager security, see the sidebar "Why NT Passwords Are Weak," page 106.) When Microsoft announced that in Win2K the proven Kerberos protocol would replace the weak, proprietary NTLM protocol, administrators thought that all vulnerabilities of password hashes in the SAM would disappear. (For more information about Kerberos, see Jan De Clercq, "Kerberos in Win2K," October 1999.) Win2K is more resistant to cracker and sniffer attacks than NT is, but Win2K doesn't eliminate backward-compatibility security problems. In certain situations, Win2K still uses NTLM when connecting to another computer. Thus, Win2K stores passwords in the vulnerable NTLM hash format, and in some instances you can use L0phtCrack to crack Win2K user passwords.
Similar to NT systems, Win2K member servers that aren't domain controllers and Win2K Professional workstations maintain a local SAM. But if you load L0phtCrack, select Dump passwords from registry from the Tools menu, then start a cracking procedure, L0phtCrack runs indefinitely and doesn't crack any passwords. L0phtCrack fails because a Win2K system has Syskey enabled by default. Syskey, a program that appeared with NT 4.0 Service Pack 3 (SP3), uses a 128-bit key to encrypt password hashes in the SAM, making subsequent SAM copies impervious to L0phtCrack. However, a user who has administrative authority can use Todd Sabin's pwdump2 utility to dump Win2K's password hashes from OS memory, where they aren't encrypted. You can supply pwdump2's output to L0phtCrack, which can then use the hashes to begin cracking passwords. This method requires that you have physical access to the system; you can't use this method remotely.
This password-cracking method applies only to Win2K member servers and Win2K Pro workstations, systems on which you usually don't maintain user accounts. To crack domain users' passwords, you can run pwdump2 on a Win2K domain controller, then try to crack the hashes. You'll have the best success with the newer pwdump2 version dated March 28, 2000. This version can dump password hashes from Active Directory (AD), in which Win2K stores user accounts. Pwdump2's earlier version works on NT and can't dump hashes from AD. (For information about using pwdump2 on Win2K domain controllers, see "Cracking User Passwords in Windows 2000" at http://www.WindowsITsecurity.com/articles/index.cfm?articleid=9186.)
Win2K workstations, member servers, and domain controllers remain vulnerable to password cracking by users who have administrative authority. This vulnerability is a concern if you're worried about users who have administrative authority abusing their power. However, the vulnerability is a benefit if you want to assess the strength of your users' passwords. I recommend periodically using L0phtCrack to crack your domain. When you use L0phtCrack to crack your domain, you aren't trying to determine whether your users' passwords resist L0phtCrack; given enough hours or days, the pwdump2 and L0phtCrack combination will crack any password. The purpose of cracking your domain is to determine which users have passwords that attackers can easily guess. L0phtCrack's list of 29,000 English words is up to the task. When I use L0phtCrack to crack a company's domain, the tool often reveals 40 percent or more of users' passwords.
You can download specialized and foreign-language word lists for L0phtCrack from ftp://ftp.cso.uiuc.edu/pub/ security/wordlists/, or you can build a word list. To point L0phtCrack to a new list, select Wordlist on the File menu. I assessed the security system of a company in which most of the employees spoke German. I set up L0phtCrack to use a German word list from the Internet and the default English list. The program demonstrated that more than 70 percent of the system's users had simple passwords that usually reflected an aspect of their personal lives. Management created a new password policy, and the chief security officer taught staff members better password-selection techniques. The IT staff continued to use L0phtCrack to test the company's security. Within 3 months, the number of weak passwords declined by half.
Capturing Passwords from the Network
Kerberos, which isn't vulnerable to L0phtCrack, replaces NTLM as Win2K's default method of authentication only when the systems involved in authentication are running Win2K (or Windows 9x with the AD client loaded) and are in the same domain or in trusting domains (e.g., in a forest). In all other cases, Win2K still uses NTLM. For example, when a Win2K workstation user maps a drive to a Win2K Server system that isn't a domain member, Win2K uses NTLM as the authentication protocol. Anytime a Win2K system connects to an NT system, or vice versa, NTLM is the authentication protocol because NT can't use Kerberos. Figure 1 shows various connection scenarios in which Win2K uses Kerberos or NTLM. When Win2K uses NTLM, the protocol is subject to sniffing and subsequent cracking techniques, as it is in NT. L0phtCrack includes the Server Message Block (SMB) Packet Capture feature, which lets you capture to a file the NTLM challenge and response exchange that happens when a client connects to a system on the network. You can then feed the file that contains the challenge and response exchange to L0phtCrack, which cracks the challenge and response pair by hashing candidate passwords and creating a candidate response based on the captured challenge. If the candidate response matches the captured response, L0phtCrack has found the password.
When I used L0phtCrack's SMB Packet Capture on a Win2K and NT network, L0phtCrack captured the challenge and response exchange between Win2K and an NT system. However, the tool failed to capture anything when I initiated drive mappings between two Win2K systems that weren't members of trusting domains. This failure surprised me because I thought Win2K would use the SMB file-sharing protocol and the NTLM protocol for authentication. (Figure 1 shows that in this configuration, Win2K uses NTLM.) To investigate why L0phtCrack didn't capture any traffic between the two Win2K systems, I loaded a packet-capture utility and captured all the network traffic between the systems. My packet trace showed that the systems initiated two connections—one on TCP port 139 and the other on port 445. I expected traffic to occur on port 139 (NetBIOS over TCP/IP—NetBT) because NT file sharing and other NT communications use that port for SMB file sharing. However, after the first packet used port 139, all subsequent traffic used port 445. From the packets' data, I discerned that Win2K was using port 445 for file sharing.
To reduce Win2K's dependence on NetBIOS, Win2K uses the Common Internet File System (CIFS) protocol rather than SMB when handling file sharing between two Win2K systems. Whenever a Win2K system initiates a file-sharing session with another system, the initial system sends a connection request through ports 139 and 445 and uses the port that the target system replies to first. Thus, Win2K uses port 445 to contact another Win2K system and falls back to port 139 when connecting to a different OS. L0phtCrack watches for packets only on port 139, so the tool works only when systems use NTLM with SMB, not CIFS. Consequently, the current version of L0phtCrack can catch connections only between Win2K and NT (which use NTLM and SMB) and not connections between two Win2K systems (which use NTLM and CIFS).
Reduce the Risk
To protect against password sniffing, upgrade NT to Win2K, load the AD client on Win9x systems, and migrate your Win2K domains from mixed mode to native mode. These actions will reduce the occurrence of NTLM authentication on your network.
For situations in which you can't eliminate NTLM, such as connections between Win2K and NT systems, consider adjusting the LMCompatibility Level settings on the systems involved. LMCompatibilityLevel is a Registry setting that NT 4.0 SP4 introduced that also exists in Win2K. In Win2K and NT, you can find the setting under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA Registry key. Selecting an LMCompatibilityLevel value of at least 1 can prevent the weak LAN Manager response from transmitting during connections. Eliminating the LAN Manager response makes L0phtCrack crack the NT response, which takes much longer than cracking the LAN Manager response. LMCompatibilityLevel also lets you require NTLMv2 for all network connections, which completely defeats L0phtCrack 2.5. (For information about LMCompatibilityLevel, see "Inside SP4 NTLMv2 Security Enhancements," September 1999.)
In Win2K, you can use Group Policy to control the LMCompatibilityLevel setting. Under \Computer Configuration\Windows Settings\Security Settings\LocalPolicies\Security Options, you'll find a policy called LAN Manager Authentication Level. Figure 2 shows the valid settings for this policy. When you define a value for this policy in a Group Policy Object (GPO), Win2K sets the corresponding value for LMCompatibilityLevel in the Registry of each system to which that GPO applies. If you want to specify a standard LMCompatibilityLevel for all computers in your domain, open the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, open the properties for the domain root, and click the Group Policy tab. Open the Default Domain Policy GPO and maneuver to the LAN Manager Authentication Level policy dialog box that Figure 2 shows. Set the LAN Manager Authentication Level to at least Send LM & NTLM - use NTLMv2 session security if negotiated.
Account Policies
Password and account lockout controls are similar in Win2K and NT. Win2K, like NT, has control options for minimum password length, maximum and minimum password ages, password uniqueness, and account lockout thresholds. However, in Win2K, you configure password and account lockout controls differently than in NT. To configure password and account lockout policy for your Win2K domain accounts, you need to open the Default Domain Policy GPO.
To reach the Default Domain Policy GPO, open the MMC Active Directory Users and Computers snap-in, right-click the domain, and select Properties. Select the Group Policy tab and edit the Default Domain Policy. Then, navigate to the Password Policy and Account Lockout Policy folders under \Computer Configuration\Windows Settings\Security Settings\Account Policies, which Figure 3 shows. Win2K users are subject to control only by the password and account lockout policies whose definitions reside in GPOs that link to the root of the domain control. AD, not the domain controller's local SAM, manages Win2K domain users. AD looks only at the group policies at the domain root. This setup might disappoint you if you planned to use group policies linked to lower organizational units (OUs) in AD to set password requirements for different departments in your company. For example, you might have planned to require five-character passwords for users in marketing and seven-character passwords for users in IT administration. But because AD looks at group policy only at the domain level, all users in the domain must adhere to the same password and account lockout policy.
When you specify values for your domain's password policy, don't configure them independently. You need to combine the values to achieve an aggregate protection level for your passwords. The procedure for setting your domain's password policy involves three steps: requiring users to choose high-quality passwords that are difficult to guess, requiring users to change passwords on a regular basis, and slowing attackers who use repeated logon attempts to guess passwords. Setting values for each of the three steps gives you flexibility if people in your organization resist one of the protection methods. For example, users might resist making regular password changes. In that case, you can weaken the controls for that step and strengthen controls for other steps.
Step 1. In \Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy, select a value for the Minimum password length setting to require users to select quality, difficult-to-guess passwords. A more effective alternative is to select the Passwords must meet complexity requirements option, which requires that passwords contain characters from at least three of the following cate-gories: A-Z, a-z, 0-9, and nonalphanumeric characters (e.g., !, $, #, %). In addition, you can use notification packages, which are custom DLLs, to implement advanced password requirements that go beyond minimum password length and complexity requirements. You can specify notification packages by adding the DLL's name to the NotificationPackages value under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA Registry key in Win2K and NT. (For more information about notification packages, see the Microsoft article "HOWTO: Password Change Filtering & Notification in Windows NT" at http://support.microsoft.com/support/kb/articles/q151/0/82.asp.)
Step 2. You can use the Maximum password age option to require password changes on a regular basis, making passwords moving targets. To prevent users from using the same password when the system requires them to change it, use the Enforce password history option, which enables Win2K to remember users' previous passwords. You can set the number of previous passwords that Win2K remembers so users can't reuse them. I recommend setting the number of passwords at 24, which is the maximum. However, users who are determined to use their favorite password can loop through 24 password changes to make Win2K forget their original password and trick the system into accepting the original password. To prevent this tactic, you can set the Minimum password age option to 1 or 2 days, which prevents users from executing a series of immediate password changes.
Step 3. To slow attackers, use the account lockout options in \Computer Configuration\Windows Settings\SecuritySettings\Account Lockout Policy, which Figure 4, page 109, shows. The combination of values that Figure 4 shows for Account lockout duration and Account lockout threshold tells Win2K that if it detects within any 24-hour period five consecutive failed logon attempts that involve an incorrect password, the OS should lock out the account. The Account lockout duration option's value is 0, so the account stays locked out until the legitimate user asks an administrator to unlock the account. If you want Win2K to automatically unlock the account after a certain time, specify a time period for the Account lockout duration policy.
Win2K offers a new account policy, Store password using reversible encryption for all users in the domain. This policy causes Win2K to store user passwords in clear text in AD, where anyone can find and read them. Microsoft's Group Policy Reference states, "The intent of this policy is to provide support for applications which use protocols that require knowledge of the user password for authentication purposes." An example is support for the AppleTalk protocol. Unless you need support for Macintosh computers that use AppleTalk, don't enable Store password using reversible encryption for all users in the domain. When you open a user account object in the MMC Active Directory Users and Computers snap-in, you'll notice the Store password using reversible encryption option under the Account tab. This option has the same effect as the Store password using reversible encryption for all users in the domain policy. However, when you select the option on a user account, you'll affect only one user instead of the entire domain.
Use Caution
Passwords benefit from better protection in Win2K, but they're still vulnerable. Make sure you avoid situations in which Win2K uses the old NTLM authentication protocol. Implement strong password-quality and password-change policies and strict lockout policies for your user accounts. You need to set policies in GPOs that link to the domain root. Don't forget to use L0phtCrack and pwdump2 to regularly crack your domain's passwords and assess password quality. Follow up your efforts with feedback to users who select poor passwords, and provide training to help users pick quality passwords. If you follow these guidelines, your system will have passwords that intruders can't easily crack, sniff, or guess.
