Who Needs Cracking? Give Me The Plaintext!
Another Defcon has come and gone. As far as I know, everybody I went with made it back safely, so I consider it a great success!
One of the most frightening things I learned this year was the existence of a tool called Windows Credential Editor (or "WCE"). As far as I know, this wasn't covered in any particular talks, but I had several offline conversations with password researchers. They all told me how downright terrifying this tool is.
Now, I used to be fairly deep in the password game. I competed in Korelogic's Crack Me If You Can challenge the first year it was out (my team ranked second place of eligible teams, with about 1/5 the size of larger teams). I've hosted (and still host) countless password lists, and I almost finished a database-driven breach site (I'll finish it one day, I swear). All of this is great for password cracking, but who needs to crack password hashes when you can dump plaintext passwords?
Let's rewind a little bit, and talk about the state-of-the-art of Windows password cracking, as I recently knew it. Windows has traditionally stored two types of password hashes: LANMAN and NTLM.
The idea is, an attacker (perhaps a script kiddie with nothing better to do, or perhaps one of the nebulous "APT" characters) has compromised a machine on your network. Maybe it's because a secretary was fooled into running a malicious Java Applet, perhaps it was a Web server with a command-injection flaw, or maybe it was a developer who needed to have that special screensaver with the embedded Trojan. Who knows how it happened, but the attacker is on your network.
To continue the attack, the attacker is going to try and move to other machines. To do this, he or she dumps passwords from memory. In a traditional attack, that means they got a list of LANMAN- and NTLM-hashed passwords.
LANMAN-hashed passwords are essentially DES - a known string ("KGB!@#$%") is encrypted with the seven character password (a DES block uses a 56-bit key and 8 bits of parity to encrypt 64-bits of data). If your password is longer than seven characters, it's helpfully split into two seven character strings that are hashed individually. If your password is longer than 14 characters, well, this was the 80s; 15+ character passwords weren't invented yet.
How do you crack LANMAN? Well, let's just say that brute-force guessing a 7-character password can be done quite fast. Heck, my cell phone probably has enough power to crack a LANMAN password with enough cycles left over to work on beating my high score in Angry Birds.
In Windows 3.1, LANMAN was superseded by NTLM (though both were stored for many years for compatibility reasons). NTLM passwords are hashed using MD4. The security mainly comes from converting the password to UTF-16 before hashing it, thus doubling the effective length of the password by adding NUL bytes! In all seriousness, because your password can now effectively be unlimited length, this was a huge step. Since it was 1992, back when I was still in grade school, and DECs still roamed the earth this was actually an impressive step.
NTLM passwords can, of course, be brute forced in much the same way as DES. By using a combination of pure guessing and modifications of common passwords, the majority of NTLM passwords can be brute forced fairly quickly. To give an idea, the 2013 Crack Me If You Can contest gave contestants about 33,000 NTLM passwords with an average length of 14 characters, and the top team cracked about 12,000 of them in 48 hours. That's right - almost 40% of NTLM-hashed passwords, with an average length of 14 characters, could be cracked in just two days. For comparison, cracking one password is often enough to compromise your network.
So, LANMAN can be trivially cracked, and NTLM takes more effort but will still crack relatively easily. From Vista onwards, LANMAN passwords were no longer stored on Windows machines, but some companies still choose to re-enable them for compatibility reasons (though it's a mystery to me who wants to maintain compatibility with DOS).
This was the state-of-the-art a year ago. Let's look at modern Windows password attacks with Windows Credential Editor.
From the website for the tool, it advertises that it can:
Perform Pass-the-Hash on Windows
'Steal' NTLM credentials from memory (with and without code injection)
'Steal' Kerberos Tickets from Windows machines
Use the 'stolen' Kerberos Tickets on other Windows or Unix machines to gain access to systems and services
Dump clear text passwords stored by Windows authentication packages
Now maybe it's just me, but there are a few terrifying points there. It can steal plaintext passwords, it can steal passwords from domain users, and it can steal Kerberos tickets to access other systems. If an attacker compromises your system, it's more "game over" than ever before.
This can be done two different ways: either inject code into the LSASS.exe process and call the MSV1_0.dll function GetPrimaryCredentials() or reverse engineer that function and implement it entirely in another process. Both cases are completely OS independent (as far as current Windows releases go), but the first one may be unsafe because if it crashes the entire system crashes.
This tool supports all current versions of Windows. I tested it myself on Windows 8 64-bit, and it worked beautifully:--
C:\Users\ron\Desktop>wce.exe -w
WCE v1.41beta (X64) (Windows Credential Editor) - (c) 2010-2013 Amplia
Security - by Hernan Ochoa (hernan@ampliasecurity.com)
Use -h for Help.
ron\WINDOWS8:iagotest8
C:\Users\ron\Desktop>
I also tested it on a Windows 7 domain-connected machine, and it worked there as well with the domain account. It would also be trivial to have a domain administrator connect to my machine to steal his or her password.
And that sort of calls out the one drawback to this tool. It requires a user to be actively logged into the host.
Anyway, that's all the info I can give. For more information, here are notes from an in-depth talk on all its inner workings:
http://www.ampliasecurity.com/research/WCE_Internals_RootedCon2011_ampliasecurity.pdf
And here's a guide on using it for post exploitation:
http://www.ampliasecurity.com/research/wce12_uba_ampliasecurity_eng.pdf
I hope you guys found that as interesting as me. See you at the next conference!