It did. I'm not sure AI has this energy. We quickly skipped the "early tinkering" phase of AI and jumped straight to the annoying "let's put this technology into everything" stage like the blockchain craze of ~2018+. Perhaps the difference is how "top-down" AI has been. Most of the push has come from massive companies trying to get people to use it instead of people finding it organically.
Early internet of 90s+ had a pretty easy learning curve. Think: HTML and a Javascript fart button. Whereas Machine Learning and Large Language Models aka AI have a pretty steep learning curve that I'm working on now. Bitcoin is kind of both, where one can easily interact with the coin trading and/or dive into the complex world of cryptography.
I miss when "fed-pegged lightning side chains" peddled by Blockstream, Luke, Greg et al was the biggest load of buzzwordy self-serving bullshit in the space.
Yeah, we will fondly reminisce about the planet-destroying ponzi scheme which made it so convenient to pay for illegal goods, scams and ransoms to cryptolockers. What a nice unnecessary ecological catastrophe we managed to concoct out of nothing.
There needs to be extra evidence before claiming that "virtually all VPNs apps" are vulnerable. From my understanding, they tested WireGuard on multiple platforms. However, other VPN clients may install extra firewall rules, I've seen that happen with VPNs on Windows/macOS/Linux.
Looks like many VPNs allow access to the local network. And you can assign public IP ranges to the local network which.. is enough to make clients leak traffic to those IP addresses.
Several of the implementation flaws allow an attacker to essentially inject plaintext frames in a Wi-Fi network. All that's needed is being within range of the network (with an extender you can still be far away). I agree that the design flaws aren't that serious! But that's also explicitly mentioned on the website so...
Edit: injection can be used to punch a hole in the router's NAT so someone can directly try to attack your devices. As always there world isn't burning down. But I think it's interesting research :)
I agree, it absolutely is interesting research, and I appreciate the detailed explanation that was published.
Although the proximity requirement severely limits the possible impact, it does make us think again about the security of our Wi-Fi networks, and as a result we may identify areas to improve, which is a benefit.
What's actually interesting is that they have some world-top cryptographers and security researchers (e.g. invented AES and SHA-3). So part of that money goes to academia, and with good results :) The government agencies are lagging behind though.
If we look at the paper then these remarks are all discussed:
- Defending against downgrade attack: "A client should remember if a network supports WPA3-SAE. That is, after successfully connecting using SAE [..] the client must never connect to this network using a weaker handshake". The Google Pixel 3 is thankfully already doing this, but others aren't. So perfectly preventable, and something the Wi-Fi Alliance could have included in their WPA3 specification.
- Side-channel leaks: "A backwards-compatible countermeasure is to replace the two vulnerable branches with a constant-time select utility, and use constant time Legendre symbol computation as defined in [73]". The WPA3 standard already contained certain side-channel defenses, but it was still vulnerable. They could've also included these new defenses in the WPA3 standard.
- Denial-of-Service attack: "... our attack is more efficient than a straightforward DoS where an attacker simply jams the channel." We only needed to inject 10 commit frames every second to overload a professional AP..
- Modern crypto standards should be written so the chance of implementation bugs is low. For example, the new hash-to-curve algorithms being standardized include side-channel defenses in the specification itself. See their usage of the CMOV instruction that provides a "Common software implementations of constant-time selects" https://tools.ietf.org/html/draft-irtf-cfrg-hash-to-curve-03
"A client should remember" just transfers things to first trust attacks, if you want to do it right you'd have to make sure you add the network to the device as WPA3 only from the get go.
Side channel attacks, sure, the standard could also have just said "don't be vulnerable to side channel attacks when generating secure data" along with everything else you should do to make a secure system.
Does it really matter how efficient the DoS attack is if any consumer gear can do the in efficient future proof version anyways? As far as intelligent attacks go isn't this yet again an implementation detail where the AP should rate limit responses to a particular client based on it's resources?
Sure, Greenfield things should be written the best they reasonably can be but not being the best something could be doesn't equate to insecure. It's a valid complaint about the standard but not an insecurity.
Again the paper had valid interesting findings in real world side channel attacks and some valid complaints that Dragonfly could have been implemented in better way but it's not focused on attacking those instead it's focused on making big noise about how bad running things in WPA2 mode is bad under the title of being about WPA3.
I again feel that most of these points are all discussed in the paper. Trust-on-first-usage is also used in SSH. Attack uses spoof MAC addresses, hard to rate-limit that. Modern crypto should be designed to reduce chance of implementation flaws. Paper concludes that WPA3 is still better than WPA2. Most attacks are on WPA3's Dragonfly. Etc. The most practical attacks are downgrades to WPA2 though, so the press might focus too much on that..
This is very similar to our earlier work on the security of MAC address randomization: http://papers.mathyvanhoef.com/asiaccs2016.pdf They provide some more practical details if you want to implement our probe request fingerprint tracking mechanism. This is a passive tracking technique.
Their method to track all devices requires actively sending packets for every single MAC address that is being tracked. The (imperfect) passive tracking techniques can be used to reduce the number of MAC addresses you have to try though. Nice finding overall! And it will likely be hard to patch this issue..
No, the standard is secure. This is a vulnerability in the implementation. The comment in the code merely says that the explicit definition of the state machine behind a 4-way handshake implementation is not in the standard (but it's described in prose). Most standards don't provide explicit state machines.
The 802.11i is the official standard. WPA1 is based on a draft of 802.11i, while WPA2 is based on the final version of 802.11i. All of them contain the 4-way handshake.
Okay, thanks for the clarification. I guess my main point of confusion is why it would work (edit: that is, why an OpenBSD client would be able to connect pre-patch), but I guess if there's no actual state machine that makes it possible for an attacker to "skip to the end"?
Exactly, since there is no state machine, an attacker can immediately send the last message. The client will try to check the integrity of this message. But it will use an uninitialized all-zero key to do this! So an attacker can spoof the last message. And once the client receives this message, it will accept all traffic.
If you're using a pre-shared key, the password is verified during the 4-way handshake. The thing is, if your password is wrong, then the Message Authentication Code (MAC) of the messages your are sending is wrong. The AP will simply drop frames with a wrong MAC, and will not respond to them. The problem is that as a client you do not know whether the AP is not responding because (1) the MAC was wrong, and hence the password was wrong; or (2) the message did not arrive at the AP (or you did not receive the response of the AP).
tl;dr: can't tell the difference between dropped messages due to wrong authentication check (i.e. wrong password), or dropped messages due to bad connection.
I think this is half right. There is still an L1 ACK, so the STA doesn't have to retry sending the packet, it knows it was received.
I believe what happens is AP sends Nonce to the STA, STA uses the PSK to send Message 2 back to the AP. It will receive a '802.11 Ack' but then no Message 3 of the 4-way handshake will ever come from the AP.
Good drivers see this and flag an invalid password warning back to the user within milliseconds. But bad drivers... sure, they will just keep assuming magic dust got in the way and if they just keep retrying the handshake enough maybe they will see a Message 3.
I'm not sure why from a security hardening perspective it's better not to specify the AP should send '802.11 Disassoc' immediately after receiving an invalid Message 2 with a proper error code so that the driver can message the UI that the password is wrong instantly.
Not really. The STA may know that its message was received, but can never be sure whether the AP replied. The reply from the AP could have been missed due to noise, or maybe it didn't reply at all. You cannot be sure. There are only heuristics.
Good drivers indeed tell you whether the message arrived or not. But it's up to the client to decide what to do with that information. And again, it's just a heuristic. I've read and messed with the code of four different Wi-Fi clients, and none of them attempt to detect a bad password this way. Most simply report an error after trying to retransmit message 2 multiple times (e.g. if wpa_supplicant got message 1 from the AP, but didn't get a reply to message 2, it warns that maybe the password was wrong).
While in this case I was wrong, DNS poisoning is certainly not out of the realm of what Verizon will do, and when a site resolves properly on one ISP and not another, I don't think it's a "wild claim" to assume that it's the ISP's fault.
