Win2K Password Protection

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).