Owning the paranoid: browser background traffic

When I talk to a lot of security researchers or paranoid types, it's very common to hear them describe how they very carefully access their bank account or personal GMail etc. Generally, the model used is to launch a separate browser instance, and navigate straight to an https bookmark. The session remains single-window, single-tab. It's a powerful model; the intent is to eliminate the chance of another (http) tab being a vector for owning the browser, or more likely abusing a cross-domain flaw in the browser or bank's web application.

Attacking this browsing model was one of the key demos in my PacSec presentation.

Whether you know it or like it or not, your browser is likely engaging in a flurry of behind-the-scenes plain http requests. Some examples are:

• Safebrowsing updates
• OCSP or other certificate related requests
• Updating RSS feeds

Before going on to what a MITM attacker can do here, it's very worth mentioning the mitigation that I found. It seems to work well on the browsers I tested. If you set your http proxy (and all protocols other than https, why not) to localhost:1, then this unwanted plain http traffic will not go out on the network. The browsers seem to honour the proxy setting even for internally-initiated requests which is nice. It's not entirely clear that blocking OCSP requests in this way is ideal, but it's better than the alternatives.

So what evil can the MITM attacker do with these plain http requests? The good news is that the requests that need to be are signed (Safebrowsing and OCSP). Interestingly, a failure talking OCSP during an https initiation does not prevent the connection, but that's a separate discussion.

Specific useful attacks include:

• Attacking the exposed HTTP protocol attack surface
• Replying with a 302 redirect in order to exploit surfjacking
• Replying with a 302 redirect followed by a Set-Cookie to exploit cookie forcing

As you can see, it's an interesting result that this paranoid browsing model does not protect you from surfjacking attacks where you think it might have. Particularly so because a lot of financial web sites neglect to mark their cookies Secure.

Cookie forcing is a great advanced way for an MITM to break into https web apps that are not vulnerable to surfjacking (or XSS, XSRF, XSSI, the usual stuff etc). I will detail this new attack class and its opportunities in a subsequent post. Also see Billy's nice write up on mixed content http script loading for another under-appreciated attack against https web apps.

Closing questions that could lead to future research include:

• Do Firefox / Opera / other browsers have robust OCSP response parsers?
• What can you do with evil / malformed XML responses to RSS updates?
• What about replying to a background request with an unexpected MIME type - does that expand the attack surface?
• What about other interesting or unexpected HTTP headers?