Passwords are the keys to your corporate network, and they can fall into the wrong hands just as physical keys can. Passwords are vulnerable to theft because careless users often select easy-to-guess passwords and because of the ways in which operating systems (OSs) store, encode, and transmit passwords. To provide authentication services, an OS must store passwords so it can compare them with users' password entries. In addition, an OS must transmit some form of a password to a remote machine whenever it authenticates a connection request from a remote user. Authentication leaves open the possibility that an intruder can retrieve user passwords by accessing the OS's password file or eavesdropping on the network when a user logs on.
Microsoft designed Windows NT to protect against security problems, but these protections are not without holes. Over the past year, several password-thieving exploits on NT systems received public attention. Microsoft countered the negative attention with security upgrades in Service Pack 3 (SP3) and hotfixes. (For information about SP3's security upgrades, see Mark Joseph Edwards, "Service Pack 3 Is Really Security Pack 3," August 1997.) However, claims that these fixes don't make NT secure have circulated in the press and on the Web. Now that the dust has settled somewhat, take stock of NT's current security risks and take steps to protect your network.
How NT Stores Passwords
NT stores unencrypted user passwords in one location. You can configure NT services to run under a specific user account. To start services under the account you specify, the Service Control Manager (SCM) must have access to the account's clear-text password. SCM stores passwords for services' accounts in the Local Security Authority (LSA) Secrets area of the Registry. Hackers have found ways to collect clear-text passwords from LSA Secrets. Most of their exploits require administrator access, so hackers must trick an administrator into running a rogue program under the administrator's account. To protect your services' accounts, prevent administrators from running untrusted programs. Also, apply the LSA2-fix hotfix, which Microsoft claims defeats currently publicized exploits. (For information about applying the hotfix, see Microsoft Support Online article Q184017, "Administrators Can Display Contents of Service Account Passwords," at http://support.microsoft.com/support/kb/articles/q184/0/17.asp.)
For every other function NT uses passwords for, the OS stores derivatives of passwords rather than clear-text passwords. These derivatives result from NT's one-way encryption function. NT inputs the password to the function, and the function yields a hash, the derivative string of bytes that the function relates to the password. Theoretically, you can't easily reverse the function to retrieve the password from the hash. All NT security APIs, commands, and dialogs authenticate user passwords by running the user's password entry through the one-way function and comparing the resulting hash with the hash in the Security Accounts Manager (SAM) Registry hive. If the hashes match, NT gives the user access to the network.
The good news about this password-storage method is that even if a hacker obtains a copy of the SAM Registry hive, the hacker gets hashes, not passwords. The bad news about NT password protection is that, last year, the hacker community developed L0phtCrack, a tool that finds hashes on NT systems and derives their user passwords. The tool repeatedly performs NT's one-way encryption function on possible passwords, then compares the result of each encryption operation to the captured hash. Eventually, the tool guesses the right password, the hashes match, and the hacker has a valid password. (For more information about L0phtCrack, visit the L0pht Heavy Industries Web site at http://www.l0pht.com.)
L0phtCrack can derive difficult passwords from their hash within hours. I ran L0phtCrack on a 150MHz Pentium machine, and in one day, the tool decrypted three 14-character passwords made up of combinations of numbers and mixed-case letters. The tool decrypted simple passwords such as picnic in a few seconds. Cracking hashes doesn't take high-powered CPUs or an experienced hacker. Screen 1 shows L0phtCrack in action.
NT's most popular security controls don't provide much protection against L0phtCrack. The highly touted intruder-lockout feature, which disables the account of a user who enters the wrong password, is effective when someone attempts to access your system by repeatedly trying passwords until one works. However, no NT security controls can detect an L0phtCrack attack that occurs entirely on the hacker's system. For example, if a hacker finds a copy of a server's Emergency Repair Disk (ERD), the hacker doesn't need to access your system to find or test passwords, so you have no way of knowing that your network's security is in danger.
The bottom line is that neophyte hackers can download tools such as L0phtCrack for free from the Internet and gain access to your accounts if they can get a copy of your password hashes. NT stores password hashes in as many as seven locations, and tools such as L0phtCrack can currently find and crack hashes in all but one of the locations. You need to be aware of the risks involved with storing passwords in each location and measures you can take to protect your network from hacker attacks.
The Registry. NT stores its primary copy of password hashes in the HKEY_LOCAL_MACHINE\SAM Registry key. To access these Registry values, you must use the built-in System Account. Configure NT's Schedule service to log on as the System Account and select the Allow Service to Interact with Desktop check box. Use the AT command to run a Registry editor, and drill down into the SAM key. (For more information about using the AT command, see Mark Minasi, "Where It's AT," March 1998 and "A Better AT," April 1998.)
L0phtCrack uses a similar method to retrieve hashes from the Registry. Obtaining hashes from the Registry requires administrators group membership. To protect your system, restrict people to whom you grant membership in the administrators group, and do not let anyone run untrusted programs under an administrator account.
Physical jeopardy. Remember that the Registry consists of standard files called hives. NT dynamically grafts these files into the virtual tree of the Registry. The SAM database is in the %SYSTEMROOT%\system32\config\sam hive file. When NT is running, the SAM database is accessible only to the system. But, if your system partition is FAT, someone with physical access to your system can boot DOS and copy the SAM database to a disk. If your system partition is NTFS, a hacker can load NTFSDOS (which you can download from http://www.sysinternals.com) to gain DOS read-only access to your NTFS partitions and copy the database. Hackers can also copy the database by booting a different installation of NT on your system. If an intruder installs a second version of NT (e.g., to c:\winnt2), all the security features of the original NT installation in c:\winnt are void.
Limit physical access to computers. Disable your systems' ability to boot from removable media devices. Password protect systems' boot settings if your BIOS supports this feature. And, use SP3's Syskey utility to make the SAM hashes more difficult to crack.
Syskey creates a random password encryption key and uses that key to encrypt the hashes in the SAM database. Then, Syskey encrypts the password encryption key with a system key. Administrators can choose among three methods for creating and storing the system key: First, NT can generate a system key using a complex obfuscation algorithm and store that key on the system where the SAM database resides. Second, NT can generate a system key that you store on a disk. (If you choose this option, be sure to create and test backups of the system key diskif you store the system key on only one disk and that disk goes bad, users won't be able to log on to the network.) Third, you can specify a password to serve as the system key. All three methods defeat state-of-the-art hacker tools. The last two choices are more secure than the first choice, but they require user intervention, which can cause problems when servers need to automatically reboot. You can use the second method and leave the disk in the server's drive to eliminate the need for manual reboots, but if the machine isn't completely secure against physical intruders, this option creates another security risk.
ERDs. Your ERDs contain a copy of all your Registry files, including the SAM database. During assessments of clients' security, I often find an ERD lying near a server or on an administrator's desk. How many people have access to your servers or your desk? Do you want to give all those people access to your hashes? Probably not. To protect your ERDs from hackers, set policies that control how many ERDs exist for each system and where administrators store the disks. Also, use Syskey to encrypt your password hashes so that if hackers obtain one of your ERDs, they can't easily recover the hashes.
Rdisk. Rdisk, the program that creates ERDs, uses NT's native compression tool to compress Registry files in the staging directory %SYSTEMROOT%\repair. The directory's default file permissions are weak; NT does not lock this copy of Registry files while the OS is running. For Rdisk protection, use Syskey, give only administrators access to the repair directory, and limit physical access to your servers.
Backups. Hackers can restore system backups to scavenge the SAM database for password hashes. Therefore, you must store backup media in a secure place and closely control who has the Back up files and directories right on your network. By default, members of the administrators, server operators, and backup operators groups can back up files.
The network. When a user connects to a resource across the network or uses a domain account to log on to a workstation, NT uses a challenge/response technique to authenticate the user. The workstation doesn't send the user's password or the password's hash across the network. Instead, the server the user is trying to connect to sends a string of bytes to the workstation as a challenge. The client uses NT's one-way encryption function to derive a hash from the password the user enters. Then, the client encrypts the server's challenge with this password hash. The client sends the operation's result to the server as its response. The server performs the same operation using that user's password hash from the SAM. If the operation's result matches the client's response, the server authenticates the connection.
This challenge/response protocol prevents intruders connected to the network from sniffing clear passwords during authentication. However, readsmb, a program that comes with L0phtCrack 2.0, can derive users' passwords from the challenges and responses that pass across most NT networks. I recently started readsmb in a command prompt window, then I ran a NET USE command in another window to connect to a shared directory on another computer. Readsmb immediately output my username and challenge/response, as Screen 2 shows. I redirected the readsmb output to a file, then used L0phtCrack to derive the password from the hash.
By default, NT LAN Manager (LM) authentication uses both the NT hashing algorithm and the weaker LM hashing algorithm to encrypt challenge/ response sessions. The LM algorithm is weaker for three reasons. First, LM passwords are not case-sensitive. NT converts all passwords to uppercase before using the LM algorithm to hash them. Second, LM hashes can't be longer than seven bytes, so NT divides passwords that are longer than seven bytes into two segments before LM encryption. This division produces two passwords that are shorter and easier to crack than the original password. Third, LM hashing uses the Data Encryption Standard (DES) encryption formula, which is weak by today's standards. NT uses the stronger RSA MD4 encryption formula.
You must use the LM protocol for authentication if you want to connect resources on LAN Manager servers or Windows 98, Win95, or Windows 3.11 systems to your network or support these OSs' clients. (For a more detailed discussion about password hashing and NT's challenge/response technique, see Alan Ramsbottom's NT cryptography FAQ at http://www.ntbugtraq.com.)
If you have many NT clients and servers, the lm-fix hotfix can help protect at least some of your network's authentication requests. Lm-fix is not currently available because of compatibility problems with distributed component object model (DCOM), but Microsoft will probably release a new version of the hotfix soon. (For more information about Microsoft's removal of lm-fix from its Web site, see the sidebar, "Lm-fix: Now You See It, Now You Don't," page 132). Lm-fix adds the LMCompatibilityLevel value to the Registry. LMCompatibilityLevel lets you specify one of the following levels of authentication: level 0, which uses both LM and NT authentication; level 1, which uses only NT hashing unless a server requests LM authentication; and level 2, which never uses LM authentication.
Level 1 reduces but doesn't eliminate a system's vulnerability to man-in-the-middle attacks. A rogue computer can intercept a connection request over a level 1 network and request that the connecting client send it LM authentication. Enabling Server Message Block (SMB) signing might provide protection from this type of attackSMB places a digital signature that clients and servers use to authenticate messages from each other on each message blockbut OSs that don't recognize SMB signing won't be able to communicate with your NT systems if you require signing. (For more information about SMB signing, see Sean Daily, "NT Server Security Checklist, Part 2," page 135; the sidebar "SMB Signing," August 1997; and Microsoft Support Online article Q161372, "How to Enable SMB Signing in Windows NT," at http://support.microsoft.com/support/kb/articles/q161/3/72.asp.)
Level 2 is your most secure connection request option, but it can connect only resources on NT systems. Non-NT clients can't use level 2 security because they're not capable of NT authentication.
To implement lm-fix, load the hotfix on all your network's computers and set the LMCompatibilityLevel value on each computer. If your site includes Win95 systems, you must rely on physical security on LANs and encryption of WAN links to prevent hackers from sniffing the Win95 clients' connection requests.
If you must send LM hashes across the network, most security experts recommend using either 7-character or 14-character passwords. LM hashing of 8-character to 13-character passwords yields weaker second hashes, which hackers can use to try to guess the first hash before they crack it.
Cached credentials. The final place that NT stores password hashes is in a machine's cached credentials. By default, NT caches logon credentials from the past 10 successful logons. NT uses this cache to authenticate users locally when the network is down and no domain controller is available. Without this feature, you can't log on to a computer when the network is unavailable unless you have a local user account on that machine. Credential caching produces another copy of password hashes that hackers can find, and caches on machines that an administrator has recently logged on to contain that administrator's credentials.
Tools such as L0phtCrack do not currently scavenge passwords from machines' credentials cache, but they might soon. Syskey doesn't appear to encrypt this portion of the Registry. (Microsoft documentation doesn't make clear whether Syskey encrypts these hashes.) You need to disable caching on all your machines to protect your network. Set the CachedLogonsCount value in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon Registry key to REG_SZ 0. (Don't make this change using REG_DWORD. For more information about credential caching, see Sean Daily, "NT Server Security Checklist, Part 2," page 135 and Microsoft Support Online article Q172931, "Cached Logon Information," at http://support.microsoft.com/support/kb/articles/q172/9/31.asp.)
Password Quality
You can greatly increase the length of time a hacker needs to crack a password by improving the password's quality. L0phtCrack uses a dictionary to crack one-word passwords in a few seconds, and quality passwords such as Zn5e937o72q204 take only a few days to crack. You can't defeat L0phtCrack's algorithm, so you need to defeat the hacker running the tool.
Make passwords as long as possible with a wide variety of characters. Use 14-character passwords that include mixed-case letters, numbers, symbols, and extended characters that use the ALT-NNNN sequence. (Extended characters can affect compatibility with non-NT systems. Documentation on the problem is sketchy, so I recommend that you test extended characters for compatibility before letting users on non-NT systems include them in passwords for logging on to NT servers.) This strategy increases the number of permutations the algorithm must try before it cracks your hash. Hackers usually start with a small character set to increase cracking speed. If your password uses symbols and extended characters, a hacker's first attempt will probably fail, and the hacker will need to run L0phtCrack using a larger character set, which can take years on a modern PC. The object is to make the intruder lose patience and move on to easier targets. A hacker with enough determination and resources can run a decryption algorithm on multiple machines to reduce the time cracking a password takes, but cracking difficult passwords is prohibitively time-consuming for most hackers. By choosing a long password that uses a range of characters, you can drive hackers to give up before they crack your password or improve the chances that an account's password will change before the hacker cracks the hash.
Password Policy
End users are historically the weakest link in password protection. All the safety precautions I've mentioned won't help if users pick poor passwords such as spouses' names.
NT offers a mechanism for enforcing password policiesnotification packages. A notification package is a simple .dll that NT calls whenever a password changes. Developers can use notification packages to automatically synchronize passwords between an NT network and corresponding accounts in other environments, such as UNIX or NetWare. Notification packages can also reject a password that a user proposes if the password doesn't comply with the notification package's rules. Passfilt.dll, which comes with Service Pack 2 (SP2), is a notification package that enforces rules about password selection, such as password length and the variety of characters passwords use. Passfilt.dll doesn't force users to choose passwords that will take hackers prohibitively long to crack, but you can write a notification package that does. (For more information about passfilt.dll, see Microsoft Support Online articles Q161990, "How to Enable Strong Password Functionality in Windows NT," at http://support.microsoft.com/support/kb/articles/q161/9/90.asp and Q151082, "Password Change Filtering & Notification in Windows NT," at http://support.microsoft.com/support/kb/articles/q151/0/82.asp.)
You might have difficulty convincing users to choose quality passwords, even with controls such as Passfilt. If you can't require everyone to choose 14-character passwords that draw on large character sets, at least require such difficult passwords for administrators, server operators, backup operators, and other critical users. To enforce such a policy, you can create a notification package that enforces different password rules for members of different groups.
Every security-conscious organization needs to define and enforce policies that reflect users' security responsibilities. In addition to standards for password choices, an effective policy needs to address whether users may write down passwords or share passwords with other users and how administrators can determine whether an intruder has accessed an account (by checking the last logon time and monitoring sudden password changes). Administrators also must define procedures for replacing forgotten passwords and for letting technical support personnel log on under other users' accounts to diagnose problems or install software.
Other Password Risks
Notification packages are a double-edged sword. Rogue notification packages can collect password changes for intruders, and NT's default configuration makes such an attack a little easier. The multistring Notification Packages Registry value in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa key specifies which notification packages a system sends when its passwords change. The default permissions for this key limit set value access to administrators and the System Account. However, this limitation doesn't necessarily mean that intruders need access to the key and the file system to load a rogue notification package. By default, NT includes in the value a notification package that doesn't exist on many systems. NetWare's File and Print Services and Directory Service Manager rely on the Fpnwclnt notification package for password synchronization between NT and NetWare. NT includes fpnw.dll in the Notification Packages value regardless of whether you are running the NetWare services that require it. This hole in NT's security means that a hacker can install a password-collecting .dll by putting it in the server's .dll search path. To protect your network, remove fpnw.dll from the Notification Packages value if you don't use it and check permissions on the Lsa key and for the directories that your system path environment variable specifies. (For more information about this security problem, see Microsoft Support Online article Q99885, "Security Issues Occur Due to How WinNT Handles FPNW-CLNT.DLL," at http://support.microsoft.com/support/kb/articles/q99/8/85.asp.)
In addition, NT versions before SP3 support all dialects of SMB, including one that sends passwords in clear text. A hacker on a rogue server can request that NT send a clear-text password, and NT complies. SP3 adds the EnablePlainTextPassword value to the HKEY_ LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters key. EnablePlainTextPassword's default value is 0, which tells SMB not to send passwords in clear text.
Fundamental Changes
NT passwords' fundamental weaknesses lie in the features that enable compatibility with other OSs. You can compensate for these weaknesses by using Syskey, disabling LM authentication over the network, and ensuring that your users select quality passwords. The second two options increase security but reduce a network's compatibility with non-NT clients and servers.
Hackers have many methods for attacking NT passwords, but you can protect your network against each method. Take steps that eliminate or reduce your network's risks, and carefully regulate local LAN segment presence, directory permissions, and physical access to your network.
