Analyzing Recent Bluetooth CVEs
03 Aug 2020A growing number of Bluetooth security vulnerabilities have been published in recent years, and I decided to dig into whether there was a common cause behind the many vulnerabilities being published. For those without much background in Bluetooth, I’ll give a brief introduction. Much like the internet, Bluetooth was created at a time when security was not a top priority. It has gotten security upgrades as the years have passed, but the need for backward compatibility and device interoperability has resulted in a massive 3000+ page Bluetooth core specification. This specification has many shortcomings. For instance, it’s well organized, it often leaves implementation details open for interpretation, and it’s obviously quite complex. And the 3000+ page specification doesn’t cover everything - there are many supplements and additional pieces of documentation that exist for understanding the details of the Bluetooth protocol. This complexity can obscure insecurity, and it makes the protocol less approachable for a researcher who has minimal time to spend learning all about a new protocol.
I find Bluetooth interesting because it’s found in so many devices, and yet it doesn’t seem to get much love. In fact, the security-conscious OpenBSD even removed their default support for Bluetooth. I can’t claim to have advanced knowledge of Bluetooth, given the enormous complexity held within the Bluetooth core specification alone, but I was able to piece together a few things by looking at the details behind some of the recent vulnerabilities. Here is a table showing some of the notable Bluetooth vulnerabilities I examined. The same table, as well as other useful Bluetooth security resources, are stored in this “awesome” Bluetooth security repo.
| Name | Con & Year published | Site URL | Paper URL | Video URL | SIG Notice | Impacted | CVE |
|---|---|---|---|---|---|---|---|
| BlueBorne | Black Hat Europe 2017 | Site | Paper | Video | No Notice | BR/EDR | CVE-2017-8628, CVE-2017-0781, CVE-2017-0782, CVE-2017-0783, CVE-2017-0785, CVE-2017-14315, CVE-2017-1000250, CVE-2017-1000251, CVE-2017-14315, CVE-2017-1000410 |
| Bleedingbit | 2018 | Site | Paper | Video | No Notice | LE | CVE-2018-7080, CVE-2018-16986 |
| Fixed Coordinate Invalid Curve Attack | 2018 | Site | Paper | No Video | SIG Notice | BR/EDR/LE | CVE-2018-5383 |
| SweynTooth | 2019 | Site | Paper | Video | No Notice | LE | CVE-2019-16336, CVE-2019-17060, CVE-2019-17061, CVE-2019-17517, CVE-2019-17518, CVE-2019-17519, CVE-2019-17520, CVE-2019-19192, CVE-2019-19193, CVE-2019-19194, CVE-2019-19195, CVE-2019-19196, CVE-2020-10061, CVE-2020-10069, CVE-2020-13593, CVE-2020-13594, CVE-2020-13595 |
| KNOB | USENIX 2019 | Site | Paper | Video | SIG Notice | BR/EDR | CVE-2019-9506 |
| BIAS | IEEE S&P 2020 | Site | Paper | Video | SIG Notice | BR/EDR | CVE-2020-10135 |
| Pairing Method Confusion | 2020 | No Site | No Paper | No Video | SIG Notice | BR/EDR/LE | CVE-2020-10134 |
| BlueFrag | 2020 | Article | No Paper | No Video | No Notice | Android | CVE-2020-0022 |
| Spectra | Black Hat USA 2020 | Abstract | ? | ? | ? | ? | ? |
I wanted to investigate the techniques that the vulnerability researchers were using to find and test out the new vulnerabilities they uncovered, and here’s what I found. The 2017 Blueborne research paper was the earliest attack examined, and perhaps the first in the most recent wave of Bluetooth vulnerabilities. The Blueborne research relied heavily on open source Bluetooth stacks (Android’s stack and Linux’s BlueZ stack), with some firmware reversing for Apple’s Bluetooth-based stack. The other vulnerability discovery from Armis followed a similar pattern, as did the Fixed Coordinate Invalid Curve Attack, though they both relied more on reverse engineering of firmware. However, in late 2018, a presentation at 35C3 unveiled the InternalBlue tool, which allows a Broadcom Bluetooth chip to be instrumented in such a way that it can act like an SDR. This allows for the injection of custom packets and many other features, without the need to buy expensive SDR hardware with a configurable Bluetooth stack on top of it. The introduction of this tool clearly assisted the discovery of more Bluetooth vulnerabilities, since after this tool’s release, practically every major Bluetooth vulnerability discovery used InternalBlue during the research phase. I found it interesting that the BlueFrag vulnerability was the only recent vulnerability in the list that was found with fuzzing, since fuzzing has uncovered so many vulnerabilities in other projects. Will more Bluetooth vulnerabilities be found once a better Bluetooth fuzzing tool is released? I’d be willing to bet yes, but time will tell.
The table below is a summary of the tools and techniques I saw used in the papers describing these vulnerabilities. The Pairing Method Confusion vulnerability does not appear to have a paper published, which explains my uncertainty around the techniques used to find it.
| Name | Firmware Reversing? | Internal Blue? | Fuzzing? |
|---|---|---|---|
| BlueBorne | Yes | No | No |
| BleedingBit | Yes | No | No |
| Fixed Coordinate Invalid Curve Attack | Yes | No | No |
| Sweyntooth | Yes | Yes | Maybe |
| KNOB | Maybe | Yes | No |
| BIAS | Yes | Yes | No |
| Pairing Method Confusion | ? | ? | ? |
| BlueFrag | Yes | Yes | Yes |
Before you get overly concerned about your Bluetooth devices being attacked, it should be noted that many of the above attacks require an attacker to perform a man-in-the-middle (MiTM) attack, which is harder in some circumstances than in others. While Bluetooth is considered a short-distance radio communication protocol, Bluetooth’s commonly quoted maximum range of 100 meters is only limited by the radios used. Radio transmissions can be sent and received from a much further distance than 100 m if proper radio equipment is used, as shown back in 2004 by the trifinite group. New attacks impacting the underlying Bluetooth specification are certainly something to watch out for due to the number of devices they impact. While a malicious Bluetooth worm has yet to appear in the wild, attacks such as BlueFrag make such a scenario a possibility. And since many IoT devices and older phones supporting Bluetooth are unlikely to receive Bluetooth firmware updates to mitigate attacks at the Bluetooth stack layer, these type of findings may have consequences in the coming years.
References
“awesome” Bluetooth security repository: https://github.com/engn33r/awesome-bluetooth-security