Simple steps to restrict intruders' access to your accounts
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.