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)?
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.
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.
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. )