Cryptography @ Infosec.pub

610 readers

1 users here now

Questions, answers, discussions, and literature on the theory and practice of cryptography

Rules (longer version here)

Stick to cryptography / infosec
Be a good netizen - be kind, act in good faith, maintain high quality, don't mislead
Link directly to original sources
Don't use us to cheat on challenges or tests!
Crypto review requests must show the algorithm
CTF / challenges and puzzles must use modern crypto
Avoid making duplicate posts
All use of AI / LLM and their prompts MUST be disclosed in your submissions and comments

##Related resources;

Reddit cryptography forums 1 & 2; /r/crypto /r/cryptography
Cryptology ePrint archive
Discussion site for ePrint papers
Libera Chat's IRC:s #crypto - (IRC protocol URL)
Metzdowd cryptography mailing list
Randombit cryptography mailing list
StackExchange cryptography community

founded 2 years ago

MODERATORS

SqueamishOssifrage

TrustedThirdParty

AirSnitch: Demystifying and Breaking Client Isolation in Wi-Fi Networks (www.ndss-symposium.org)

submitted 1 month ago by Natanael@slrpnk.net to c/crypto

2 comments fedilink hide all child comments

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.

you are viewing a single comment's thread
view the rest of the comments

[–] litchralee@sh.itjust.works 1 points 1 month ago (1 children)

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.

[–] Natanael@slrpnk.net 1 points 1 month ago

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