Windows Passwords Overview
Windows operating systems offer several different methods of storing password information. The primary goal of Windows password storage is to provide a secure method of storing passwords on the operating system or within Active Directory and offer a mechanism to authenticate users and services. Refer to Chapter 2, Active Directory – Escalation of Privilege, for more information about the attacks against Active Directory. Additionally, password storage systems also allow administrators to define rules and apply policies to ensure passwords are complex to protect systems against unauthorized access. As part of these policies, administrators can enforce lockout thresholds, durations, reset policies, and many other options to help strengthen password implementations.
Security Accounts Manager
The Security Accounts Manager (SAM) is a vital component of how Windows stores passwords locally on the computer system. Storage of user and account information in the SAM database provides system users the ability to authenticate to the local system if an account has been created for them. Passwords stored in the SAM database are stored in either LAN Manager (LM) hash or NT LAN Manager (NTLM) format depending on the policies implemented and enforced for password storage.
During normal operation of a Windows system, the SAM database cannot be copied due to restrictions enforced by the operating system kernel. The SAM database is stored in two places within Windows: %systemroot%system32configsam is the location of the main storage for passwords and %systemroot% epairsam._ is a backup of the main file in the event that recovery is required for a repair process.
Offline attacks against the contents of the SAM database are possible because contents of the SAM database are also stored in memory. A few examples of tools that can be used to obtain a copy of the stored hashes are Metasploit,[D] fgdump,[E] and Cain & Abel.[F]
Ewww.foofus.net/fizzgig/fgdump/
System Key (SYSKEY)
The system key (SYSKEY) was first implemented in the Windows NT 4.0 platform as an optional feature and is enabled by default while starting the Windows 2000 operating system. The implementation of SYSKEY was intended to protect passwords while the operating system is not running by encrypting the data stored in the SAM database with a 128-bit encryption key. During the boot process, the SYSKEY is loaded into active memory to allow access to Local Security Authority (LSA) secrets, SAM passwords, system recovery, Active Directory, and other passwords. If the SYSKEY is corrupt or not present, the operating systems will not be able to decrypt the SAM database and users will not be able to log on to the system. Several different options exist for implementing and refining how SYSKEY is used in your environment. Some of the options are discussed in the section “Defenses against Windows Password Attacks.”
LAN Manager Hash
LAN Manager hash (LM hash) is used as the method to store passwords within the Windows operating system in a encrypted form as an alternative to storing passwords in clear text. When a password is less than 15 characters long, both an LM hash and an NTLM hash are generated and stored in the local SAM database or in Active Directory. In the event a password is more than 15 characters long, an LM hash cannot be created and thus one will not be stored for the password. This process occurs when a new account and password is created or when a change is made to an existing password. One of the downfalls of an LM hash is that it is easy to brute force the password to obtain the clear-text equivalent in a fairly short amount of time. This is due to the way Windows implements and stores the passwords and how they are encrypted. In recent versions of the Windows operating system, storage in LM hash format is disabled by default and administrators will need to enable LM hash storage in order to use this type of storage.
To create an LM hash, Windows will accept a password with a length of less than 15 characters. The first step in the creation of the LM hash is to convert the entire password to uppercase. For example, if a user enters a password “mypass,” it will be converted to “MYPASS.” In the next step, the password's length will be evaluated and if the length of the password is less than 14 bytes, it will be padded with NULL bytes to make it 14 bytes long. Once the password length is 14 bytes (the password length plus the NULL bytes if required) it will be split into two parts of 7 bytes each. The next step in creating the hash involves multiple operations using the Data Encryption Standard (DES) encryption algorithm.
alt1 Tip
An in-depth review of DES algorithm and how it operates can be found by visiting the National Institute of Standards and Technology Web site and reading FIPS PUB 46-3.G
Both halves of the padded passwords undergo routines using the DES algorithm and ultimately produce two 8-byte encrypted hashes that are then joined together to create a 16-byte hash. This 16-byte hash is the LM hash that is then stored in the SAM database.
Some of the weaknesses dealing with how Windows creates and stores is a direct result of its implementation. One of the weaknesses is how the password is calculated and stored. Knowing the overall hash is the result of combining two small hashes means an attacker needs only to perform cryptanalysis attacks against two smaller hashes as opposed to one larger hash requiring more time and computing power. Another concern results from the limited key space and the process of converting all alphabetic lowercase letters to uppercase. In addition to these weaknesses, there is no salt used to introduce further randomization of the resulting stored hash.
alt1 Tip
Values can be added to a password or hash to increase the complexity and reduce the likelihood of a successful password attack. This value is sometimes referred to as salt.
Knowledge of these weaknesses and how Windows generates and stores passwords has allowed researchers to develop tools that make reversing the passwords trivial. If an attacker is using precomputed cracking tables, many passwords can be cracked in seconds and most can be cracked in just a few minutes. An example of this type of attack is covered in the section “Dangers with Windows Password Attacks.”
alt1 Warning
Cracking passwords repetitively and knowing that Microsoft does not salt the passwords allow attackers to identify some passwords just by looking at the hash. This is because without a salting routine the algorithm used will always result in the same hash for a password.
The example below is the hashed value for a blank password stored as an LM hash:
aad3b435b51404eeaad3b435b51404ee
The next example is a hashed value for the word “password” stored as an LM hash:
e52cac67419a9a224a3b108f3fa6cb6d
After compromising a system, an attacker can often look at the leading four or five characters and determine a hash starting with “aad3b” is a blank password and a hash starting with “e52ca” is likely the password of “password.” This knowledge may allow attackers to continue attacks against the organization without having to crack passwords at all. Unfortunately, although this example talks about blank passwords and using the word “password” as a password, from the author's experience this is encountered all too often during penetration tests.
NT Hash
The NT LAN Manager hash, also known as NT hash, NTLM hash, or Unicode hash, is a password hashing mechanism that encrypts passwords using the MD4 hashing algorithm and supports passwords up to 128 characters long. The NT hash also supports both upper- and lowercase characters. Similar to the LM hash, the NT hash does not perform or implement a salt routine. The NT hash is considered more secure than the legacy LAN Manager hash due to its use of the MD4 algorithm for converting plaintext passwords into a hashed format. Cracking NT hashes does take more time than the legacy LAN Manager hash, but it can still be cracked.
LSA Secrets
LSA secrets are one of the hidden, or not so hidden, jewels of password storage on Windows operating systems. Windows sometimes stores passwords for services and cached credentials in the HKEY_LOCAL_MACHINESecurityPolicySecrets registry key. Within this registry key, individual registry keys are created for each secret stored within the system.
By default, access to the registry key is limited to the system account; however, various methods and tools can be used to view and interact with the LSA secrets. Some of the information stored in each registry may include remote access credentials, cached system credentials, SQL Server service passwords, and Web user passwords. UTF-16 string format is used to store passwords within the LSA secret protected storage. Application Programming Interfaces (APIs) are available for use by applications to create and store information as LSA secrets keys.
Often attackers will compromise systems by using buffer overflow exploits and obtain a copy of the local SAM database hashes, crack the hashes offline, and build a password list. However, an attacker may also decide to “dump” the LSA secrets stored on the compromised system to obtain even more passwords than that are stored in the SAM database. Depending on how many services are configured and on the use of the system, an attacker may be able to acquire a significant amount of passwords to use against other parts of the network. In cases where administrators reuse passwords, this may lead to compromising many systems and possibly the entire domain.
alt2 Epic Fail
Although the topic coverage, thus far, has provided valuable information about password storage and how Windows controls and protects access to passwords, never forget humans have their own way of storing passwords. No matter how much an organization tries to protect passwords by implementing robust controls, the human element can have disastrous effects on network security initiatives.
As security professionals, we are often called upon to provide reviews of physical security controls protecting organizations' assets. During assessments, security analysts will frequently conduct after-hour sweeps of businesses to identify passwords stored in common places, customer information left unsecured, and sensitive information that may have been discarded in the regular trash instead of approved shredding receptacles.
It is still very common to find passwords written down and stored in unsecured locations. People are becoming wiser and not storing them under keyboards and mouse pads as much as they used to. However, some of the most popular storage place from our experience includes desk drawers, in front of or filed under the letter “P” in a Rolodex, and tucked away in personal day planners. Most passwords are still left unsecured and within an arm's reach of the computer keyboard.
Password and Lockout Policies
Password and lockout policies are rules an administrator can impose on how the Windows operating system or Windows domain handles user logon attempts and password implementations. These rules can be defined on a computer locally or globally by modifying the domain password policies. Administrators can modify default password and logon policies to help protect systems and the domain from password attacks. Some of the policies that can be modified are defined in Table 1.1.
Table 1.1. Password and lockout settings
| Enforce password history | Controls how many different passwords must be used before a user is allowed to use a previous password again |
| Maximum password age | Enforces how long a user can use the same password before requiring the user to change it |
| Minimum password age | Defines the minimum amount of time a user must keep a password once changed. Prevents users from abusing the “Enforce password history” by changing their password many times in row so they can use previous passwords sooner |
| Minimum password length | Defines the minimum number of characters required for a password |
| Password must meet complexity requirements | Forces users to use stronger passwords by implementing strict password creation rules. Some of the requirements include using upper- and lowercase characters, meeting a minimum length requirement, using numbers in the password, and using special characters, such as !, *, %, $, and # |
| Account lockout threshold | Determines the number of failed logon attempts before the account is locked |
| Reset account lockout after | Determines how many minutes the system will keep count of failed attempts. Example: If set for 30 minutes, it will reset the failed attempt count every 30 minutes and the “Account lockout threshold” count will be set back to 0 (requires the “Account lockout threshold” to be enabled and set) |
| Account lockout duration | Determines how many minutes the account will remain locked out if the lockout threshold is met (requires the “Account lockout threshold” to be enabled and set) |
Understanding how to manage these types of policies can help administrators reduce the chances of a successful password attack. More details about policies are discussed in the section “Defenses against Windows Password Attacks.”
How Windows Password Attacks Work
Understanding how Windows stores passwords and the knowledge of some common attack methodologies can help attackers identify weaknesses and opportunities for obtaining credentials stored on Windows operating systems. Several different approaches can be taken to gain access to Microsoft operating systems depending on the environment the attacker is in and the state of the networks' existing security.
Many times attackers are able to gain access to passwords and password hashes stored on Microsoft operating systems by leveraging vulnerabilities present due to the lack of a consistent patch management methodology. In organizations where effective patch management policies are not developed or followed, the likelihood of an attack resulting in an attacker gaining access to systems and obtaining passwords is significantly increased. This threat is further increased when operating systems are missing patches and stable exploit code is readily available to leverage the vulnerabilities present on operating systems. Exploit code for many Microsoft operating systems can be found within tools such as Metasploit and at public disclosure sites such as Milw0rm.[H]
alt1 Warning
Although Metasploit and Milw0rm provide access to excellent quality exploits for attackers and penetration testers, it is important to understand these resources are not the only ones available. Many independent researchers publish exploits on personal Web sites and other locations for use by anyone who may need them. Exploit code may also be available at some of the popular vulnerability disclosure Web sites, such as SecurityFocus,I Secunia,J packet storm,K and OSVDB.L Exploit code is also sometimes referred to as Proof of Concept code or PoC.
Iwww.securityfocus.com/vulnerabilities
In some sectors, vulnerability research and exploit development is conducted purely to maintain a competitive business advantage. Companies that offer penetration testing services will often identify new vulnerabilities during assessments and develop exploits and tools to leverage the vulnerabilities. These exploits may be developed within the organization and are the property of the company that has developed them. Companies that provide penetration testers with penetration testing and exploitation tools will often develop exploits as a core part of a service offering.
Malicious attackers may find vulnerabilities and develop exploits used for gaining access to systems without ever disclosing the vulnerabilities to the system vendors. This allows attackers to leverage the vulnerabilities over long periods of time and against many systems since the vendor and public may not be aware of the vulnerabilities that exist.
During the footprinting and the fingerprinting phases of network attacks, an attacker will identify target systems and operating system types to determine what the network landscape looks like. This information gathering also allows the attacker to determine what types of attacks may be fruitful during the exploitation phases of an attack. Part of determining the exploitability of password attacks against Windows operating systems includes identifying system password policies. These policies, as explained in the section “Windows Passwords Overview,” determine if an attacker can or will perform password guessing, dictionary, and brute force attacks against the operating system.
Ineffective lockout policies may allow attackers to leverage the use of password attacks to gain access to the operating system. If an attacker is successful and has gained administrator-level credentials, he may be able to obtain additional information including the contents of the SAM database or LSA secrets. Additionally, attackers may obtain full unrestricted access to other files that may contain passwords, such as batch files, scripts, e-mail storage, and documents created by users to store passwords.
alt1 Note
After an attacker has gained administrator-level access to the operating system, common hacking and penetration testing tools can be used to obtain the username and password hashes stored in the SAM database. Why would an attacker want to do this if they already have a local administrator account? Many administrators are creatures of habit and tend to take the easy approach to password management where possible, especially when managing many servers, computers, and devices within a network. Frequently, network administrators will reuse passwords across the network to reduce the burden of remembering many passwords and to simplify management of systems. Many administrators will reuse a standard password for all local administrator accounts on end-user systems and will reuse a separate password across server-based systems.
Obtaining and cracking the passwords from a compromised system allows an attacker to build a comprehensive list of possible accounts and passwords that can be used on other parts of the network. The password list can be used against devices such as routers and switches or even against domain user accounts that may use the same password for service accounts.
Additionally, depending on how many passwords are obtained an attacker may be able to identify a common convention for password construction. For example, let's assume we obtained the following passwords:
Would it be too much of a stretch to guess the passwords for the Oracle database if an attacker needed to?
Scripts used for automation of tasks and conducting maintenance are great for simplifying administrative tasks and freeing up time so administrators can focus on other initiatives. However, hard-coding username and passwords within these types of scripts can allow an attacker to view the passwords and add them to their password lists. It is common for penetration testers to search for batch files, database maintenance scripts, and other forms of automation to learn more passwords for further attacks.