SIA338: Authentication & Passwords, The Good, The Bad & The Really Ugly

One of the sessions that I attended today was by the very popular Marcus Murray. He’s a Swedish security expert and Microsoft security MVP. I heard him speak a couple of years ago at TechEd Orlando and was really blown away by the content and his presentation style. Thankfully Microsoft let him come back and do another session this year. Some of the content was from his Orlando session, but also included some great new content. You can actually download his whole presentation from his blog. Since you can access the presentation, I’ll just summarize a few of his attack demos:

Pass the Hash. This was one of the demos he did in Orlando, which scared the heck out of everyone. Although it’s not a new attack vector, the results are scary. In a nut shell, this is how it works. Whenever someone, such as a domain administrator, logs onto a Windows machine their password hash gets stored on the computer. If another user or attacker can get local admin access, there are tools which can dump that hash. You can then take that hash (with another tool) and impersonate that use to other servers on the network, compromising them. If you can grab a domain admin account hash, you have instantly 0wn3d the domain. If you can access a domain controller you can now dump the hashes for everyone in the entire domain and you can impersonate anyone at will.

After TechEd Orlando I went through the entire exercise in my home lab and was able to duplicate the results and escalate from a local workstation administrator to a domain admin in less than 30 seconds. If you combine these tools with a web-based attack and local privilege escalation techniques, an attacker could remotely 0wn your entire corporate domain in a matter of seconds. Think about that for a little bit! No password cracking required, and password length is irrelevant.

Passing the Dutchie. This is similar to pass the hash, but the attacker uses an untrusted computer that is not part of the domain. The attack works by using a man-in-the-middle attack using an SMB relay to use NTLM credentials to access resources on domain joined computers.

Computer Account default password. Sometimes deployment tools or other methods of creating a computer account in AD improperly configure the password and set it to the name of the computer. If for some reason the password doesn’t get changed (machine never joined to the domain, etc.) this computer account can be used to access network resources. Marcus said 95% of his clients have this problem with at least one computer account in AD. So chances are your network is vulnerable to this attack!

Passing the Google Cookie. In this attack Marcus snatched Google docs cookies from the network (WiFi or wired), and injected them into IE and was able to impersonate the user and access their documents. This is similar to pass the hash, but it used cookies and the Google docs web site. Google doesn’t send their cookies over SSL, so beware! You can see a video of this attack on the his blog link I provided above.

One of the new tidbits of information that was brand new to me is the concept of Authentication Assurance in Windows Server 2008 R2 using smart cards. In a nut shell this is a new feature in Windows Server 2008 R2 that lets Windows dynamically add you to a security group if you logon with smartcard using a particular certificate template. If you use this security group to ACL resources, such as a file share, then attacks like pass the hash and pass the dutche are foiled since a smartcard was not used for authentication and you aren’t a member of the special security group. This security group could be extended to IPsec to only allow users that authenticate with a smartcard to access any resources on a particular computer.

Another countermeasure that he mentioned were some new settings in Windows 7 and Server 2008 R2 that can audit and even eliminate the use of NTLM on the network. There are some new group policy settings that you can use to block all NTLM authentication. This is easier said than done since some applications or methods of accessing resources don’t work with Kerberos, such as accessing a file share via IP address vice a hostname. Even if you can’t fully disable NTLM for all use cases, you can at least start auditing to get a handle on how widely its used on your network. This is one reason why I always try to Kerberos enable ANY application on the network, such as SQL, SharePoint, IIS, vCenter, etc.

Buy me a coffee

Related Posts

Notify of
Inline Feedbacks
View all comments