You must be logged in to post a comment to this blog.
ISACA > Journal > Journal Author Blog > Posts > Security Flaws With the Windows Operating System
Security Flaws With the Windows Operating System
Muhammad Faisal NaqviMuhammad Faisal Naqvi, CISA, AMBCI, CISSP, ISO 27000 A, ISO 27000 MI
 
My recent ISACA Journal article discusses some security flaws in Windows. The errors are related to fundamental components of security, such as password, account lockout and audit logs. These weaknesses have existed since 2003 and are present in all of the latest versions of Server and Client Windows. Windows is one of the leading operating systems for personal computers (PCs) and servers and is also used to implement security on PCs and servers within an enterprise. The professionals who are responsible for managing and auditing the computer security rely on security measures that Windows has explained are sufficient, but in reality have their weaknesses. These discrepancies may lead to a false sense of security.
 
One discrepancy is related to password policy. Windows explains that enabling password complexity, length and history ensures a strong password, but in some cases, a user can set a password meeting these criteria that can still easily be guessed by another person.

Account lockout policy is a countermeasure against password guessing. This policy will lock the account after a specified number of invalid or failed login attempts. But this policy can be easily bypassed using the following technique:

  • A password-guessing attack can be launched by one user against all other domain or local users.
  • A password-guessing attack can be continued even after the account lockout threshold.
  • A simple user can launch this attack 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 used after 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.
Another discrepancy is related to audit policy. Windows explains that enabling audit-account-logon-events logs events of credential validation, but credential validation through the previously mentioned technique will not be logged. Even if Microsoft’s recommended best practices related to audit policy are implemented, no failed attempts will be logged related to this attack.
 
The majority of the above-mentioned weaknesses can be prevented with the following compensating controls:
  1. Users should be made aware of the criteria of strong passwords.
  2. Multifactor authentication (e.g., one-time passwords, public key infrastructure, tokens, biometric) should be implemented.
  3. The intrusion prevention system should be configured to prevent this kind of attack by adding the rule that if there are multiple failed account management requests from one source within a few seconds, it should be treated as an attack.
  4. The account lockout duration should be set to infinite.
  5. In the audit policy, audit account management should be set to success and failure.
  6. Administrators should unlock accounts only after a proper investigation of logs.
  7. Once unlocked, a password reset should be required.
 
Read Muhammad Faisal Naqvi’s recent JournalOnline article:
Reinspecting Password, Account Lockout and Audit Policies,” ISACA Journal, volume 2, 2014.

Comments

Question

Can you go into more detail about the password guessing attack continuing after the account has been locked due to unsuccessful login attempts?

Additionally, using properly configured SIEM tools should detect a high number of unsuccessful login attempts. 
JasonY at 6/5/2014 6:36 AM