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 :)
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.
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..
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
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..
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.
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.
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).
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.
- At least in computer science, it's generally professors who organise the peer review (the Program Commitee)
- I've heard from several collegues that the editor introduced spelling mistakes. Sure, overall they might get some errors out, but a spellcheck is not needed.
- Well yes. But there is no need for that to be expensive.
- Do we need them for this? If there really is fraud, previous cases show it's their university that starts an investigation. I'm not sure if the effect of retracting a paper is that significant..
- If all papers were public in the first place, there is no need to contact someone if it's okay to reuse material.
Anyway publishers might provide some value, but not enough to demand we pay for every single paper, or pay costly subscriptions. They need to die already or adept.
Accurate Wi-Fi based indoor location positioning already exists, though with different pros and cons. For example, the following system still works reliably when walking around, but may be a bit less accurate. And it requires no calibration https://www.youtube.com/watch?v=foVqKLE4Mpk
That demo is based on the new 802.11mc standard. Surprisingly, this new standard isn't mentioned in the paper. So no comparison between this and their system...
Yes, but we present several techniques on how to generate these amounts of data. For TLS and HTTPS you can use JavaScript. For WPA-TKIP you need control of one TCP connection, and that is enough to generate the data. We're not saying it's a point and click attack, but it's a very good reason to start worrying :)
> I don't really see someone sitting there for 75 hours while this takes place without closing the browser/window/tab.
But that's not a problem. If the user closes the browser or tab, the attack can continue at a later point in time. It doesn't need to be collected all at once. As a concrete example, if you leave your computer at work running during the weekend, the attacker has enough time. Or if you leave it running during the night, the attack can be spread out over a few nights. I'm sure there are even more scenarios than just these two examples: there's room for quite some flexibility when performing the attack.