The March 31, 1997, EE Times article about the alleged flaw in Windows NT's security has sounded an alarm. In brief, the story asserted that "a reasonably skilled kid" with a PC and a modem could hack NT's passwords. How serious is the security breach the article exposed? In an official statement (http://www.microsoft.com/security/eetimes.htm), Microsoft wrote that the only true threat to NT's security is from someone first obtaining an administrative account and password. Microsoft's solution: Protect the administrator accounts. Contrary to Microsoft's statement, not just administrators can compromise NT's security.

The crux of the issue is who has access to the Security Accounts Manager (SAM) and Security hives of the NT Registry. NT stores user passwords as part of hash codes in the SAM hive of the Registry. (For more information about password hash functions, see Mark Minasi, "Windows NT Logons," June 1997.) The Security hive contains security information for the local computer, including user rights, password policy, and the membership of local groups. The SAM hive needs the Security hive to work properly. If hackers can access the SAM hive, they can use a utility such as PWDUMP available at http://www.nmrc.org/files/nt/index.html. As Screen 1 , shows, PWDUMP changes permission on the Registry to let users read the SAM. PWDUMP provides a printout of the hash codes and, therefore, makes them accessible to password crackers such as NT Crack and L0phtCrack. Here are steps a potential hacker could follow to crack NT's security, and what you can do to prevent such attacks on your system.

HACKER GOAL ONE:
Gain Access to the SAM
Users can gain access to the SAM and Security hives in several ways. Microsoft says the best way to protect your NT systems is to protect the administrator accounts, but administrators are not the only users who can access the SAM and Security hives. Server operators, backup operators, and even ordinary domain users can view and dump hash codes from the Registry. Protecting administrator accounts is not enough.

By default, no user has the proper permissions to access or even view the NT SAM. However, the SAM and Security hives are like other files. Users who have permission to copy the Registry files--such as users who might have to back up the Registry--can copy and manipulate these files on a whim.

If you log on as a backup operator, however, you can't just copy the SAM and Security hives. The Registry is open while NT is running, and a sharing violation occurs when you attempt to copy the files. However, the Regback utility on the Windows NT resource kit CD-ROMs lets anyone in the administrator, server operator, or backup operator local groups copy the open Registry.

The list of potentially dangerous users, however, includes more than these three groups. Regular domain users can invade NT security if NT is on a FAT volume and they have permission to restart the machine. All they have to do is boot to DOS, copy the SAM and Security hives from the %SystemRoot%\System32config directory, and they're in business.

In general, if NT is on an NTFS volume, domain users can't boot DOS and copy the hives. But NTFSDOS, a utility written by Mark Russinovich and Bryce Cogswell, lets users mount the NTFS volumes in DOS. (Mark Russinovich and Bryce Cogswell present one view of NTFSDOS and Joel Sloss another view in point and counterpoint articles in the September 1996 issue.) Run NTFSDOS, go to the %SystemRoot%\System32\config directory, and copy the hives.

Microsoft says that true security is physical security. Following Microsoft's advice, lock the machines away, and remove ordinary users' permissions to restart the computers. If users can't restart the machines, the possibility of rebooting to DOS on a FAT volume or using NTFSDOS is no longer a threat.

Is NT secure now? Ordinary domain users can't copy the open Registry because the action will cause a sharing violation. Nor can users back up the system because they don't have permissions associated with administrator, server operator, or backup operator accounts. But a fundamental feature of NT's built-in availability is the Repair directory. After a successful installation and each time you run the Rdisk utility, NT stores a backup of the Registry in %SystemRoot%\Repair. The backup files aren't open, and users can easily copy them if they can log on locally or if the directory is shared. By default, the NTFS permissions don't protect the Repair directory. All users have read control, and read control offers enough permission to copy files.

For ordinary users to obtain the SAM hive that contains passwords, they must access the current version of the Registry. The Registry is vulnerable in at least two ways. First, even though NT doesn't back up the Security and SAM hives by default when you run Rdisk, a copy of the SAM from the original NT installation remains in the Repair directory. If the administrator has not changed the administrative password since the original installation, the password is at risk. Second, many administrators use the rdisk /s command, which includes the Security and SAM hives in a backup to an unprotected Repair directory (for more information about the Rdisk utility, see Michael D. Reilly, "The Emergency Repair Disk," January 1997).

In summary, here's how you can prevent an ordinary domain user from gaining access to the SAM and Security hives on your servers:

* Don't permit local logon to servers.
* Use NTFS volumes instead of FAT volumes.
* Physically secure the servers.
* Change the default permissions of the Repair directory.
* Secure your Emergency Repair Disks and tape backups.

Remember, users can still access their local machine's Registry through the Repair directory or an Emergency Repair Disk and attempt to crack the local machine's administrator password. One way to prevent this attack is to convert to NTFS and set more restrictive permissions on each workstation's Repair folder.

HACKER GOAL TWO:
Dump the Hash Codes
Even after users have copies of the SAM and Security hives, they can't easily view hash codes. They have to log on to an NT machine as Administrator and dump the hash codes with PWDUMP. If they manually copy both Registry files into their own Registry, NT will use the hijacked SAM. Although users don't have administrative privileges at work, they are administrators on their home PC. From their home PC, they can dump the hash codes and, at their leisure, perform as many dictionary attacks as they need to find the passwords.

To copy the hijacked SAM to a local Registry when NT is on a FAT volume, users just boot to DOS and copy the file. If NT is on an NTFS volume, users can use Regrest, another utility on the resource kit CD-ROMs. However, the hives in the Repair directory or from an Emergency Repair Disk are compressed, and a compressed Registry doesn't work in NT. But the compression algorithm isn't difficult; you can easily uncompress those files with the Expand command in %SystemRoot%\System32.

If users replace the SAM and attempt to log on as the hijacked Administrator, they overwrite their personal administrative password and don't know the new stolen password. However, the utility NT Locksmith, available at http://www.winternals.com, lets you change the local administrator password. Running this utility requires physical access to the NT machine. Most people do not have physical access to servers at work, but they have access to their home PC. After users change the password, they can log on locally and dump the hash codes from the hijacked SAM.

HACKER GOAL THREE:
Crack NT's Passwords
Once users have the hash codes, they can use NT Crack, L0phtCrack, or a similar utility to perform a dictionary attack against NT, as you see in Screen 2. The outcome of the password crack depends on the quality of the wordlist, or dictionary, hackers use to perform the crack. The more words, dates, numbers, and wordplays that are in the list--and the more complex they are--the better the chance for a successful crack. Therefore, a good password security policy greatly reduces the likelihood of a successful crack.

For good password security, you can prohibit blank passwords and require a certain password length, for example a six-character minimum. Require complex passwords, usually a random selection of letters and numbers. NT's User Manager won't let you force complex passwords. However, you can set all your users' passwords manually and not let users change them. Or Screen 3 shows how you can use a resource kit utility, Passprop, to require a simple level of password complexity. In addition, you can make passwords expire after a certain period and keep a password history so users can't use the same password repeatedly.

Is All Hope Lost?
My goal here is not to show hackers, step by step, how to break into NT. Rather, I want to call NT administrators to arms to strengthen their network's weakness before someone takes advantage of it. The best way to defeat the enemy is to understand the enemy's tactics and know your weaknesses.

Is NT insecure? It is open to exploitation. But strong security policies will greatly reduce the possibility of a security breach. PWDUMP, NT Crack, and L0phtCrack are dangerous utilities. But these utilities are useless until someone can gain access to NT's Registry. Microsoft has not protected NT's Registry as well as it might have. You can counter this weakness by implementing stricter security on the active Registry and especially the Registry backups--tape backups, the Repair directory, and Emergency Repair Disks. If the Registry is secure, NT is secure. And if NT is secure, you can sleep better at night.