Some 802.1x have inherent mitm attacks that have been called out since 2004 and never got the v2 (https://www.rfc-editor.org/rfc/rfc6677.html). EAP-TLS however is the best practice here + VLANs.
Hostapd now has support for multi pass SAE /WPA3 password as well. We have an implementation of dynamic VLAN+per device PSK with WPA3 (https://github.com/spr-networks/super) we've been using for a few years now.
Ironically one of the main pain points is Apple. keychain sync means all the apple devices on the same sync account should share a password for wireless. Secondly the MAC randomization timeouts require reassignment.
The trouble with SAE per device passwords is that the commit makes it difficult to evaluate more than one password per pairing without knowing the identity of a device (the MAC) a-priori, which is why it's harder to find this deployed in production. It's possible for an AP to cycle through a few attempts but not many, whereas in WPA2 an AP could rotate through all the passwords without a commit. The standard needs to adapt.
I was leaning towards using this configuration for splitting devices into VLANs while using one SSID. Yeah, dynamic VLAN+per device PSK would be best, but I'm probably happy enough with a shared PSK per VLAN to isolate a guest or IoT network. Would this VLAN isolation have prevented this attack? At least to prevent an attacker from jumping between VLANs? (I assume shared PSK per VLAN might be vulnerable to attacking client isolation within the VLAN?)
This attack exploits multi PSK networks precisely. If it's all one PSK the attacker can already throw up a rogue AP for WPA3 or just sniff/inject WPA2 outright. The back half of a secure multi PSK setup is deploying VLANs for segmentation, to block these attacks.
WiFi provides half-way measures with client isolation features that break down when the packets hit L3, or in some cases the broadcast key implementations are deficient allowing L2 attacks. The paper is about all of the fun ways they could pivot across networks, and they figured out how to enable full bidirectional MITM in a wider class of attacks than commonly known or previously published.
This is mostly accurate, to clarify the association IDs tie into what VLANs will be assigned and that does block all of the injection/MITM attacks. This also assumes that the VLAN segments are truly isolated from one another, as in they do not route traffic between each other by default including for broadcast and multicast traffic.
However client isolation should be a tool people have at their disposal. Consider the need for people to buy cloud IOT devices and throw them on a guest network (https://arstechnica.com/security/2024/09/massive-china-state...). It's also about keeping web-browsers away from these devices during regular use, because there are paths for malicious web pages to break into IOT devices.
What exactly a VLAN is (or rather, properly: broadcast domain) gets kinda fuzzy in enterprise controller based wifi setups… and client isolation isn't really different from what some switches sell as "Private VLAN" (but terminology is extremely ambiguous and overloaded in this area, that term can mean entirely different things across vendors or even products lines).
What exact security guarantees you get really depends on the sum total of the setup, especially if the wireless controller isn't also the IP router, or you do local exit (as opposed to haul-all-to-controller).
Yep, unfortunately fuzzy. For enterprise wifi deployments, one amusing thing to do when configuring 802.1X is to test ARP spoofing the upstream radius server after associating, and self-authenticate.
It might be interesting to go and apply some of the sneaky packet injection mechanisms in this paper actually to try to bypass ARP spoofing defenses.
EAP TLS provides strong authentication, is much better than the other enterprise authentication options, but will not block these lateral attacks from other authenticated devices. The second half of the deployment is putting each identity into a VLAN to defend against the L2/L3 disconnects that can occur.
I work on https://supernetworks.org/. We propose a solution to these flaws with per-device VLANs and encourage per-device passwords as well.
More practically the risk for these attacks is as follows. A simple password makes sense for easy setup on a guest network, that's treated as untrusted. These passwords can probably be cracked from sniffing a WPA2 key exchange -- who cares says the threat model, the network is untrusted. But this attack lets the insecure network pivot out into the secure one.
More precisely: the manufacturer's software on your consumer grade routers refuses to expose that functionality to the end user. They're almost always relying on VLANs behind the scenes to separate the WAN and LAN ports.
> They're almost always relying on VLANs behind the scenes to separate the WAN and LAN ports.
I don't believe this is true. I expect that what's going on there is the WAN and LAN ports on the switch [0] are in separate bridges.
Why do you believe that they're using VLANs behind the scenes? It seems silly to add and remove a whole-ass VLAN tag to traffic based on what port it comes in on. Do you have switch chip or other relevant documentation that indicates that this is what's going on?
[0] or WAN and LAN interfaces, if the ports are actually separate, entirely-independent interfaces, rather than bound up in a switch
It's trivial to look up the switch port configuration of a consumer router once you put OpenWRT on it. The most common topology is the CPU has two RGMII/XGMII or similar links to an 8-port switch chip, five more ports of the switch are connected PHYs for external ports and configured for the LAN VLAN, and the last port is connected to a PHY for an external port and configured for the WAN VLAN. This does not result in any VLAN tags being emitted over the wire, but from the perspective of the switch silicon it's just one of many possible VLAN configurations. Changing which physical port is the WAN port is as simple as assigning a different switch port to that VLAN. If you did want VLAN tags emitted on a particular port, it's a single checkbox or single-character config file change.
by complexity class that would be consensus, although the argument for building BPP systems is about the energy cost being orders of magnitude less and perhaps also some polynomial speedup
A direct equivalent, no, as stated in the introduction.
"Notably, while probabilistic computers can emulate quantum interference with polynomial resources, their convergence is in general believed to require
exponential time [10]. This challenge is known as the signproblem in Monte Carlo algorithms [11]."
the router sniffed plaintext http to grab HTTP User agents to put them into a curl bash command line string. Nice RCE from the browser.
reply