8

If someone successfully set up a phishing website on a fake wireless network for say, bankofamerica.com, and lets pretend that SSL was not used, would they be able to run a script on the server that reads the cookie contents of anyone who connected to it (for example, a long-term authentication token)?

AgmLauncher
  • 211
  • 2
  • 5
  • 3
    Such an attack would normally be called [pharming](http://en.wikipedia.org/wiki/Pharming) rather than phishing – paj28 Feb 06 '15 at 12:48

4 Answers4

7

Assuming a pharming attack rather than phishing... This is where the domain name is redirected to a fake site rather than Typosquatting or tricking the user into visiting a totally different site that is made up to look like the target.

The difference here is crucial - the effective domain of the fake site as seen from the victim that is actually the same as the real site will cause the browser to treat the fake site as the same Origin.

This means that cookies, local storage, et al, will be available to the fake site.

Two mitigating points:

  • If the Secure Flag has been set on any auth cookies, they will not be sent to the domain unless it is accessed over HTTPS.
  • If HSTS has been set for the domain either because the user has visited the site before and has an HSTS entry for the domain in their browser, or the site is in the HSTS pre-loaded list, the user will not be able to connect to the fake site over HTTP (nor over HTTPS if the certificate causes browser warnings).

If neither of the above apply and the user had an authenticated session against the fake site, then the cookies will be sent to the fake site, including any used for authentication. Hopefully a bank will have taken either of the above precautions but not always the case.

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
  • Thanks, this is what I figured would be the case. I'm in a unique situation where I need to build a website that will be deployed on mobile wifi access points that each run web servers internally. Thus it's very likely that someone could set up a fake access point and serve a fake website. I was planning on using SSL with HSTS anyway, but just wanted to be sure that if the end user accidentally accepts a bad certificate, then all hope is lost and their cookies now belong to the attacker :/ – AgmLauncher Feb 07 '15 at 05:15
3

Yes the attacker can send you a malicious link and if you click on it the cookie information will pass to the attacker. Such types of attacks are called Cross Site Scripting attack XSS . The attack scenario can be of two types: 1. Stored XSS . 2. Reflected XSS

Irfan
  • 121
  • 6
  • 5
    XSS is not needed - the phishing site is already controlled by the attacker. – SilverlightFox Feb 06 '15 at 12:42
  • If the site is used by the attacker the attacker can get document.cookie file and all the cookie information stored in it. – Irfan Feb 06 '15 at 12:59
  • 4
    Using `document.cookie` on *your own site* is **not XSS**. The site is working exactly how the attacker who built it intended. The site isn't being attacked and working differently from how its creator intended (e.g., by attacker-injected content); the site *is* the attack, and it's working perfectly. – apsillers Feb 06 '15 at 17:36
  • The attacker cannot capture cookies with the secure flag set unless the user accepts a forged certificate. If the real site is vulnerable to xss then the attacker probably doesn't need to bother with a rogue IP/fake website. – symcbean Feb 07 '15 at 00:20
3

Yes, assuming HTTPS is not used.

In your situation, you run the wireless gateway, and you have the power to make bankofamerica.com resolve to a different host than it would on the public Internet. This is a pharming attack.

Cookies are tied to a domain name. When a server sends a Set-Cookie response header, or a script uses document.cookie to set a cookie, we say that the cookie is set by (or for) that domain. Generally, the ability to read cookies for a particular domain name is limited to the server with that domain name. This has obvious attack implications if the name bankofamerica.com suddenly refers to a different IP address.

Every time your browser sends a request to a server named bankofamerica.com, it includes the cookies set by bankofamerica.com in the request. If the actual server (or IP address) that is reached when your computer asks for bankofamerica.com changes, your browser doesn't care, and will send your bankofamerica.com-set cookies to the acceptably-named (but actually malicious) server. (Consider: sometimes the IP address associated with a domain name can change legitimately; how would your system know whether a change is legitimate or an attack?)

Since you control this rogue server, you can see all traffic that comes in and out. Therefore, you can see the cookie headers sent by the client's browser to the server. However, if you control the router, you can see all that information even before it reaches your malicious server (via the router itself) so there's not a good reason to actually set of a malicious server in addition to your malicious router. If you somehow managed to change the client's bankofamerica.com DNS record without completely controlling the router, however, then your rogue-server idea fits your requirements perfectly.

Note that HTTPS does a good job of blocking this attack. Your server can't successfully impersonate a secure connection to bankofamerica.com, because it doesn't have a signed certificate from a certificate authority that the user trusts. No certificate authority would give you a signed cert for bankofamerica.com unless you could prove your really owned the real thing (which you obviously can't prove, because you don't own it). When you try to redirect the client's secure connection to your fake server, the client will be alerted that a possible attack is happening.

If the user first tried http://bankofamerica.com instead of going dirrectly to https://bankofamerica.com, your evil server could say "No need to upgrade to HTTPS; let's just say on plain HTTP," and the client would not get a warning about certificates. This an SSL stripping attack. This can be prevented by HSTS, which a server can use to tell a client, "Never contact this host by an insecure connection for the next XX days/months/years."

Another protective measure possible with HTTPS is the secure cookie flag. The browser will not send secure-marked cookies to the owning domain unless the request takes place over HTTPS. Since your server can't impersonate the target domain over a secure connection, you will never get to see secure cookies.

Community
  • 1
apsillers
  • 5,780
  • 27
  • 33
0

Yes they can but depending on the browser it does not even need to be a phishing attack at all. Internet Explorer 11 has a recent vulnerability that allows an attacker to steal cookies.

Many different programming languages can run on websites and there are commands that can do some scary things. If you are on Linux you can setup a whole new isolated profile just for Firefox so you system is protected. Yes, even Linux can get pwned by Java and attack the boot loader with an remote evil maid attack. (Why did I mention evil maid? Because I'm just giving a example of how far a browser exploit can go. )

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • 1
    This answer appears to address *other* mechanisms for stealing cookies, rather than addressing the OP's concerns about the viability of this particular attack type. (Also, it this answer will retain its value over time much better if your link to the articles you mention, rather than giving directions on how to find them. In a year from now, search Google's News tab for "internet explorer 11" may turn up completely different types of stories.) – apsillers Feb 06 '15 at 17:40
  • I'm sorry i was banned for posting reference links but here is one: http://www.winbeta.org/news/your-authentication-cookies-could-be-grabs-latest-internet-explorer-11-vulnerability –  Feb 06 '15 at 18:22