gipsies

In the future people might think the same about Bitcoin and AI.

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.

Website with a short explanain: https://tunnelcrack.mathyvanhoef.com

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..

Sometimes there are also silly driver bugs that allow you to get the real MAC address of a device when the user is using a spoofed MAC address :) http://www.mathyvanhoef.com/2013/11/unmasking-spoofed-mac-ad...

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.

A wild claim without any source. The owner set the IP to localhost himself.

https://twitter.com/briankrebs/status/779144394360381440

That will be an interesting read. Though not having a table of contents for a 117 page (double column!) report really isn't ideal..

- 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...

Or by using a trusted minifier on the source code yourself, as mentioned in the link.

Because in the paper they tested the attack with 1x2^27 requests, then with 2x2^27 requests, then 3x2^27, etc etc.

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.

> No offense, but it doesn't sound like you know fully what you're talking about.

About that ...

MAC addresses are not checked unless you use an extra tool for this. For example, a large institution (university, company, etc) can have many access points, each with a unique MAC address. However the SSID is unique among all Access Points. Your device will only check the SSID, try to connect (using mutual authentication), but no MAC address checks take place. You don't need to know or use the MAC address of the target network to clone it. You can just use any MAC address you want, that is if you know the password of it, or are cloning an unprotected network.

All WPA or WPA2 secured networks use mutual authentication. Since you do not know the password of my home network, my device will refuse to connect to it. In particular the 4-way EAPOL handshake will fail, since the challenge-response algorithm detects that you don't know the password. This is "only" an issue if you have open networks in your Network List.

A bruteforce attack against the PSK handshake requires only a single handshake to be captured. There are no known techniques to speed up the attack if more handshakes are captured.

Man-in-the-middle attacks against WPA are not trivial at all. The client and access point perform mutual authentication. If you don't know the password, you can't put up an identical rogue access point. The passphrase is never explicitly included in the handshake, only in "protected" forms (in challenge/response messages).

This is misleading. When using WPA the client and access point perform mutual authentication. This means that if you don't know the password, you cannot set up a rogue access point that "copies the target access point's settings". Because you don't know the password! And if you'd use a random password, the client will refuse to connect to the rogue AP.

The tool is actually creating a second, unencrypted network. On Windows it will give you a warning that the configuration of the network has changed. On Android you'd have to manually reconnect to the unencrypted network. So their method doesn't automatically perform a man-in-the-middle attack. A decent setup will warn you about this. Sure, if a user ignores all OS warnings, connects to an unencrypted network anyway, and feels the need to type his password in random fields s/he never saw before, then this will work [3].

What would be more interesting is to jam the target network, using an actual jammer [1], and then perform a KARMA man-in-the-middle attack [2]. The idea is to listen for probe requests to unencrypted networks, and then clone that unencrypted network. In this case the user would automatically connect, making the attack more likely to succeed...

[1] http://people.cs.kuleuven.be/~mathy.vanhoef/papers/acsac2014...

[2] http://www.theta44.org/karma/

[3] Perhaps I'm a bit cynical, but I suppose it might actually work some of the time... :(

Calling it remotely exploitable indeed seems misleading. A lot of the article is just fluf without real content.

A microwave operates around the 2.4 GHz frequency, so it likely shields only against those frequencies. This is where WiFi lives (in particular the higher channel numbers around 11 and 13). So test the impact on WiFi reception?

Ha, I've read that paper before, Mr. Guido Pallemans :)

When you turn your WiFi on, you can be tracked and attacked very easily. This is been known for a while, though not widely enough.

If at one time you connected to an open network, your devices continues to scan for that network. I can spoof that network, you connect to it, and then I intercept all traffic. A full framework has been created for this, complete with the ability to fingerprint your browser/OS and send exploits to your device [1]. Even if you only connect to password protected networks, it's possible (without access to the real AP) to let your clients send parts of the EAPOL handshake, and then perform a bruteforce attack. Weak passwords are cracked, meaning I can again intercept all traffic and possibly exploit your device.

So you only connect to one single network, strong password. Good. I can still track your MAC address. Even with one single device I can estimate the distance and the angle of your signal [2]. Hence I know your location, at all times. So you prevent MAC address tracking by using an identifier-free link layer protocol [3] (this doesn't exist in practice, only researchers made a demo showing its possible). Though a lot better, even with such a system it's possible to track the movement of devices purely based on the fingerprint of the physical WiFi signal [4]. Given sufficient location data it's likely to again (automatically) de-anonimize the dataset and track your movements (it's more complicated, yes, but still possible).

[1] http://www.sensepost.com/blog/7557.html

[2] Avoiding Multipath to Revive Inbuilding WiFi Localization

[3] Improving Wireless Privacy with an Identifier-Free Link Layer Protocol Ben

[4] SecureArray: improving wifi security with fine-grained physical-layer information

Even with enough MIMO 802.11n devices it's still practically impossible. They essentially need access to the raw signals to do all their calculations, but this isn't provided by drivers/firmware/devices.

If you're really lucky you have a device with open source firmware [1]. However even that firmware can only interface with the PHY layer by writing to registers to change the configuration of the device. Essentially the modulation of the signals is done in hardware, and you only control MAC aspects of it (things like disabling carrier sense is possible, changing backoff behavior, inter-frame wait timings, etc). But you can't access the real signal, it's a hardware limitation, so this not possible using existing devices.

[1] https://github.com/qca/open-ath9k-htc-firmware

I remember playing a lot with my old TI-83. One of the most impressive games was DOOM: http://www.ticalc.org/archives/files/fileinfo/238/23843.html Best video I can find: https://www.youtube.com/watch?v=TuupoxmeQ6U

Unfortunately I never had a TI-89. Would've been awesome if I had one back in the day, and then test these games: http://www.ticalc.org/archives/files/fileinfo/405/40593.html and http://www.ticalc.org/archives/files/fileinfo/323/32318.html