0

If you set up a rogue AP with the same SSID as a commonly-known wireless access point, what prevents you from forging DNS queries answering with your own web server and stealing people's login credential cookies?

schroeder
  • 125,553
  • 55
  • 289
  • 326
Christian
  • 265
  • 1
  • 3
  • I wrote a blog detailing just how simple it can be to access the cookie data and hijack session with it: http://scotthel.me/advsesshijack – Scott Helme Aug 15 '13 at 11:45

2 Answers2

2

"Rouge" is a kind of lipstick. You mean a rogue access point.

There is nothing which prevents an evildoer from setting up an access point which mimics, from a outside, an access point that you would like to use. At least for any "open" access point. An attacker could find it somewhat more difficult to mimic an AP that requires authentication and does it properly (WPA2), such that your own computer is aware that authentication is expected and would complain loudly if it is not required by the AP. This also depends a lot on the exact kind of authentication. It is best to assume that rogue access points are always a possibility, and, indeed, ready-to-use hardware for that is available.

In reality, this is not different, qualitatively, from the Internet "in general". It should always be assumed that anything which goes over the Internet can be eavesdropped on and altered and rerouted; the WiFi part is just the first step in the journey over the wild Internet, and it is no more protected than all the others, despite tenacious beliefs to the contrary. (I think it comes from the authentication with a password; people think that "if there is a password then it is secure", without realizing that the password is not for their protection, but to limit access to the Internet access which is beyond the access point.)

The comprehensive solution against cookie stealing is HTTPS (aka "HTTP-within-SSL"). Even attackers who can redirect your requests to their own server cannot impersonate an https:// powered Web site (and steal the corresponding cookies), at least as long as:

  • the site does things properly (i.e., mostly, site-wide HTTPS, with no HTTP-only part, and cookies flagged as Secure and HttpOnly);
  • you take care to use HTTPS and not be directed to an HTTP-only clone of the site, in particular if the site requests a password entry;
  • you do not "click through" any warning about a bad certificate (and that's crucial for the whole thing).
Tom Leek
  • 170,038
  • 29
  • 342
  • 480
-2

In short, nothing. The only way to be totally safe would be to use a VPN through the untrusted network.

Once they have access to your traffic they could just use an SSL (TLS) interception proxy and MITM even HTTPS connections.

Scott Helme
  • 3,198
  • 3
  • 22
  • 32
  • HTTPS prevents MITM. – rook Aug 15 '13 at 16:32
  • No it doesn't: http://fiddler2.com/documentation/Configure-Fiddler/Tasks/DecryptHTTPS – Scott Helme Aug 16 '13 at 13:22
  • The user is most likely to either not see or ignore any warnings and simply bypass them to continue using the website. It's also covered here: http://security.stackexchange.com/questions/8145/does-https-prevent-man-in-the-middle-attacks-by-proxy-server If the user clicks through, the proxy can access traffic. – Scott Helme Aug 16 '13 at 13:25