Browser Pivoting (Get past two-factor auth)September 26, 2013
Several months ago, I was asked if I had a way to get past two-factor authentication on web applications. Criminals do it, but penetration testers don’t. To solve this problem, I built a man-in-the-browser capability for penetration testers and red teams. I call it browser pivoting.
A browser pivot is an HTTP proxy server that injects into a 32-bit Internet Explorer process. By browsing through this proxy server, I can reach any website my target logged into–as them. If the target logs into their web mail, I’m logged into their web mail. If they send sap stories to their ex-girlfriend on Facebook, I read them. If they use DropBox’s website to store and manage files, I’ll download the best ones. If they’re connected to an intranet portal site; I’m there too. [Update 21 Nov 13: 64-bit IE is now supported as well]
How it Works
Internet Explorer’s architecture makes Browser Pivoting possible. Internet Explorer is an application that consumes several libraries. WinINet is the library Internet Explorer uses to communicate. The WinINet API is popular with malware developers because it allows them to request content from a URL with very little code. WinINet is more than a high-level HTTP library built on top of Windows sockets. WinINet manages a lot of state for the applications that use it.
I became familiar with WinINet during Beacon‘s development. I tried to use the Cookie header to send information. I was baffled when this cookie kept coming back blank. I didn’t know this at the time, but WinINet removed my cookie to insert the cookie from its store into my request. I had to set a INTERNET_FLAG_NO_COOKIES flag before I could programmatically send my cookie.
Cookies aren’t the only thing WinINet forces into a request. WinINet will also retransmit “credential material” which includes a previously provided username/password or client SSL certificate. If WinINet is communicating with a site in the Intranet Zone (and the user’s settings permit it); WinINet will automatically try to logon with the user’s default credentials. The WinINet consumer must set the INTERNET_OPTION_SUPPRESS_SERVER_AUTH flag to disable this behavior.
WinINet is the layer that manages Internet Explorer’s cache, history, cookies, HTTP authentication, and SSL session state. Inheriting this managed state isn’t a bug–it’s a feature.
A browser pivot is an HTTP proxy server that fulfills requests with WinINet. The process this proxy server lives in is important. If I inject this proxy server into notepad.exe, I don’t get anything interesting.
Magic happens when I inject  this proxy server into the Internet Explorer process . I inherit Internet Explorer’s WinINet state with each request. If a user’s web session is secured with a stored cookie, session cookie, HTTP authentication, or client SSL certificate–I can use that session with a browser pivot .
Two-factor authentication is a non-issue at this point too. WinINet doesn’t care about how this session state was obtained. It just uses it.
 Several people have asked about this mysterious process injection thing I refer to. The Browser Pivot proxy server is compiled as a Reflective DLL. I use the Metasploit Framework’s post/windows/manage/reflective_dll_inject module to inject this DLL into a process I choose.
 There’s one nuance to this: Modern versions of Internet Explorer isolate each tab in a separate process. In this case, the parent Internet Explorer process does not have access to WinINet state. The processes associated with a tab share WinINet state with the other tab processes. If you inject into Internet Explorer 10, make sure you inject into a child tab’s process.
 WinINet session state is good until the user closes the browser. If the user closes their browser–the proxy server goes away and the attacker must inject into another process. How to keep session state–even after the browser closes, is not part of this work.