BlueToolkit

Extensible Bluetooth Classic vulnerability testing framework based on simple YAML DSL.

Documentation • Install • Usage • Supported Exploits • Bluetooth Classic and BLE vulnerabilities and attacks • Results • Hardware

BlueToolkit is an extensible Bluetooth Classic vulnerability testing framework that helps uncover new and old vulnerabilities in Bluetooth-enabled devices.

It works by executing templated exploits one by one and verifying appropriate properties based on the template logic. The toolkit is extensible and allows new research to be added to the centralized testing toolkit. There are 43 Bluetooth exploits available in the toolkit, from known public exploits and tools to custom-developed ones.

The framework works in a Black-box fashion, but it is also possible to operate the toolkit in a Gray-box fashion. For that one needs to extend the framework and connect it to the Operating System of the target so that it would be possible to observe Bluetooth logs and guarantee no false positives.

Also, we have already used our framework and were able to find 64 new vulnerabilities in 22 cars (Audi, BMW, Chevrolet, Honda, Hyundai, Mercedes-Benz, Mini, Opel, Polestar, Renault, Skoda, Toyota, VW, Tesla).

We have a dedicated repository that provides various types of vulnerability templates.

Credit

This work has been done at Cyber Defence Campus and System Security Group at ETH Zurich.

Install BlueToolkit

BlueToolkit has 2 installation stages: general and specific module installation. The general installation downloads the code, modules and tools available in the toolkit and tries to set up modules that do not require human interaction. The specific module installation requires a human to verify that the needed hardware is connected to the device on which the toolkit is being installed.

Install

We provide 2 installation options: virtual machine or Ubuntu/Debian.

Specific Module Install

Usage

sudo -E env PATH=$PATH bluekit -h

This will display help information for the tool. Here are all the parameters it supports.

usage: bluekit [-h] [-t TARGET] [-l] [-c] [-ct] [-ch] [-v VERBOSITY] [-ex EXCLUDEEXPLOITS [EXCLUDEEXPLOITS ...]] [-e EXPLOITS [EXPLOITS ...]] [-r] [-re] [-rej] [-hh HARDWARE [HARDWARE ...]] ...

positional arguments:
  rest

options:
  -h, --help            show this help message and exit
  -t TARGET, --target TARGET
                        target MAC address
  -l, --listexploits    List exploits or not
  -c, --checksetup      Check whether Braktooth is available and setup
  -ct, --checktarget    Check connectivity and availability of the target
  -ch, --checkpoint     Start from a checkpoint
  -v VERBOSITY, --verbosity VERBOSITY
                        Verbosity level
  -ex EXCLUDEEXPLOITS [EXCLUDEEXPLOITS ...], --excludeexploits EXCLUDEEXPLOITS [EXCLUDEEXPLOITS ...]
                        Exclude exploits, example --exclude exploit1, exploit2
  -e EXPLOITS [EXPLOITS ...], --exploits EXPLOITS [EXPLOITS ...]
                        Scan only for provided --exploits exploit1, exploit2; --exclude is not taken into account
  -r, --recon           Run a recon script
  -re, --report         Create a report for a target device
  -rej, --reportjson    Create a report for a target device
  -hh HARDWARE [HARDWARE ...], --hardware HARDWARE [HARDWARE ...]
                        Scan only for provided exploits based on hardware --hardware hardware1 hardware2; --exclude and --exploit are not taken into account

EXAMPLES:
Run bluekit recon:
   $ sudo -E env PATH=$PATH bluekit -t AA:BB:CC:DD:EE:FF -r

Run bluekit connectivity check:
   $ sudo -E env PATH=$PATH bluekit -t AA:BB:CC:DD:EE:FF -ct

Run bluekit with a specific exploit:
   $ sudo -E env PATH=$PATH bluekit -t AA:BB:CC:DD:EE:FF -e invalid_max_slot

Run bluekit with specific exploits:
   $ sudo -E env PATH=$PATH bluekit -t AA:BB:CC:DD:EE:FF -e invalid_max_slot au_rand_flooding internalblue_knob

Run bluekit and list all available exploits:
   $ sudo -E env PATH=$PATH bluekit -l

Documentation is available at: https://github.com/sgxgsx/BlueToolkit/wiki

Available Bluetooth Vulnerabilities and Attacks

BlueToolkit automatically downloads all vulnerability and hardware templates. BlueToolkit templates repository provides a full list of ready-to-use templates. Additionally, you can write your own templates and checks as well as add new hardware by following BlueToolkit's templating guide The YAML reference syntax is available here

We collected and classified Bluetooth vulnerabilities in an "Awesome Bluetooth Security" way. We used the following sources - ACM, IEEE SP, Blackhat, DEFCON, Car Hacking Village, NDSS, and Google Scholars. Looked for the following keywords in Search Engines such as Google, Baidu, Yandex, Bing - Bluetooth security toolkit, Bluetooth exploits github, Bluetooth security framework, bluetooth pentesting toolkit. We also parsed all Github repositories based on the following parameters - topic:bluetooth topic:exploit, topic:bluetooth topic:security.

Currently BlueToolkit check the following vulnerabilities and attacks:

For manual attacks refer to the documentation.

Novel attacks

These attacks a novel/new and are tested by the framework

Vulnerabilities to be added soon

Bluetooth Vulnerabilities and Attacks

Additionally, we found the following Bluetooth Classic and Bluetooth Low Energy (BLE) vulnerabilities. The table has the following information about the attacks and vulnerabilities - name, type either implementation-specific, protocol-specific or affecting a BT profile, Bluetooth Type (BLE, BT, BT + BLE), BT versions affected, number of exploits, year released, CVE if available, CVSS if available, Hardware if required, Proof of Concept if available and additional information in the comment section with additional links or explanation.

The YAML DSL reference syntax is available here.

Results from testing

We tested 22 cars from the following manufacturers and were able to find 60+ new vulnerabilities in them: Audi, BMW, Chevrolet, Honda, Hyundai, Mercedes-Benz, Mini, Opel, Polestar, Renault, Skoda, Toyota, VW, Tesla.

We responsibly disclosed all of the vulnerabilities. All manufacturers had time to fix the vulnerabilities but not all of them did or wanted to!

Novel Attacks

Insecure NC Implementation

The IVI system does not properly implement the Numeric Comparison authentication protocol as in the core specification of the Bluetooth which makes a link to be non-authenticated and thus vulnerable to the NiNo, Method Confusion and custom MitM attacks.

There are 3 possible variations:

1. The IVI/device doesn't require a confirmation for pairing (e.g. no button to confirm the pairing) (Renault, Hyundai cars)
2. The static number is always shown. (BMW, Mini cars)
3. The IVI shows a pairing window without a pairing number to compare. (Audi)

There are 2 possible reasons:

1. State problem
2. Design problem

In case of the state problem an adversary needs to connect to the IVI(other device) with a capability other than DisplayYesNo and the IVI should try to execute a broken Numeric Comparison and not Passkey or Just Works.

In case of a design problem, one simply needs to observe the pairing process and what is required of a used on a target device (IVI).

Examples of vulnerable cars:

For the PoC steps please consult contact extractor documentation

Vehicular NiNo

The vehicle allows connections to a device with no input or output capabilities. According to the specification if one of the devices has a NoInputNoOutput capability, then the pairing mode used is named Just Works and such a link should be considered unauthenticated and vulnerable to MitM attacks. This results in an adjacent adversary being able to execute a practical attack and establish a MitM position.

Important distinction: In this case, the vehicle doesn't allow NoInputNoOutput devices to initiate a connection to the IVI, but fails to check the same for a connection initiated by the IVI. The attack window is smaller than in a usual NiNo attack but still exists.

Note on NiNo devices in the vehicular domain: In the vehicular domain, the usage of NiNo devices such as headphones is not frequent if legal at all while driving. When it comes to the smartphone domain a connection to such devices is considered a feature and a usability trade-off to enable wireless headphones for example. As such a use-case is not present in the vehicular domain then it's better to disallow connection from such devices, which many of the manufacturers do already.

For the PoC steps please consult contact extractor documentation

Contact Extractor attack

The vehicle IVI system allows a physical adversary to extract previously shared through Bluetooth contacts. This happens due to incorrect handling of access control for newly created BT sessions for already known MAC addresses.

Examples of vulnerable cars:

For the PoC steps please consult contact extractor documentation

Hardware

To test all vulnerabilities one would need to buy additional hardware:

• ESP-WROVER-KIT-VE for Braktooth vulnerabilities
• Nexus5 (phone) for Internalblue-based vulnerabilities. It also could be substituted by CYW20735, but an additional hardware profile would be needed and 2 exploits won't be reproducible.
• CYW920819M2EVB-01 for BIAS, BLUR and BLUFFS attacks

Running Bluetoolkit

See https://github.com/sgxgsx/BlueToolkit/wiki for details on running BlueToolkit

License

BlueToolkit is distributed under MIT License