Kr00k vuln in WiFi chips that allows unauthorized decryption of traffic
1–10 of 31 posts
Re: Kr00k vuln in WiFi chips that allows unauthorized decryption of traffic
#2An interesting attack on WPA2 on unpatched devices.
This reminds me of the WPS reaver attack, which is a complete facepalm from an implementation perspective. Only 11,000 possible combinations, and trying 1 key every other second would net you the WPA password in "In 2011, a security researcher named Stefan Viehböck discovered a flaw in this implementation. The concept he introduced was based on the following facts:
Out of the 8 digits of the PIN, the last digit is a checksum, which leaves 7 digits to guess. The PIN is validated by dividing it into 2 halves. So first half leaves 10^4 = 10,000 guesses & 2nd half leaves 10^3 = 1000 guesses. So a total of 11000 guesses only, where it should be 10^8 = 100000000 guesses."
Re: Kr00k vuln in WiFi chips that allows unauthorized decryption of traffic
#3Is there a proof of concept out there yet? Also, does this require a firmware patch, or can it be mitigated via software?
edit: I can't reply to the comment below about iOS updates because the comment is dead, but I just would like to interject that iOS and macOS updates can, and sometimes do, contain firmware updates for hardware. The release notes for the macOS update that contains the fix doesn't specify if the fix is in firmware or software, but I suspect it is in the former.
Re: Kr00k vuln in WiFi chips that allows unauthorized decryption of traffic
#4The next time I update (wifi) routers I'm responsible for, I think I'm going to go fully Internet Only DMZ, and Wireguard 'VPN' for entry to the LAN.
Re: Kr00k vuln in WiFi chips that allows unauthorized decryption of traffic
#5Is there a proof of concept out there yet? Also, does this require a firmware patch, or can it be mitigated via software? edit: I can't reply to the comment below about iOS updates because the comment is dead, but I just would like to interject that iOS and macOS updates can, and sometimes do, contain firmware updates for hardware. The release notes for the macOS update that contains the fix doesn't specify if the fi…
The article mentions that iOS 13.2 fixes the issue. If an iOS update can fix it, then I think it would just be software.
Re: Kr00k vuln in WiFi chips that allows unauthorized decryption of traffic
#6Less sensationalist and more informative link: https://nvd.nist.gov/vuln/detail/CVE-2019-15126 (CVSS Severity Base Score: 3.1 Low)
Eh yeah, you shouldn't use WPA2 as your sole defence against data exfiltration. Nice way to drive traffic to your website though..
Re: Kr00k vuln in WiFi chips that allows unauthorized decryption of traffic
#7Is there a proof of concept out there yet? Also, does this require a firmware patch, or can it be mitigated via software? edit: I can't reply to the comment below about iOS updates because the comment is dead, but I just would like to interject that iOS and macOS updates can, and sometimes do, contain firmware updates for hardware. The release notes for the macOS update that contains the fix doesn't specify if the fi…
Since the bug is apparently in FullMAC devices, it would be a firmware fix in most cases (unless someone is running a FullMAC device as SoftMAC for whatever reason).
Also, the boundaries between firmware, hardware and (driver) software are pretty murky as far as Wi-Fi drivers are concerned: I remember reading that many FullMAC devices contain their own firmware in a ROM and have some room in on-chip RAM for patches (but not an entirely new firmware image!). These patches can be uploaded at device initialisation time and are contained in the device driver.
This is similar conceptually to microcode, both in that such updates are not persistent (i.e. have to be applied again after every boot) and optional (compared to a mandatory firmware blob upload, you won't notice if your driver is outdated or simply not installing updates for a known vulnerability).
Re: Kr00k vuln in WiFi chips that allows unauthorized decryption of traffic
#8The next time I update (wifi) routers I'm responsible for, I think I'm going to go fully Internet Only DMZ, and Wireguard 'VPN' for entry to the LAN.
That sounds nice on paper, but will make common things like accessing Plex-servers from apps on the set-top box, Chromecasting and what not a royal pain in the ass.
Re: Kr00k vuln in WiFi chips that allows unauthorized decryption of traffic
#9Is there a proof of concept out there yet? Also, does this require a firmware patch, or can it be mitigated via software? edit: I can't reply to the comment below about iOS updates because the comment is dead, but I just would like to interject that iOS and macOS updates can, and sometimes do, contain firmware updates for hardware. The release notes for the macOS update that contains the fix doesn't specify if the fi…
Since the bug is apparently in FullMAC devices, it would be a firmware fix in most cases (unless someone is running a FullMAC device as SoftMAC for whatever reason). Also, the boundaries between firmware, hardware and (driver) software are pretty murky as far as Wi-Fi drivers are concerned: I remember reading that many FullMAC devices contain their own firmware in a ROM and have some room in on-chip RAM for patches (…
Thanks for your detailed post.
> Also, the boundaries between firmware, hardware and (driver) software are pretty murky as far as Wi-Fi drivers are concerned
Yeah, this is why I ask if it can be fixed via software. I've been utterly surprised at the amount of bugs that exist in firmware but can be mitigated on the seemingly software-side of things.
I have a device that used the brcmfmac driver on Linux until today, and am hoping I won't have to shelve it forever.
Re: Kr00k vuln in WiFi chips that allows unauthorized decryption of traffic
#10Less sensationalist and more informative link: https://nvd.nist.gov/vuln/detail/CVE-2019-15126 (CVSS Severity Base Score: 3.1 Low) Eh yeah, you shouldn't use WPA2 as your sole defence against data exfiltration. Nice way to drive traffic to your website though..
To summarize the mechanism: the affected chips will transmit packets that are waiting in the Tx buffer even after the station was disassociated and because the station is disassociated (and thus the encryption key was zeroized), these packets are going to be transmitted encrypted with all-zero key.