Administrative Password Best Practices
This article applies to: Security Essentials for IT Professionals
The compromise of an administrative account represents two major risks unless specific steps are taken. The first risk, of course, is access to all data and resources on the compromised system. The second is disclosure of credentials to other accounts, including those for other systems, which can allow the compromise to spread. It is this latter risk this document is intended to address.
Often, administrative accounts are compromised without the attacker knowing the password to the account. Any number of direct vulnerabilities or the leverage of access to unprivileged accounts can yield administrative access. Generally, the first step is to ensure that the attacker can revisit the compromised system through a backdoor. The second order of business is compromise of the credentials to one or more accounts for use against other systems on the network.
To understand the risk to those passwords, we have to understand how contemporary operating systems store them and the relative forces required to recover passwords in their human-readable form.
Windows password storage is, in many ways, considerably weaker than other operating systems.
Windows stores local passwords in the Security Account Manager (SAM). This file is readable only by administrator or administrative processes and, in later versions of Windows, is protected by a key stored on disk in the SECURITY file.
Passwords are stored in the SAM in irreversible hashes in one of two forms. The old LANMAN form, retained to support the needs of Windows 98 clients, is created by converting the password to upper case characters, splitting it into two seven character segments, and hashing those independently. The modern form is simply a hash of the password, maintaining its case sensitivity. It is the legacy storage method that creates the greatest risk to Windows password storage. This is because an attacker is faced with the much simpler task of recovering two smaller passwords rather than one larger password. Once that is done, it is a simple matter to test permutations of character case until the modern, case-sensitive password is found.
Several tools, most notably SAMdump, exist to extract authentication information from the SAM in human-readable form. A typical representation of the SAM, starting with the administrator account looks something like:
Administrator:50:eeb854f :dbd555 :::
SAMdump-like tools and the system compromises that are prerequisites for their use are not the only risk of password hash disclosure. Many of the existing Windows protocols, including SMB, RDP, and PPTP expose to network eavesdroppers easy opportunities to recover the hash during normal authentication transactions.
There are many tools currently available to generate rainbow tables of hashed password storage mechanisms, among them Windows hashes. These tools employ the same algorithms used for password storage to precompute hashes for all combinations of characters, numbers, and symbols. The password length to which the process can be applied is limited by time and disk real estate, but in this age of using botnets to distribute computational loads, it is felt that even passwords out to 15 characters with significant complexity are vulnerable. Once an attacker has possession of the contents of the SAM, matching that to the original password using precomputed rainbow tables often takes minutes.
Most UNIX operating systems store passwords in hashed form, in a file or database inaccessible to non-root users. If root has been compromised on a suitable system, these hashes are subject to attack.
The key difference for UNIX operating systems is the hash is first salted with a random value intended to greatly increase the number of possibilities an attacker must try. The use of salted hashes renders rainbow-like efforts useless due to the greatly increased number of combinations. With an unsalted hash such as Windows, each password has exactly one matching hash. With a salted hash like those used in other operating systems, a password may have millions of matching hashes. That leaves an attacker with no option but conventional password cracking techniques. Each hash is tested against a possible password until a match is found. The salted-hash algorithms in use today seek to make the cracking process as computationally costly as possible. This workload is often several orders of magnitude slower than pre-computing rainbow tables. The primary risk to complex, salted hashes exists when weak passwords are chosen. Simple passwords, consisting of words, combinations of words, simple substitutions, or short passwords, are easily recovered. The ease of recovery varies with the hashing approach. Traditional UNIX crypt() used a two-character salt and a DES algorithm. This format is used by Solaris, OSX, and a few other UNIXes. Modern CPUs can try millions of password combinations per second against such a format. Where the operating system allows (Linux, the BSD variants), stronger SHA and MD5-based storage using eight character salts are far slower to attack.
As with Windows, the use of network services where the passwords are not well protected can result in instant disclosure to an eavesdropper. Telnet, FTP, HTTP, and any other protocol not protected by strong encryption (SSH or SSL) present a serious risk.
For these reasons, synchronizing administrative passwords across a large group of machines is extremely dangerous. The compromise of any system immediately exposes all systems. A combination of the following three strategies is recommended:
- Password complexity. On any operating system, complex passwords are vital to thwart the most common attack method we see: repeated password guessing over an open service (SSH or SMB). In general, complexity must be coupled with length.
- Discontinuing the use of legacy password storage. Long, complex passwords offer good security but are vulnerable to recovery if they are stored using a weaker methodology. Discontinuing the use of legacy password storage, either LANMAN hashes on Windows systems or crypt() variants on Solaris or similar UNIXes, makes complex passwords much more resistant to attack.
Unique passwords for each system. This strategy recognizes that compromises may occur even on the best protected systems and seeks to confine the attacker to the first victim host. This approach is so often used that it is necessary for each password to include information not available from the operating system itself, concactenated with a strong password known only to the administrator. For example, passwords could include one or more of:
- Property tag number
- System serial number
- Building and office number
Weaknesses in MS-CHAPv2 and PPTP: http://www.schneier.com/paper-pptpv2.html
Recovery of Windows hashes from PPTP sessions: http://asleap.sourceforge.net
John the Ripper: http://www.openwall.com/john