BlueSpy – Spying on Bluetooth conversations
BlueSpy is a proof of concept for exploiting vulnerabilities in Bluetooth headsets and eavesdropping on private conversations
The first results following the publication of BSAM, a security methodology that allows for a complete and homogeneous assessment of Bluetooth devices security, have not been long in coming.
Its application has helped identify security problems in many Bluetooth headsets, showing that manufacturers must take Bluetooth security seriously to avoid, among other risks, unauthorized connections to these devices attempting to spy on conversations.
Using a Python script from Linux, automating the tasks required to exploit a common vulnerability in Bluetooth devices is possible. This vulnerability allows anyone to access the Bluetooth device without alerting or notifying the owner, i.e., entirely silently.
The demonstration focused on a particular high-end headset. Still, it became clear that headsets from other manufacturers are also affected by the same vulnerability, as the device only needs to support “JustWorks” pairing.
At the RootedCon Madrid 2024 security conference, Tarlogic presented BSAM and its research, demonstrating how to capture audio without the device user’s awareness and use it to eavesdrop on private conversations.
This open and collaborative methodology incorporates controls that assess the security of multiple aspects of Bluetooth communications and provides examples of vulnerabilities in this technology, which is widely used in mobile and low-power devices.
Vulnerability identification using BSAM
The methodology is divided into seven sections, representing the phases during an audit and addressing a Bluetooth device’s security aspects.
One of these sections is the inter-device discovery phase, in which devices broadcast and exchange announcement messages with information about the device’s identity and capabilities.
Among the security controls built into the discovery phase, it is particularly relevant to check the exposed name, the point at which the device is discoverable and the use of random MAC addresses.
In our case, the headsets are exposed to their name in the Bluetooth announcement messages, which immediately identify them.
On the other hand, the headsets use a public, static MAC address, which uniquely identifies them and makes their manufacturer easily identifiable.
Combining these factors makes a device easily identifiable as a target for an attack such as the one presented. It makes it possible to search for additional information, such as the specific model and whether it has a microphone.
Although the issues identified during the device discovery phase do not seem particularly relevant, they help direct the audit during the next phase of BSAM analysis: pairing.
Pairing is the process during which two Bluetooth devices generate a shared key. This key will be used to encrypt the link and authenticate both devices going forward. Without the shared key, the devices will typically not allow the connection to continue or will only allow limited interaction with each other.
The BSAM controls referred to the pairing stage check the security level during this procedure and the protection of the generated shared key. The security level of the pairing depends on the level of control the user has over the process. At the highest level of security, the user must enter a pin on both devices involved so that only devices explicitly authorized by the user can be paired.
For ease of use, Bluetooth implements an insecure pairing mechanism called “JustWorks”. This mechanism does not require any verification or notification to the user and allows any device to pair unattended and interact with it.
BlueSpy exploits the fact that the “JustWorks” mechanism can be used during pairing, which does not require secure pairing. In combination with a discoverable device in pairing mode, anyone using BlueSpy can initiate the pairing, set a shared key, connect to the headset, and start using it as if it were a legitimate user. In this case, they can activate the microphone and eavesdrop on conversations.
The BlueSpy script
BlueSpy is a Python script developed as a proof-of-concept exploit for this vulnerability. It only needs native Bluetooth tools available on Linux operating systems.
An Arch Linux distribution has been used with a working installation of BlueZ, the Linux Bluetooth stack, and PipeWire as an audio server to record and playback the captured audio.
The BlueSpy tool, with code and documentation, is published in Tarlogic Security’s GitHub repository.
To execute the attack against a device, you need to know its Bluetooth MAC address, which can be obtained with any Bluetooth scanning tool, in our case using bluetoothctl:
Once the MAC address of the device has been obtained, you can run BlueSpy, which performs the following steps to execute the attack:
- Initial configuration
- Pairing (generation of shared key)
- Connection
- Audio recording
- Audio playback
During the configuration stage, the script ensures that the local computer will allow pairing and key sharing with remote devices, which can be done without security. In other words, it ensures that “JustWorks” can be used to prevent the user from being notified or having to interact.
Once configured, the pairing is performed, and the generated key is stored in the BlueZ device database, which is usually located in the “/var/lib/bluetooth” directory.
With the generated and stored key, a connection to the device can be initiated using bluetoothctl. The PipeWire sound server automatically enables a new audio source to be added to the system (audio source).
BlueSpy uses this new audio source to record and store it in a file (“recording.wav” by default). This recording can then be played back with “paplay” or any other audio playback tool.
Mitigation
The fundamental reason BlueSpy works is that the headset doesn’t require secure pairing. The most straightforward mitigation requires the user to allow pairing explicitly using a physical button or by playing an audio notification when a new pairing attempt is received.
Another possible mitigation is using a physical button or control to turn on or off the device’s discoverability and pairing state so that the user can control it when it is in each mode of operation.
The device manufacturer must implement all of these mitigations, but users can also protect themselves by incorporating safe practices into their everyday use of Bluetooth technology.
There are headsets that are not discoverable, pairable, or connectable when locked in their charging station or when already connected to some other device. One way to avoid these attacks is to keep them locked in their case whenever they are not going to be used.
These recommendations, however, may need to be revised for other devices with similar problems, as Bluetooth devices can behave in very different ways. Therefore, it is imperative that Bluetooth devices are audited from a security point of view using, e.g., the BSAM methodology to determine their specific performance.
In conclusion
Bluetooth technology offers a simple form of communication for low-power devices, but many manufacturers have prioritized ease and convenience of use by users/customers over security.
Within companies, to maintain a complete and beneficial security policy, risk calculation must take into account all devices and systems connected to the infrastructure. Until now, risk calculation has focused mainly on devices connected by cable or WiFi, but research and tools such as BlueSpy show that it is essential to consider technologies such as Bluetooth as well. Failure to do so means unwittingly exposing oneself to security vulnerabilities such as the one shown in this article.
The BSAM methodology is a tool that simplifies and standardizes the security assessment of Bluetooth devices and allows them to be integrated into the organization’s risk calculation and security policy.