Protecting Privileged Domain Accounts: Disabling Encrypted Passwords

[Author's Note: This is the 3rd in a multi-part series on the topic of "Protecting Privileged Domain Accounts". My primary goal is to help incident responders protect their privileged accounts when interacting with comprised hosts, though I also believe this information will be useful to anyone administering and defending a Windows environment.]

Update: I have added several updates to this post due to the fact that the mimikatz tool (and others) are now able to dump cleartext passwords from the Kerberos security service provider (SSP). Because of this, the idea of disabling these SSPs that store encrypted passwords is no longer feasible. More details below, with updates in italics.

Update 2: This article still has some useful background information, but be aware that passwords are no longer stored in memory by default with Windows 8.1 and Server 2012R2. Be sure to read "Protecting Privileged Domain Accounts: Restricted Admin and Protected Users" for recent updates on this topic.

Last week I discussed the fact that the only way to prevent LM hashes from loading in memory for interactive logons is to use a password of 15 or more characters. Furthermore, the fact that LM hash Rainbow Tables can crack the corresponding passwords in just a few seconds means that attackers who obtain these LM hashes will know the clear-text passwords almost instantly.

Today we'll do one better. We'll look at a method for directly obtaining a user's clear-text password from memory. No intermediate cracking steps necessary!

In this article, I'll discuss the issue of encrypted passwords in memory, the mimikatz tool which exploits the issue, and finally what we can do to protect our accounts from this "feature".

Encrypted Passwords in Memory, You Say?

Yep. It turns out that by default, interactive logons store an encrypted form of the user's password in memory. The reason for this is to provide for single sign-on (SSO) to services that do not support native network authentication protocols (i.e., Kerberos, NTLM/LM challenge-response). In these cases, Microsoft conveniently stores an encrypted version of your clear-text password in memory to authenticate you to these services.

Now in case you are wondering if there's any real difference between an encrypted password in memory and a password hash in memory, there definitely is. A hash is considered a one-way function, meaning that once data is run through the hashing algorithm, you cannot reverse the output to get the input (i.e., to get the password). Encryption, on the other hand, allows for decryption. So the fact that there is an encrypted version of your password in memory implies that there is a way to decrypt it. This is not good. Now in the case of the LM hash, we saw last week that cracking this hash is trivial, so it is effectively the same as a clear-text password?also not good. But if you set a password to be greater than 15 characters, which breaks the LM hash, then only the NT hash is available and the NT hash of a strong password is much, much more difficult to crack?as a hashed password should be!

Getting the Password

This issue is relatively new?or at least relatively unknown until recently. Just a few weeks ago, the issue got a boost in visibility with this pentestmonkey blog regarding the tool mimikatz. (I have to thank Ed Skoudis for pointing this one out to me?thanks Ed!). More recently, Tim Tomes posted an interesting article on PaulDotCom showing how to use mimikatz with Metasploit. I assume it won't be long before there's a Meterpreter module for it as well. But prior to these articles, few people knew about this issue.

It appears that the discovery was made by the author of the tool mimikatz. The author, who goes by the nickname "Gentil Kiwi" (I couldn't find his real name), is French. With the help of Google Translate, his blog articles provide a good overview of the issue and generally how his tool is able to produce the clear-text password.

His first blog on this subject is cleverly titled "Pass the pass(word)". In this blog, he discusses the fact that Windows Vista and higher feature a Security Support Provider (SSP) for Terminal Services named TsPkg, which provides single sign-on functionality to terminal servers. This feature can also be added to Windows XP SP3, as discussed here. Furthermore, this TechNet article discusses how to enable this SSO feature for specified terminal servers via GPO. However, as the author of the tool stated in his blog, and as my testing confirms, Windows will store the password in memory whether this feature is "enabled" via GPO or not. In other words, by default it's always on.

A few weeks later, the author posted an update titled "Re-pass the pass(word)", where he discusses another SSP providing similar SSO capability, named WDigest. This time it's not only in Vista and higher, but in XP and Server 2003 also!

WDigest provides for "digest access authentication", an extension to HTTP specified by RFC 2069 and later in RFC 2617. Direct access authentication improves upon basic access authentication, which sends credentials in the clear. Wdigest specifically supports RFC 2617, as well as RFC 2831, which is a more generic authentication mechanism (useful beyond HTTP) called Simple Authentication and Security Layer (SASL). The general idea here is that these specifications provide challenge-response authentication, whereby a challenge is issued and the responding party answers the challenge using a hashing routine that takes the clear-text password as an input. The Wikipedia article on digest access authentication is very interesting and highlights a number of problems, including the fact that the server using this scheme may in fact store the client's password in the clear in order to verify the answer. Nevertheless, we are concerned about the client itself, which does have to store the password in the clear in order to answer a challenge from the server.

Update: After this article was published, the author of mimikatz, Benjamin Delpy, discovered that the Kerberos SSP also stores your password in memory and his tool will now dump the password from this module as discussed in his blog "Re-re-re-pass-the-pass". After further study on Kerberos, it appears that the reason for storing the password is to allow Windows to automatically renew the Keberos Ticket Granting Ticket (TGT) without the user having to retype the password every few hours. The TGT is effectively the LM/NT hash in the Kerberos model, except that it expires and must be renewed regularly, unlike password hashes which are valid until the password is changed.

So in each of these cases, the SSP stores the clear-text password in an "encrypted" form. The encryption is implemented using the standard Win32 functions LsaProtectMemory and LsaUnprotectMemory, which "encrypts/decrypts the specified memory buffer". The tool mimikatz is able to pull the encrypted credentials from memory and simply unencrypt them with the LsaUnprotectMemory function, reporting clear-text passwords to the console.

Testing

Let's see this in action. First off, have a look at the default Security Support Providers.

• Here are the default settings on Windows 7:
  Update: Kerberos should also be highlighted:

• And here are the default settings on Windows XP:
  Update: Kerberos should also be highlighted:

Now let's run the tool to see what mimikatz provides.

• For this testing, MSAD2-RESPONDER2 has performed an interactive logon at the console while MSAD2-RESPONDER1 is logged on via a RunAs interactive logon.

The tool works as advertised. It provides the clear-text password for interactive logons. Notice that the tool also provides the LM and NT (aka NTLM) hashes as well?though in the case of MSAD2-RESPONDER2, there is no LM hash due to the long password.

Update: The new version of mimikatz would also dump the password from the Kerberos SSP module.

So what can we do to disable this "feature"? We can simply remove these two providers from the Registry location 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.

• From my Windows 7 test machine, I've removed WDigest & TsPkg and rebooted:

• Now let's re-run the tool and see what we get:

Great! The passwords are no longer available because the questionable security support providers are no longer available. We still have hashes available due to the interactive logon though, so that still represents a significant risk. Nevertheless, we've at least incrementally improved our security posture by not revealing clear-text passwords.

Update: Unfortunately since Kerberos is also vulnerable, we cannot remove that SSP and still have a functioning modern Windows domain.

Conclusion

As was the case for my previous two articles in this series, the definitive way to avoid this issue is to avoid interactive logons. As discussed in my first article, always use network logons instead of interactive logons when connecting to compromised machines.

On there other hand, there will obviously be one or more trusted machines for which you will need to perform an interactive logon. For those machines, I suggest you remove the TsPkg and WDigest SSPs to avoid a blatent security risk.

Update: Removing SSPs is no longer valid advice since Kerberos also stores the password. Therefore, the most effective protection is to avoid interactive logons to any untrusted hosts. Other solutions such as one-time-passwords should also be considered.

That's all for now. Next week? access tokens!