Qualcomm’s monthly security bulletins show an interesting trend with their Wi-Fi chips, which for some reason hardly receive any attention.
Here’s what I found looking at the past 13 months:
- There are critical remotely exploitable Wi-Fi vulnerabilities. Looking at the past 1 year (including April 2021 bulletin), Qualcomm fixed 44(!) remotely exploitable Wi-Fi vulnerabilities of which 1 was ranked critical and most of the rest ranked high (according to Qualcomm). Looking back a little further reveals even more such vulnerabilities (e.g. 12 fixed in February 21, with at least one ranked as critical).
- Wi-Fi vulnerabilities are being discovered and addressed all year round. Wi-Fi vulnerabilities were fixed in 8 of 12 monthly security releases.
- FragAttacks are an issue. 12 out of the 44 vulnerabilities are related to the #FragAttacks paper by @Mathy Vanhoef. The rest are spread between buffer overflow, buffer overread and some lesser issues.
- Exploits are easy. Although not a lot of information is available about most of the vulnerabilities, the text, combined with some available exploit code and our own research, suggest that they are extremely easy to exploit
- Exploits can be carried out remotely. Unlike Intel’s incorrect assessment of Wi-Fi vulnerabilities, Qualcomm considers Wi-Fi attacks to be REMOTE attacks.
- Patching is impossible. Although some of the fixed code is directly distributed by Qualcomm, approximately 50% of the vulnerabilities are found in open-source code maintained by Qualcomm. This means that fixes need to be compiled and distributed by OEMs leaving no no “single source” for patches.
The Disturbing Trend
Just a couple of months ago AirEye published a post about Intel’s release of numerous security patches related to network airspace attacks (i.e. zero-click Wi-Fi attacks).
Unfortunately, it is impractical for any organization to maintain a complete inventory of all Qualcomm, Intel or any other Wi-Fi chip dependent devices, not to mention keep track of the different patches required from different vendors that OEM the manufacturer’s chipset and code.
These indicate a disturbing trend: an insanely large, unknown and unprotected attack surface that is being neglected by organizations today.
What can organizations do then?
As a start, an organization needs to accept that their Wi-Fi enabled devices are inherently vulnerable to over-the-air attacks. These attacks can be carried out remotely through surrounding wireless equipment and can therefore put the entire organization at riskThe organization then needs to consider how under that assumption they are protected. This is where the Network Airspace Control and Protection (NACP) solution comes in. The NACP monitors the complete network airspace of the organization and identifies all wireless assets in the network airspace. It then classifies what is a corporate asset and what is not, i.e. what can be perceived as Antenna for Hire. Accordingly, it prevents wireless connections between corporate assets and Antenna for Hire as well as communication between corporate assets that is against corporate policy. That way, regardless of vulnerability of the underlying wireless chip, a device is not exploited. Only a NACP is positioned to do that.
Full Details
For those readers who look for the gory details, here’s a list of the remotely exploitable Wi-Fi vulnerabilities I picked up from Qualcomm’s security bulletins for the past 13 months:
Bulleting | #Vulnerabilities / Max severity | CVEs | Comment |
---|---|---|---|
March 22 | 2 / High | CVE-2021-35088 CVE-2021-35117 |
|
February 22 | 0 | ||
January 22 | 0 | ||
December 21 | 0 | ||
November 21 | 2 / High | CVE-2021-30321 CVE-2021-1903 |
|
October 21 | 7 / High | CVE-2020-11303 CVE-2021-30302 CVE-2021-30304 CVE-2021-30310 CVE-2021-1977 CVE-2021-1980 CVE-2021-30312 |
|
September 21 | 4 / High | CVE-2021-1971 CVE-2021-1941 CVE-2021-1948 CVE-2021-1974 |
|
August 21 | 14 / High | CVE-2020-26140 CVE-2020-26143 CVE-2020-26144 CVE-2020-26147 CVE-2020-11264 CVE-2020-11301 CVE-2020-24587 CVE-2020-24588 CVE-2020-26139 CVE-2020-26141 CVE-2020-26145 CVE-2020-26146 CVE-2021-1972 CVE-2021-1976 |
FragAttacks |
July 21 | 12 / Critical | CVE-2021-1887 CVE-2021-1938 CVE-2021-1953 CVE-2021-1896 CVE-2021-1965 CVE-2021-1907 CVE-2021-1943 CVE-2021-1945 CVE-2021-1954 CVE-2021-1955 CVE-2021-1964 CVE-2021-1970 |
|
June 21 | 1 / High | CVE-2021-1937 | |
May 21 | 2 / High | CVE-2021-1925 CVE-2021-1915 |
|
April 21 | 0 | ||
March 21 | 0 | ||
February 21 | 11 / Critical | CVE-2020-11269 CVE-2020-11270 CVE-2020-11275 CVE-2020-11276 CVE-2020-11278 CVE-2020-11280 CVE-2020-11281 CVE-2020-11287 CVE-2020-11296 CVE-2020-11272 CVE-2020-11297 |