From KrØØk to finding related vulnerabilities

KrØØk (formally CVE-2019-15126) is a vulnerability in Broadcom and Cypress Wi-Fi chips that allows unauthorized decryption of some WPA2-encrypted traffic. Specifically, the bug has led to wireless network data being encrypted with a WPA2 pairwise session key that is all zeros instead of the proper session key that had previously been established in the 4-way handshake. This undesirable state occurs on vulnerable Broadcom and Cypress chips following a Wi-Fi disassociation.

Figure 1. Overview of KrØØk - following a disassociation, data is transmitted encrypted with an all zero session key

Exploiting KrØØk allows adversaries to intercept and decrypt (potentially sensitive) data of interest and, when compared to other techniques commonly used against Wi-Fi, exploiting KrØØk has a significant advantage: while they need to be in range of the Wi-Fi signal, the attackers do not need to be authenticated and associated to the WLAN. In other words, they don’t need to know the Wi-Fi password.

We worked with the affected vendors (as well as ICASI) through a responsible disclosure process before we first publicly disclosed the flaw at the RSA Conference in February 2020. The ensuing publicity brought the issue to the attention of many more chipset and device manufacturers, some of which discovered they also had vulnerable products – and have since deployed patches. We are maintaining a list of related vendor advisories on this webpage[1].

While we did not observe CVE-2019-15126 in other Wi-Fi chips than Broadcom and Cypress, we did find that similar vulnerabilities affected chips by other vendors. These findings were first presented at Black Hat USA 2020 and we’re briefly outlining them below.

Qualcomm – CVE-2020-3702

One of the chips we looked at, aside from those from Broadcom and Cypress, was by Qualcomm. The vulnerability we discovered (which was assigned CVE-2020-3702) was also triggerable by a disassociation and led to undesirable disclosure of data by transmitting unencrypted data in the place of encrypted data frames – much like with KrØØk. The main difference is, however, that instead of being encrypted with an all-zero session key, the data is not encrypted at all (despite the encryption flags being set).

The devices we tested and found to have been vulnerable are the D-Link DCH-G020 Smart Home Hub and the Turris Omnia wireless router. Of course, any other unpatched devices using the vulnerable Qualcomm chipsets will also be vulnerable.

Following our disclosure, Qualcomm was very cooperative and in July released a fix to the proprietary driver used in their officially supported products. Not all devices with Qualcomm chips use this proprietary driver, however – in some cases, open source Linux drivers are used – such as the upstream “ath9k” driver, for example. As it’s not actively developed by Qualcomm, it’s not clear at the time of writing if it will receive a patch from Qualcomm or the open-source community.

MediaTek and Microsoft Azure Sphere

We also observed the manifestation of a similar vulnerability (i.e. lack of encryption) on some Wi-Fi chips by MediaTek.

One of the affected devices is the ASUS RT-AC52U router. Another one is the Microsoft Azure Sphere development kit, which we looked into as part of our Azure Sphere Security Research Challenge partnership. Azure Sphere uses MediaTek’s MT3620 microcontroller and targets a wide range of IoT applications, including smart home, commercial, industrial and many other domains.

According to MediaTek, software patches fixing the issue were released during March and April 2020. The fix for MT3620 was included in Azure Sphere OS version 20.07, released in July 2020.

Release of testing script

As more than five months have passed since we publicly disclosed the KrØØk vulnerability – and several proofs-of-concept have been published by independent researchers – we’ve decided to release the script we’ve been using to test whether devices are vulnerable to KrØØk. We have also included tests for the newer variants described here. This script can be used by researchers or device manufacturers to verify that specific devices have been patched and are no longer vulnerable.

Special thanks to our colleague Martin Kalužník, who greatly contributed to this research.

[1] If you have an advisory you would like added to this list please contact us at threatintel[at]eset.com.