Reinspecting Password, Account Lockout and Audit Policies

Reinspecting Windows sounds like reinventing the wheel, but reviewing password policy, account lockout policy and audit policy proves that auditing is not a one-time exercise; rather, it, must be a continuous, ongoing process, especially when new versions are introduced. It is true that even the mostly widely used operating system (OS) from one of world’s leading companies has many areas that need to be fixed and improved.

Operating System Passwords

A password for an OS is normally considered to be the first line of defense. In too many cases, the OS password is actually the one and only line of defense, especially when single sign-on is implemented or when Active Directory (AD) authentication is integrated with other applications or databases. This opens up an organization to the risk that a password-guessing attack could be used to gain unauthorized access to the systems. Two common forms of guessing attacks are brute force, where the malicious user tries every possible combination of characters to guess the user’s password, and dictionary attacks, where different dictionary words are tried one by one.

Password Policy

Password policy is a very basic control to avoid easily guessable passwords. The screen shown in figure 1 is used to set or display the Domain Password Policy in Windows Server 2012.

Usually, security and auditing professionals trust in what is given by large companies, such as Microsoft, in these parameters; but upon verification, it proves important to audit all situations, regardless of the prominence of any one product or company.

Complexity Requirements
One of the restrictions of password complexity requirements (figure 2) is that a password must not contain parts of the user’s full name that exceed two consecutive characters, but for a user using a full name, e.g., Faisal, a password having five consecutive characters, is possible.

Furthermore, this parameter requires passwords to be at least six characters in length, as shown in figure 2, but this parameter alone does not enforce a minimum password length of six characters. A password of even three characters (e.g., a.1 or Aa1) can be set.

Other requirements of password complexity include requiring characters from at least three of the following four categories:

1. Uppercase letters (A-Z)
2. Lowercase letters (a-z)
3. Numbers (0-9)
4. Special characters (e.g., !, #, $)

Yet passwords can contain dictionary words leading to easy-to-guess passwords, such as Password1, CountryName1 and CityName1.

Enforcing Password History
The enforce-password-history parameter ensures uniqueness of new passwords, but it accepts new passwords with a difference of only one character.

Similar new passwords can be set, e.g., Password1, Password2, Password3.

Minimum Password Length
Similarly, the minimum-password-length parameter ensures the length of the password, but there is no control over repetition of characters. So passwords with repeated or adjacent characters can be set even when complexity is enabled. With a minimum password length of eight characters, passwords such as Aaaaaaa or Ab123456 can be set.

Recommendations Related to Password Policy

Due to the potential for implementing easy-to-guess passwords, users should be made aware that these kinds of easy passwords need to be avoided. Furthermore, the minimum-password-length parameter should be set, even when the password-must-meet-complexity-requirements parameter is enabled.

Server Password Policy in Other Operating Systems

The Windows OS is used mostly for client machines. Thus, Windows Domain Controller is used to implement the security policies on these client machines. The same policies are also applied to all Windows-based servers on the domain. Other server OSs provide many additional parameters to avoid the previously discussed easy passwords for servers’ users.

IBM OS/400 includes the following:

1. QPWDRQDDGT—Prevents passwords with too few numbers
2. QPWDLMTREP—Prevents passwords with repeating characters, e.g., Aaaaa
3. QPWDLMTADJ—Prevents passwords with adjacent digits, e.g., Abc123

Note that the WRKSYSVAL *SEC command is used to get these values.¹ These parameters can be applied in an AS400 Server using the CHGSYSVAL command.

Oracle Solaris and IBM AIX include the following:

1. MINALPHA—Prevents passwords with too few letters
2. MINDIGIT—Prevents passwords with too few numbers
3. MINLOWER—Prevents passwords with too few lower case letters
4. MINUPPER—Prevents passwords with too few upper-case letters
5. MINNONALPHA—Prevents passwords with too few nonalphabet characters
6. MINSPECIAL—Prevents passwords with too few special characters
7. MAXREPEATS—Prevents passwords with repeating characters
8. MINDIFF—Prevents very similar old and new passwords
9. DICTIONLIST—Contains a list of common words that cannot be used as part of a password, e.g., country, city, company, departments, designations²

These parameters can be applied in a Solaris or AIX server by uncommenting the lines (removing # from start of line) and specifying the appropriate values after = in the file: /etc/default/passwd.

Account Lockout Policy

Another possible defense against password-guessing attacks is enabling an account-lockout policy, which means the account will be locked after a specified number of invalid or failed login attempts.

As an example, in figure 3, the account lockout threshold is set to three invalid attempts. When an incorrect password is entered, the message shown in figure 4 is displayed.

The message in figure 4 continues to display for up to the previously set maximum of three incorrect passwords. After the fourth attempt, the account is locked. After an account is locked, entering either a correct or incorrect password results in the same message being displayed (figure 5), so the person entering the password has no way of knowing if the password was correct. Unfortunately, an unpublished vulnerability in Windows can bypass this protection leaving the system at risk.

Visual Basic (VB) language has a function that behaves abnormally for user authentication. If the password entered into the function is not correct once the account is locked out, it gives the error message: “The specified network password is not correct.” As soon as the correct password is provided, this function realizes that the account has been locked out, so the message displayed reads: “The referenced account is locked out and may not be logged on to.”

Because different messages are displayed for the wrong password and the correct password, this function can be used to continue to guess the password, bypassing the account lockout protection. The abnormal behavior of the change-password function has been observed in Windows Server 2012, Windows 8, Windows 7, Windows Server 2008 and Windows Server 2003.

Risk Related to the Change-password Function
The following risk can result from a weakness in the change-password function:

• A password-guessing attack can be launched by one domain user against all domain users.
• A password-guessing attack can be continued even after the account lockout threshold.
• A simple user can execute this function without administrative privileges.
• There is no delay between unsuccessful attempts, whereas in the graphical user interface (GUI), a delay of 30 seconds is expected twice after five unsuccessful attempts.
• Once the password is guessed, it may be able to be used after just 30 minutes. Thirty minutes is the account lockout duration’s default value and is the recommended value by Microsoft.³

The latest next-generation firewalls or intrusion prevention systems (IPS) do not have out-of-the-box rules to recognize this attack.

Recommended Countermeasures
The following countermeasures can be implemented to reduce the previously mentioned risk factors:

1. The IPS should be configured to prevent this attack by adding the rule that if there are multiple failed account management requests from one source within one second, it should be treated as an attack.
2. Account lockout duration should be set to infinite.
3. Accounts should be unlocked only after proper investigation.
4. Once unlocked, password reset should be required.

Audit Policy

Audit policy is a detective control to log password-guessing attempts (figure 6).

The audit-account-logon-events parameter logs events of credential validation, as shown in figure 7, but when the VB function is used, credential-validation events are not logged.

Even if Microsoft’s recommended best practices related to account logon and account management are implemented, no failed logs are available related to the attack (figure 8).

Whereas, when the account is locked out normally, through the GUI, the logs for audit failure, logon and credential validation are available (figure 9).

Recommendations Related to Audit Policy
In the audit policy, audit account management should be set to “Success & Failure.” In the case of account lockout, these logs should be investigated before unlocking the account.

Conclusion

Auditing is not a one-time exercise, but rather it is a continuous and ongoing process no matter what system or provider is in use. Even the basics should be reviewed periodically to avoid a false sense of security.

In the example described previously, Windows is shown to have some limitations in password policy. Thus, some countermeasures are needed. For highly critical servers, other operating systems may be considered, such as IBM AIX, Oracle Solaris or IBM OS/400. Further, VB has a function with abnormal behavior. This function can be used to continue to guess the password, bypassing the account lockout protection. Countermeasures related to IPS, Windows Account Lockout Policy and Windows Audit Policy should be implemented to reduce risk.

References

• Microsoft, “Configuring Account Lockout,” Technet, http://technet.microsoft.com/en-us/library/cc737614(WS.10).aspx
• Microsoft, “Troubleshooting Account Lockout,” Technet, http://technet.microsoft.com/en-us/library/cc773155(WS.10).aspx
• Microsoft, “Configuring Audit Policies,” Technet, http://technet.microsoft.com/en-us/library/dd277403.aspx
• Microsoft, “Auditing Security Events Best Practices,” Technet, http://technet.microsoft.com/en-us/library/cc778162(WS.10).aspx

Endnotes

¹ IBM, System Values That Apply to Passwords, http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Frzarl%2Frzarlpwdsv.htm
² Oracle, Authentication and Password Management Module, http://docs.oracle.com/cd/E23824_01/html/821-1474/pam-authtok-check-5.html
³ Microsoft, “Recommended Account Lockout Settings for Medium Security,” http://technet.microsoft.com/en-us/library/cc737614(WS.10).aspx

M. Faisal Naqvi, CISA, AMBCI, CISSP, ISO 27000 A, ISO 27000 MI, has more than 15 years of IT security auditing and implementation management experience. He has managed various projects related to enterprise resource planning (ERP) systems. He is a regular speaker on information security and audit at many conferences, seminars and workshops.