It would mean (for example) that your local coffee shop could MITM their clients connecting to the bank through their free wifi. Being in a privileged network position isn't that hard, with all the mobile devices flying around everywhere.
Completely unscientific observation: More people in my local coffee shop are using phones than laptops, and more of those phones are Androids than iOS. I know anecdotally that the Chrome browser is very popular on Android. I would give even odds on there being more people to exploit with this than there were with goto fail.
I use coffee shop WiFi when I access useless sites such as Drudge Report. However, it's not hard to either
a) switch to cellular on a phone before accessing something important like a banking site
or b) use something like Personal Hotspot together with a phone switched to cellular to allow a laptop to access something important like a banking site
That's what I do. I certainly don't trust random WiFi for sensitive communications.
IMO you're much safer relying on AT&T or Verizon to connect you to key sites via cellular service rather than thru WiFi. OTOH I know that in the past AT&T has automatically switched my iPad from cellular to WiFi when I was at a coffee shop that had service from them. So this may be a little tricky in practice.
Even worse, from what I've observed, such networks are often not secure even against a trivial ARP spoof attack, so anyone connecting to the coffee shop Wi-Fi could mount this attack.
Is there any reasonable way to make them secure against ARP spoofing? As I understand it, it would require individual login from all clients (some form of 802.1x)?
And even if you do protect against ARP spoofing via 802.1x -- you would still need some kind of shared secret/certificate scheme to avoid a fake access point? As anyone sitting next to you is likely to be able to provide a stronger signal than the hotspot...
Reminds me that I had an idea to wrap up some kind of hot-spot with an easy to use internet cafe style time-limited access software distribution and offer up to local businesses... I suppose these days providing a screen for qr-code sharing of details would be a viable option...
To make them immune to the ARP spoofing in the general case is hard, but as I understand it, to make them immune to the specific case of clients other than the gateway impersonating the gateway (which is what people want to do for most MitM) is pretty straightforward. The access point is probably itself the gateway most of the time, so it knows the gateway's MAC (its own), and it can reliably refuse to forward ARP packets for other MACs claiming to be the gateway.
> it can reliably refuse to forward ARP packets for other MACs claiming to be the gateway.
I thought most wireless lans acted as an (shared medium) ethernet, that is, they allow clients to send packets directly client to client? That is, I thought [ed:naughty]-client could just broadcast ARP packets directly to the clients? Or does perhaps (ethernet) broadcast traffic go through the gateway?
None of this helps with a rouge AP, of course -- so it might be a bit academic.
In infrastructure mode, all WiFi traffic goes through the access point. Whether or not, from a configuration perspective, the access point lets you meddle with traffic that passes through it is a separate question, but I don't think there's anything wireless-protocol-wise that precludes it.
Just to add—in open networks masquerading as the AP is possible so long as you can reach the hosts with your Tx. This is mitigated with encryption, however, as I understand the WPA2 standard, I suppose you could send out a broadcast ARP response packet encrypted using the Group Transient Key pretending to be the AP. However, probably all sane clients would discard ARP responses that were broadcast, as normally, ARP responses should always be unicast to the requesting client.
How does a client actually authenticate a packet coming from the AP versus something else? The only info is a preshared key so it doesn't seem possible to have any true security there.
The PSK is used to derive pairwise keys between each station and the AP. However, if the attacker knows the PSK, it's theoretically impossible sufficiently advanced attacks. That's why enterprise networks use RADIUS for enhanced security.
I believe the AP has separate session keys per client (the shared secret is used for authenticating with the AP and setting up a session -- and yes, I guess that means if you know the shared secret the client expects you to use (eg: a note in a cafe) you can probably impersonate the AP at the point of client association) -- but the group key is special.
But as demonstrated up-thread I clearly need to refresh my knowledge of 802.11*...
(side-reply as direct reply is either in cool-down or limited due to depth)
Interesting, I hadn't really looked into 802.11alphabetsoup in terms of ad-hoc vs infrastructure -- wasn't aware the ap was a bottleneck. The natural next question is if there are any standard secure forms for ad-hoc networking?
It would seem that shared-secret should be easy enough (but probably with the same/similar security issues as other shared-media networks in addition to the possibility of guessing the key). Some form of certificate authentication, or kerberos like shared-secret-trusted-mediator should be possible? But having a look around, I can't seem to find any - certainly not any that could be expected to work with standard OSs and devices...?
I suppose one could simply use an unsecured ad-hoc network + vpn for routing? Still I don't know of any VPN-styles that would allow broadcast traffic over such a mesh network?
I'm not claiming that being in a position to MITM is super difficult, but in your given example it's unlikely that you'd be vulnerable since web browsers (outside of Chrome on Android) don't use OpenSSL. Additionally, there is a degree of sophistication required to attempt this attack that exceeds that of goto fail. So again, bad, but not as bad as goto fail.
