krackattacks reports that a patched wpa_supplicant is still vulnerable

[tutti-dutti]

I am logging this ticket just a precaution to whether if this is a legitimate problem with krackattacks.

I ran krackattacks-test-client.py against a patched wpa_supplicant. Wpa_supplicant version 2.6 with the 8 patched released here "https://w1.fi/security/2017-1/"

The results were mixed. Krackattacks claimed the patched wpa_supplicant is not vulnerable to " pairwise key reinstallation" but is still vulnerable to "group key reinstallations".

I have contacted wpa_supplicant working group. They recommend verifying the test tool. They also recommend that I look into our "DUT Wi-Fi driver/firmware not implementing CCMP replay protection correctly". Hopefully it is because of my wifi driver. But is there a chance that might be because of krackattacks?

Here are the 2 reports from krackattacks:

[18:55:23] aa:bb:bb:dd:ee: client DOESN'T seem vulnerable to pairwise key reinstallation in the 4-way handshake (using standard attack).

[18:55:34] aa:bb:bb:dd:ee: Received 5 unique replies to replayed broadcast ARP requests. Client is vulnerable to group [18:55:34] key reinstallations in the 4-way handshake (or client accepts replayed broadcast frames)!

My environment:

CPU: Freescale imx28 OS: linux 3.10.6 armv5tejl GNU/Linux Wifi driver: rt2800usb

[kangdd]

@tutti-dutti , how about you now? My testing result is same as yours.

I did following testing on my Qcom develop board(Android6): 1) with all 8 patches, result: same as yours, not vulnerable to pairwise key reinstallation, but vulnerable to group key reinstallation. 2) without any patch, result: still same as 1).

I began to think if I ran the test script correctly. So I continued to test several cell phones I have. The results are different.

The complete testing result:

	pairwise key reinstallation	group key reinstallation
LG G3(Android 6)	Vulnerable	Vulnerable
Sumsung GalaxyTabS2(Android 6)	Vulnerable	Vulnerable
Apple iPad(iOS10.3.1)	Not vulnerable	Not vulnerable
Qcom dev board(Android 6)(before patch)	Not vulnerable	Vulnerable
Qcom dev board(Android 6)(after patch)	Not vulnerable	Vulnerable

AP1: virtualBox Kali Linux with TP-WN722N or AP2: Ubuntu 14.04 (krackattacks-test-client.py can also run on ubtuntu as soon as configuring python correctly.)

So I'm really confused. It seems the test script is right(different wifi station has different testing result.). But why did the patches not works?

I got the patches from Google Android Open Source project: https://source.android.com/security/bulletin/2017-11-01#2017-11-06-details

[tutti-dutti]

@kangdd I vaguely remember that IOS might not be subjected to tptk vulnerability. I am still at the same boat. My focus now is on my wifi driver.

[kangdd]

@tutti-dutti Yeah, maybe wifi driver has some bad. I just saw Qualcomm said they will update wifi driver & firmware.

[neukatan]

@kangdd I was just running into same results and awaiting update from alliance. Do you mind sharing where QCom said they will update the firmware to address the group key reinstallation?

[kangdd]

@akatragadda I found the document about this on https://createpoint.qti.qualcomm.com. But it needs a account to log in.

[neukatan]

@kangdd thanks for quick response. Planning to reach out to Qualcomm about the details, will keep the thread posted if I find anything interesting.

[kangdd]

@vanhoefm On your official website, it said:

_"Because Android uses wpasupplicant, Android 6.0 and above also contains this vulnerability. This makes it trivial to intercept and manipulate traffic sent by these Linux and Android devices. Note that currently 50% of Android devices are vulnerable to this exceptionally devastating variant of our attack."

But I tested my Galaxy Nexus 3 (Android4.3, Google official ROM) with your script, it is also vulnerable to both pairwise key installation and group key installation.

I'm really confused by the result. Is it possible that there are something wrong in testing?

[ptdropper]

I am testing an older 2009 vintage WiFi device which is a patched version of wpa_supplicant version 2.3 and it also reports the same issue raised, "group key reinstallations in the group key handshake". I am testing both before and after results. The after results show that the pair wise vulnerability is not present, the group key reinstallation is still present.

[djpark121]

@ptdropper I am observing the same issue with both the krackattacks and WMA tool, except that I am using the latest wpa_supplicant off of master. I am also using the mainline mac80211 and cfg80211 drivers, and the latest patches from kernel release 4.14 have been backported for those drivers. I'm still seeing the group key reinstallation vulnerability, but not the pair wise vulnerability. wpa logs however show that the GTK is specifically NOT reinstalled, so the issue is very confusing.

[ptdropper]

Hi everyone For my board I have been successful in correcting the group key reinstallation vulnerability! I edited the wpa_supplicant configuration to tell the Makefile to enable the symbol "CONFIG_IEEE80211W" . In my case that symbol is commented out by default. After a code review of the patches, I found that the code for group key reinstallatoin is protected by the #define CONFIG_IEEE80211W I enabled the symbol, did make clean and then a typical build. Verified that the wpa_supplicant I built is on the target and ran the "krack-test-client.py --group" and the vulnerability is reported as corrected. Enjoy!

[kangdd]

@ptdropper congratulations! I am still on my way fighting with group key.

[vanhoefm]

Defining CONFIG_IEEE80211W is not required. It does not influence whether a device is vulnerable or not.

The problem is likely that the tested clients have another vulnerability: they accepted replayed broadcast and multicast frames. This is what they meant by the "DUT Wi-Fi driver/firmware not implementing CCMP replay protection correctly". Put differently, there is an additional bug in the driver of firmware of the Wi-Fi client being tested.

If the debug logs of wpa_supplicant don't show that a group key is being installed, they wpa_supplicant is patched correctly. The problem is in the driver or firmware of the Wi-Fi dongle of the client. Maybe use a different Wi-Fi card on the client device and see what happens then.

[ptdropper]

Thanks very much for that explanation. I know that the wifi device we are using has existing ARP issues we are trying to work around. This makes sense.

[DavidRau]

Hi all,

Thanks for your great support to clarify this topic.

I tried krackattacks-scripts many times to ensure my patch code works correctly. In my understanding, there are 6 test cases are included in krack-test-client.py with different parameters. And I am not so sure case#2 and case#5 are the same test completely.

krack-test-client.py (1) pairwise key reinstallation in the 4-way handshake (using standard attack) (2) group key reinstallation in the 4-way handshake

krack-test-client.py --group (3) group key reinstallation in the group key handshake

krack-test-client.py --tptk (4) pairwise key reinstallation in the 4-way handshake (using TPTK attack) (5) group key reinstallation in the 4-way handshake.

krack-test-client.py --tptk-rand (6) pairwise key reinstallation in the 4-way handshake (using TPTK-RAND attack)

Unfortunately, there are high fail rate when execute "krack-test-client.py --tptk-rand". krackattacks report my device is vulnerable or not randomly...

[12:13:04] xx:xx:xx:xx:xx:xx4: IV reuse detected (IV=1, seq=2). Client is vulnerable to pairwise key reinstallations in the 4-way handshake! [13:22:45] xx:xx:xx:xx:xx:xx: client DOESN'T seem vulnerable to pairwise key reinstallation in the 4-way handshake (using TPTK-RAND attack).

Any ideas?

[vanhoefm]

To people that might still see this issue: first test whether the device accepts replayed broadcast traffic (using ./krack-test-client.py --replay-broadcast).

[wabbas55]

I have tried testing the patched supplicant using "krack-test-client.py --group" and in supplicant log I can see that it says WPA: Not reinstalling already in-use GTK to the driver after group handshake completed state but even then the script log on Linux says Client reinstalls the group key in the group key handshake (this is bad) or client accepts replayed broadcast frames.

On the other hand, if I run this test on un-patched supplicant, the supplicant log says WPA: Installing GTK to the driver after group handshake completed state.

Since the wpa supplicant is not reinstalling group key, do I still need to patch the wifi driver. Isn't this enough.

[vbora2]

On a patched wpa_supplicant 2.6 I am seeing only failures for the "krack-test-client.py --tptk-rand" test. All other ones pass (including --replay-broadcast). The errors are:

[12:12:55] 48:e2:44:c6:a2:b3: IV reuse detected (IV=6, seq=5). Client reinstalls the pairwise key in the 4-way handshake (this is bad)

[12:15:38] 48:e2:44:c6:a2:b3: usage of all-zero key detected (IV=5, seq=4). Client (re)installs an all-zero key in the 4-way handshake (this is very bad).

Any idea why this might be happening? Do I need to patch the driver too?

[vanhoefm]

The vulnerability regarding broadcast frames is likely a duplicate of #36

Normally patches wpa_supplicant is sufficient to prevent the --tptk-rand test from failing. Closing due to old age.