The vulnerability of Windows passwords to table based cracking.

The vulnerability of Windows passwords to pre-computed table based cracking:

This write up discusses the inherent weaknesses of the default windows password scheme and how to remediate that weakness by editing your system settings.

Recently the issue of password strength and auditing came up and the discussion prompted me to do further research into the subject. What I found is that the critical vulnerability with windows passwords comes from the LM and NTLM algorithms it uses and the way Microsoft implements this with challenge response to authenticate users.

A lot of other people have covered this subject in great detail so I’ll just touch on it briefly here.

The Vulnerability:

To test the information given below download the pwdump2 or pwdump3 programs and the “Ophcrack” time-memory trade off (table based) password cracker. Use the large pre-computed tables to run your tests on the hashes recovered by the pwdump programs.

Even though Active Directory may be used to enforce password complexity settings (upper, lower, alpha-numeric) the LM method re-designates all characters to upper case before the hash is computed, therefore, PaSswOrD is hashed as PASSWORD. Additionally, any password 14 characters or less is hashed and then divided into two seven character pieces, these smaller pieces are easily cracked using the time-memory trade off method. The MD4 hash of NTLM is a bit more robust but is still easily cracked. The addition of special characters to the aforementioned LM password is mostly irrelevant as the bulk of the password is cracked almost immediately and the remaining iterations don’t take long to complete.

The MD4/LM/NTLM hash is easily cracked (within a few minutes usually) and this leads to two attack vectors which are commonly exploited.

  1. Accessing and cracking the LM/NTLM hashes either on the host or on the domain controller and copying them off to be cracked.
  2. Sniffing the LM/NTLM authentication challenge/response pairs off of the network and then reassembling them to be cracked.

The Fix:

Microsoft has addressed this issue by implementing NTLMv2 authentication which is 128 bit and significantly more difficult to crack when good password generation practices are used. NTLMv2 is native to Windows 2000 domains greater than Service Pack 2.

With this in mind there are three changes that can be made to remediate this threat, they are:

  1. Disable LM/NTLM challenge/response authentication.
  2. Enable NTLMv2 authentication.
  3. Restrict the storage of LM/NTLM password hashes locally (client and server).

The LM/NTLM hashes currently stored on the domain controllers will be flushed the next time an authenticated domain user changes their password and will not be replaced with an NTLMv2 hash. If these methods are implemented I believe the need for manual password auditing is nullified.

The following pages document how to accomplish all three of the remediation methods above and provide links to addition information on the subject.

Restrict MS Active Directory to NTLMv2 authentication only and disable LM/NTLM:

The following steps are needed to disable LM and NTLM challenge/response authentication between Active Directory members and Domain Controllers.

On the domain controller open the domain security policy for editing and select the following settings:

  1. Locate the “LANMAN authentication level setting at, “Windows Settings/Local Policies/Security Options and open it for editing.
  2. Select “Send NTLMv2 response only\refuse LM & NTLM.
  3. Go to the action menu and select Reload to reload the AD Policy.
  4. Exit the Domain Security Policy Editor.

Only one policy change is necessary, the AD Policy change will migrate through the Domain Controllers on it’s own in a matter of minutes.

Restrict the storage of LM and NTLM hashes on MS Active Directory members:

To disable the storage of LM hashes in Win2k AD you must add a registry key to the registry on each Domain Controller and reboot the server. These settings will be passed to the AD members by group policy.

Link to the full article involving the restriction of LM/NTLM hash storage on MS AD members is (MS Article ID: 299656):

http://support.microsoft.com/default.aspx?scid=KB;EN-US;q299656&

Windows 2000 SP2 and Later, this registry edit is for Windows 2000 SP 2 machines and later. It is not tested on machines prior to Win2k SP2. Windows 98, SE and ME machines require a special registry edit that is discussed in the linked article.

To make the registry edit on a Win2k DC do the following:

  1. Start the registry editor.
  1. Start/run/regedit/enter
  • Locate and highlight the registry key:
    1. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
    2. On the Edit menu click “add key, type “NoLMHash and press enter.

    Close regedit and reboot the Domain Controller.

    Compatibility with Windows NT 4 and Win 98, 98SE and ME:

    There are compatibility issues with Windows 2000/2003 Active Directory authentication and NTLMv2. These issues can be resolved through editing the registry on these older operating systems to enable NTLMv2 compatibility.

    Details regarding Windows NT 4 workstation can be found here (software):

    http://www.microsoft.com/ntworkstation/downloads/Other/adclient.asp

    And here (how-to):

    http://www.its.caltech.edu/win/adnt.html
    Active Directory Services In Windows 98, 98SE, ME:

    http://support.microsoft.com/default.aspx?scid=kb;en-us;323455

    And here:

    http://www.its.caltech.edu/win/adnt.html

    Managing NT and 9x clients with Active Directory:

    Here is a rundown of the features in the Active Directory Client Extensions patch:

    • The ability to log onto domain controllers: This includes the ability to change passwords on any Windows 2000 domain controller in the domain, rather than just the primary domain controller for that domain (as was the case with NT 4.0 domains). Note that NT 4.0 clients and Win9x clients will only be able to change their passwords at the PDC; you can’t override NT 4.0 password behavior by changing the password at the PDC with this patch.
    • Windows Address Book (WAB) properties: This allows users to search for and change the properties of user objects in AD through the Start -> Search system, and also allows for new schema elements to be added to said user objects through the client (in the event they are needed).
    • NTLM version 2 authentication: Clients with the patch can perform NTLM v2 authentication over the network as well as version 1. Some of the changes in version 2 include encryption and hashing of the password, case-sensitive passwords, and a number of other changes for security.
    • The DFS fault tolerance client: This allows clients transparent access to Windows 2000 distributed file system (DFS) shares, as well as failover shares described through Active Directory.
    • Active Directory Service Interfaces (ADSI): This allows Active Directory actions to be scripted (through the use of Windows Script Host or other scripting systems), and allows programmers a common API to Active Directory functions.

    Link:

    http://searchvb.techtarget.com/tip/1,289483,sid8_gci932984,00.html

    Additional in-depth information regarding this process is available at the following URL’s:

    Microsoft Tech net:

    Restricting LM NTLM:

    http://support.microsoft.com/default.aspx?scid=kb;en-us;299656

    Selecting Strong Passwords:

    http://www.microsoft.com/technet/security/smallbusiness/prodtech/windowsxp/select_sec_passwords.mspx

    Windows Security.com:

    http://www.windowsecurity.com/articles/Protect-Weak-Authentication-Protocols-Passwords.html

    The SANS Top 20, regarding section W3.1 Windows Authentication:

    http://www.sans.org/top20/index1.php?printer=Y

    MCP Magazine:

    http://www.mcpmag.com/columns/article.asp?EditorialsID=708

    5 Responses to “The vulnerability of Windows passwords to table based cracking.”

    1. Timothy Says:

      The KB article you link to mentions it now, but just to clarify for anybody else reading this, you no longer have to modify the registry to disable storage of LM hashes. It’s available now in group policy in a domain, or the local security policy of any standalone server or workstation. It’s also misleading to say it will not store NTLM hashes. It will, in fact, still store NT hashes since that is the only other available hash in a Windows environment. The amount of time to crack an NT hash that uses special characters and is very long, even using a rainbow table cracker. This is not inherent to Windows persay, any hashed password file from unix distros is also vulnerable. Hashes are great at *stalling* password cracking, but not preventing it. Eventually as computing power increases, brute force attacks on older hashes will successfully decode the password.

      The moral of the story: Tighten security using the methods outlined in this blog post for your windows systems, DO NOT let users boot machines into other environments (through a boot disk or CD or partition), do the same for your non-windows systems (they are not invulnerable!!!!), and set your passwords to REGULARLY expire! The older a password is, the more likely it’s cracked. Oh and for pete’s sake, do not let users run as local admins! That is the simplest way to prevent unauthorized disclosure of a computer’s SAM.

    2. iastor.sys…

      […]The vulnerability of Windows passwords to table based cracking. « The Black Flag[…]…

    3. Forgot windows 8 password…

      […]The vulnerability of Windows passwords to table based cracking. « The Black Flag[…]…

    4. Hey there, I think your website might be having browser compatibility issues.
      When I look at your website in Chrome, it looks fine but when opening in Internet Explorer, it has some
      overlapping. I just wanted to give you a quick heads up! Other then that, terrific blog!

    5. options trading service

      The vulnerability of Windows passwords to table based cracking. | The Black Flag

    Leave a Reply

    Fill in your details below or click an icon to log in:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out / Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out / Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out / Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out / Change )

    Connecting to %s

    %d bloggers like this: