In this paper, we undertake a structured security analysis of Wi-Fi client isolation and uncover new classes of attacks that bypass this protection. We identify several root causes behind these weaknesses. First, Wi-Fi keys that protect broadcast frames are improperly managed and can be abused to bypass client isolation. Second, isolation is often only enforced at the MAC or IP layer, but not both. Third, weak synchronization of a client’s identity across the network stack allows one to bypass Wi-Fi client isolation at the network layer instead, enabling the interception of uplink and downlink traffic of other clients as well as internal backend devices. Every tested router and network was vulnerable to at least one attack. More broadly, the lack of standardization leads to inconsistent, ad hoc, and often incomplete implementations of isolation across vendors.
Having skimmed through the paper, the lack of coordination between 802.11, L2 switching, and L3 routing is indeed alarming. But I think this one takes the cake:
In the RADIUS protocol, the client is the AP and the server is the remote authentication server, and they pre-share a passphrase. This passphrase is used to encrypt and authenticate RADIUS packet fields, such as to encrypt PMK in transit and derive the Message Authenticator, a hash for integrity-protection. We verified that an attacker, having intercepted the first RADIUS packet sent from the enterprise AP, can brute-force the Message Authenticator and learn the AP passphrase.
If only the first packet between the AP and real RADIUS server is necessary to bypass the encryption between those two and compute the message authentication hash, then the encryption is hideously broken. That is to say, the encryption is not protecting anything and that alone sets a false expectation, even when the first packet can’t be intercepted.
That aaid, the manner of this interception of uplink-bound traffic is really sad: what sort of routing config would allow going downstream for the RADIUS serve? Something would have to be deeply wrong with how the control plane is configured, but I do concede that there are plausible networks that do this.
I’m assuming this is the same type of attack as against WiFi passwords in general, bruteforce of weak passwords. But otherwise yes, a PAKE algorithm instead for auth would completely prevent the ability to bruteforce based on watching traffic alone, and WPA3 already uses a PAKE and it should be used for everything which could be low entropy