FT handshake vulnerability

[ramonfontes]

I have been trying to reproduce the FT handshake vulnerability with mac80211/hwsim and hostapd but it doesn't work anymore.

Firstly, I though that it could be related to the hostap version. Hence, I've installed v2.6 and I've moved the client to a new AP with the roam command provided by wpa_supplicant. According to the messages below, krack-ft-test.py can detect the FT reassociation but the AP doesn't reinstall the same IV.

[08:06:44] Detected Authentication frame, clearing client state
[08:06:44] Detected Authentication frame, clearing client state
[08:06:44] Detected FT reassociation frame
[08:06:45] Replaying Reassociation Request
[08:06:45] Detected FT reassociation frame
[08:06:46] Replaying Reassociation Request
[08:06:59] AP transmitted data using IV=1 (seq=24)
[08:06:59] Replaying Reassociation Request
[08:06:59] Detected FT reassociation frame
[08:06:59] AP transmitted data using IV=1 (seq=26)
[08:07:00] AP transmitted data using IV=2 (seq=27)
[08:07:00] Replaying Reassociation Request
[08:07:00] Detected FT reassociation frame
[08:07:00] AP transmitted data using IV=1 (seq=29)
[08:07:01] AP transmitted data using IV=2 (seq=30)
[08:07:01] Replaying Reassociation Request
[08:07:01] Detected FT reassociation frame
[08:07:01] AP transmitted data using IV=1 (seq=32)
[08:07:02] Replaying Reassociation Request
[08:07:02] Detected FT reassociation frame
[08:07:02] AP transmitted data using IV=1 (seq=35)

Then, I've found this commit and I though that it could be related to the kernel version. However, I've installed the kernel version 4.8 and the result is still the same.

Can you help me with this issue? I was able to reproduce the vulnerability three years ago and I don't know what I'm doing wrong now.

Thoughs?

[vanhoefm]

That kernel commit can indeed prevent the attack even when using an unpatched hostapd or wpa_supplicant. I think this patch also has been backported to older kernels due to its security impact. So you'll have to use a kernel that was released before the disclosure of the KRACK attacks and without maintenance/security patches beyond that date. Another option might be to install a "driver backports" that doesn't include this patch or where you revert this patch.

Another tip: run hostapd will extra debug output such as hostapd -dd -K and then see if it tries to reinstall the key.

[sacca97]

I am testing various configurations too, in particular using as AP the latest Kali and trying to find something that reinstalls an all-zero key, but even theoretically vulnerable systems (Ubuntu 16.04/17.10 with old kernel and vulnerable wpa_supplicant) are reported as not vulnerable. (They reuse a key, but not the all-zero apparently)

For the AP test I'm in the same situation as Ramon and I am sure to be using a fully non-patched system.

[vanhoefm]

I realize this is an older issue. But if this still a problem (or for someone reading this now): feel free to attach a packet capture and a debug output log to investigate this further.

[turbostar190]

I can reproduce the same output as Ramon using Ubuntu 16.04, kernel 4.4.0 and wpa_supplicant built from this report along with hostapd built from https://github.com/intrig-unicamp/mininet-wifi/tree/krack-attack .

IVs are reset after replaying reassociation request but the script doesn't output the "final" state "this is bad" or "this is good" (packet capture). With recent version of packages, the same test doesn't reset IVs either, so should I consider anyway as an "half win"?

[vanhoefm]

The script should display something like IV reuse detected (IV=%d, seq=%d). AP is vulnerable!. It won't explicitly say this is "good" or "bad".

[turbostar190]

Yeah sorry, I was referring to that line. It's not shown, like the snippet in the first post of this issue.

[vanhoefm]

I'm not sure why that's not shown. Are you using the virtual Python environment? I, unfortunately, don't have time to debug this currently. Manually seeing that IVs are being reused is currently probably sufficient to determine that the AP is vulnerable.

[turbostar190]

Yes, I'm using the Python3 virtual environment. This is the output of the script krack-ft-test.py on sta1: Xterm.sta1.log.

Manually seeing that IVs are being reused is currently probably sufficient to determine that the AP is vulnerable.

Great, thanks

[vanhoefm]

Based on that output I would say the AP is vulnerable. I'm going to reopen this issue since there's indeed something wrong with the code (if anyone reads this: pull requests to fix it are welcome).

[turbostar190]

To get the message to appear in a likely vulnerable environment I checked out that removing an IV list reset on every FT reassoc packet makes IV reuse detected appear. You can see this commit.

For my needs at the moment it's good, but I did not test it in a not vulnerable environment, for example.