1065000 - security bug: man in the middle attack can cause persistent domain spoofing

Status: RESOLVED INVALID

(Core :: Networking, defect)

Description

[Wouter van Rooij]

Attachment: Word document containing the screenshots of this attack

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.103 Safari/537.36

Steps to reproduce:

When browsing to a website, in this example my website: www.hack.je, I intercepted the request with a proxy (The freely available Burp Suite in my case). By altering the destination target of the GET request, to in this example: www.nu.nl (Dutch news site).
Then close your browser. Start it up again, and browse to www.hack.je in your navigation bar. 


Actual results:

Of course the browser shows the www.nu.nl website instead of my website. Notice that www.hack.je is still in the navigation bar?! When performing this once, every time I browse to www.hack.je, www.nu.nl is shown as output. The only way to undo this man-in-the-middle attack is to clear your cache, or refresh the page. Everytime I enter www.hack.je it doesn't even come to a request. The request is allways a get request to www.nu.nl.


Expected results:

What should have happened, is that by browsing to www.hack.je, firefox should have sent a get request to www.hack.je! The way it is been done at this moment makes a victim vulnerable to the following example:

Astrid enters a Starbucks store, joins the open wifi and browses to a page.
Eve performs a man in the middle attack and alters the target to www.evil.com, which looks like the login screen of the requested page.
Astrid still sees the address she originally entered in the address bar and enters her credentials and her account is compromised.
Bob, the boyfriend of Alice, later that day at home, also uses Alice her laptop. He also browses to that page.
However Eve isn't performing his man-in-the-middle attack anymore, Bob is still being redirected to www.evil.com and so also his credentials are compromised.

Please see the screenshots for clarification and how to reproduce this attack.


RISK RATING:

Chance: High (open wifi hotspot is enough to perform this attack)
Impact: High (it is persistent, as described above)
Risk: Critical

Comment 1

[Wouter van Rooij]

Notice that if you browse to hack.je (without the www.) and you change both the hostheader and the destination target of the GET request, that the navigation bar does change. It is then not possible anymore to end the man-in-the-middle attack with just a refresh. However a user that notices the addressbar change, probably won't enter his credentials anymore.

Comment 2

[Daniel Veditz [:dveditz]]

Did you actually see a wire request to evil.com the second time? (you can use our devtools network tab). What's probably happened is the data is cached, which is not a bug. If you submit the form it should then go to the correct www.hack.je.

But... if you use http: instead of https: there is absolutely no protection against MITM attacks; https was invented specifically to prevent that attack. Once you've been MITM'd there are all kinds of cache-poisoning type attacks that are possible to extend the reach of the MITM to future connections (the literal cache, cookies, local storage, and more).

Comment 3

[Wouter van Rooij]

Actually, it does when you change not only the target destination, but also the host header. A notible user could see the change in the address bar, however, if an attacker manages to register a type error, it would be hardly noticable (example: www.mozilla.org www.mozillla.org) 
It does also work on google.com. I guess nobody is browsing google like this: https://www.google.com. They will just enter google.com or www.google.com (I'll attach a proof video of that) 
If instead of my "Under construction" I would have had a google login screen, with the www.google.com in the navigation bar, who could tell the difference? In a normal MITM I would understand that it's **** happens. However, you saw mee closing the browser in the video. Next time the victim is at home, he/she or someone else in the family visits google.com still the same page will be displayed and credentials will be sent to my site instead of google.com. 
As can be seen, also HSTS can be bypassed this way.

Comment 4

[Wouter van Rooij]

Attachment: screencapture.wmv

Comment 5

[Wouter van Rooij]

By the way: this attack also works when going to www.facebook.com and redirect it to twitter.com. You can see that it is over https. What I don't get is that (and I will also upload a video of that) the browser for some reason has some kind of domain spoofing. As can be seen, in the first browser (which has been tampered using my attack: going to www.hack.je has the browser redirect?!?! to www.nu.nl) The second browser, that hasn't been tampered with, shows that I have no such redirect script or whatsoever on the site.
There is so to speak no verification whether the cached url is the url that was requested in the first place. No response has been changed, only the request. So the entered URL www.hack.je wasn't requested in the first place.

Comment 6

[Wouter van Rooij]

Attachment: screencapture2.wmv

Comment 7

[Patrick McManus [:mcmanus]]

so for most of the comments here involving http:// it just seems you have a poisoned cache from the mitm. The cache intentionally persists between restarts, so that poisoning can persist as well. Some of the confusion around the location bar is probably a cached 3xx redirect of some kind (the redirect can be cachable too).

I'm more interested in comment 5 that suggests any kind of MITM (much less a cache poisoning) is happening over https:// .

I'd love to see the video
I'd love to see an NSPR log https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

Can you confirm you are running with the default Trust Anchor list? (i.e. you haven't added any new CA roots). It would be good to click on the lock icon and the more information button it reveals in any video.

Comment 8

[Al Billings [:abillings - ex-MoCo]]

This seems to be the way the cache works. If it is poisoned, bad things happen.