Byline to Matthew Terry
Kr00k, a recent vulnerability found by Eset, causes devices sending traffic over Wi-Fi to send unencrypted data, like in the KRACK vulnerability. While a separate vulnerability, KRACK exploits devices by installing an all-zero encryption key, among other vulnerabilities, whereas Kr00k exploits a timing issue where the client or access point (AP) removes the key before finishing its connection leading to an all-zero encryption key. With both vulnerabilities the result leads to traffic sent unencrypted over Wi-Fi. Eset estimated that billions of devices with Broadcom and Cypress Wi-Fi chips send unencrypted traffic over WI-FI when exploited with this vulnerability. We have confirmed that no WatchGuard devices use Broadcom or Cypress chips, so no WatchGuard devices are vulnerable. Connected devices may still fall victim to this attack though.
Wi-Fi communication typically works by having clients and their connected access point take turns speaking and listening. Unless you use an Open Wi-Fi network, the devices communicate securely over the air using standards like WPA2 or WPA3, where the client and AP will create a unique key to encrypt the communication (derived from the pre-shared key (PSK) of your Wi-Fi network, or from extensible authentication protocol (EAP) parameters in a Wi-Fi network authenticating with 802.1x). While a device waits for its turn to communicate, it stores the chunks of data in a buffer. Then, when the device’s turn comes up, it will encrypt the data using the negotiated key and send it.
This communication can continue with each device taking turns sending and receiving data. The communication between a client and AP stops when one device decides that is wants to disconnect from the network. When this happens, usually one of the devices sends a message to disconnect from the wireless network.
When connecting or disconnecting, the AP and client authenticate or deauthenticate. When the session ends, the client deauthenticates with the AP using Management Frames. Additionally, a client or AP sending Management Frames over Wi-Fi must not encrypt this traffic since they haven’t negotiated a key yet. Therefore, you can spoof a deauthentication packet to disconnect a client. Kr00ck further exploits some devices by timing the deauthentication packet. When some Broadcom or Cypress chips receive a deauthnetication packet with data in the transmit buffer, it will clear the key then send the data in the transmit buffer, leading to traffic in the transmit buffer sent unencrypted.
An adversary could easily exploit this vulnerability with a simple device like a Wi-Fi pineapple. One only needs to send deauthnetication packets and monitor the traffic. Typically, the buffer will hold up to a few kilobytes of data. While that doesn’t sound like a lot, if timed correctly, for example, one could catch login details. Attackers could also repeatedly exploit the issue to build up significant leaked data over time.
We find Kr00k a less severe vulnerably than KRACK since the client would only send a small amount of traffic unencrypted. Additionally, no one could reasonably determine when the client sends traffic with the client personal information. But this attack affects billions of devices and only a minimal amount of knowledge is needed to exploit it. The ease and reliability of this exploit make gathering information simple, even with a low success rate for the exploit, to capture personal details for every try.
Broadcom and Cypress have released patches so venders can implement them. Consumers can mitigate against Kr00k, outside of patches from vendors, by configuring the use of WPA3 only, or enabling 802.11w protected Management Frames on their Wi-Fi SSID. WatchGuard also supports enabling 802.11w protected Management Frames with our Wi-Fi Cloud solution. Also, while Wireless Intrusion Prevention System (WIPS) cannot prevent attackers from sending deauthentication or disassociation frames to clients and access points, WatchGuard’s Wi-Fi Cloud managed access points have the capability of detecting and notifying administrators about deauthentication flood attacks, which happen when an attacker attempts to take advantage of this vulnerability. On the client side, SSL encryption in HTTPS traffic does keep most data safe from this exploit, but for unencrypted traffic you can use a trusted VPN to help protect the traffic.
Leave a Reply