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?
