Android/recent wpa_supplicant impact assessment is misleading
Opened this issue · 2 comments
The KRACK author states that Android 6.0 devices and others using more recent versions of wpa_supplicant are vulnerable to an easier, more powerful attack. However, although the attack against those devices sounds scarier, the real-life implications of that attack are actually less worrisome than against other devices. The KRACK author did not look at the big picture.
The attack specific to those versions of wpa_supplicant which zero out the PTK works by taking over the connection from those devices to the access point. However, it does not allow the attacker to interact in any way with the original access point. Although the attacker now has full control over the connection to the device, they cannot forward it to the real AP and man-in-the-middle the resulting traffic (unless they have credentials to the AP, but then there are many other ways to attack it). This is unlike the original KRACK attack which does allow the attacker to decrypt and possibly modify data while the client remains connected to the original AP.
Crucially, we can already do similar things without relying on KRACK, intrinsic to the way WiFi works. If I want to take over your network connection, all I have to do is show up with a rogue access point with the SSID of a public WiFi that your device is likely to have stored, and then forcibly inject a deauth to kick it off its current network. Chances are it will join my rogue network of its own accord. Anyone who has ever connected to a public WiFi on their phone is vulnerable to this, and the impact is all but identical to what you can do with the specific form of KRACK we're talking about. This is a much simpler attack (you don't even need custom attack tools, just a aircrack to inject deauths and a standard AP) and works on every device.
Other than that, the worst you can do with this variant of KRACK relevant to the original AP's network is to sniff whatever traffic the client attempts to send to the original AP. However, since you can't reply appropriately (unless it's new connections to Internet hosts you can forward to), this is most likely of rather limited use.
Therefore, I would suggest changing the language around this to better reflect the reality of the situation. In my opinion, Android 6.0 and later devices are actually affected by KRACK in a less severe way, in practical situations, all things considered.
For further reading, the wpa_supplicant advisory has a more accurate description of the problem that gauges the impact on older versions as being more severe:
For the station/Supplicant side GTK/IGTK reinstallation and TK configuration:
All wpa_supplicant versions. The impact on older versions can be more severe due to earlier changes in this area: v2.3 and older can also reinstall the pairwise key and as such have similar impact as the AP FT case (CVE-2017-13077); v2.4 and v2.5 end up configuring an all-zero TK which breaks the normal data path, but could allow an attacker to decrypt all following frames from the station and to inject arbitrary frames to the station. In addition, a different message sequence involving 4-way handshake can result in configuration of an all-zero TK in v2.6 and the current snapshot of the development repository as of the publication of this advisory.
Also, personally, I think "disable WiFi and only use 4G" is completely unnecessary fear mongering, especially for the vast majority of people who only use Internet applications, often on public WiFi, which already must use HTTPS/TLS for security anyway. There is absolutely zero reason to be concerned for that use case. This attack only matters for very strange corner cases, like a hypothetical corporate app that may have a corporate SSID whitelisted and attempt to only communicate with intranet hosts when the device is on it.
Thank-you for the information -- I will circle back for discussion.
Keeping open now for the time being -- thanks!