Stealing Windows Credentials Silently from the Browser

Proxies are a wonderful tool for anonymity, but here we'll exploit them to silently steal identifying information and credentials of a Windows user by visiting one website.



Proxies are generally great security tools. They help organizations monitor and block web traffic flowing in their networks and they help those with a want or need for privacy to become more anonymous. Some proxies require authentication to use - and this is what we're going to exploit.

RFC2616 tells us how authentication, and proxy authentication, should be handled within HTTP headers. We're going to focus on proxy authentication, but for all purposes normal webpage authentication is nearly identical. The process works by a proxy server replying to a client's request with a Proxy-Authenticate response and a HTTP 407 response code. The client then makes a determination on how to proceed, prompting the user for credentials, and authenticating to the proxy. However, on Windows machines we can avoid asking the user for anything. By simply limiting the authentication option to only accepting NTLM, all major web browsers will authenticate as the current Windows user to the proxy.

That sounds mildly concerning, but it's our proxy. We configured it. We trust it. Who cares?

Well, it seems that not all proxies obey this important statement in RFC2616:

Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to the current connection and SHOULD NOT be passed on to downstream clients.

The problem arises when something upstream from your proxy sends a 407 response code and your proxy passes this onward to the browser. In this case, the browser thinks that it's authenticating to it's own proxy, but that authentication data is actually sent upstream.

Enter project FourOhSeven. This proof of concept tool is a script that can be run from any Apache server to try to elicit information from a client behind a proxy. If a client visits the page, and is behind a proxy that passes HTTP 407 responses, the script will initiate NTLM negotiation with the browser and extract from the currently logged-in user the username, domain, computer name, NTLM and LM challenge-response hashes, and OS version and build - and all transported within the existing HTTP channel and without prompting the user.

This attack was particularly effective against older versions of the Tor bundle (circa 2007-2008), however, I've confirmed that - at least in the latest bundle for Windows - that this technique doesn't work. Kudos to the Tor developers for using a proper local proxy server.

From a test Windows XP virtual machine, I've tested Internet Explorer 6, 7, and 8, Firefox 18, and Chrome 24 and confirmed that, when using a proxy, visiting the PoC page would silently extract the user information. When testing on Firefox and Chrome on Linux, both browsers prompt for credentials. However, if the user enters any credentials, they are sent, but so is the name of the computer.

So, perhaps you don't use a proxy, or it's not vulnerable. While not as bad, this technique can be modified and used with traditional authentication as well, working against Windows and Linux to steal the computer name. Visit a webpage, get asked for credentials, and rather than just sending credentials you type, the computer name is also sent along simply because it's part of how NTLMSSP messages are formed.

The information leaks that occur can be devastating to those seeking to remain anonymous while using a proxy. If you're using a public proxy for anonymity, you may wish to test this on your own proxies to see if they're vulnerable and pass upstream HTTP 407 responses to the client.

Finally, there are ways to use this a bit more maliciously. I'll leave it to the reader to consider how Windows Proxy Auto-Discovery (WPAD) can be used to enable this attack silently on an entire network.

Download the PoC code here.