Bluetooth: The Spy In The Meeting Room

Bluetooth technology permeates the modern world. From smart phones to wireless speakers, fitness trackers to WiFi mesh hardware, Bluetooth has become the de facto standard for short-range wireless communications. The chances are that you have Bluetooth enabled devices near you as you read this, and, if you're regularly involved in conference calls, you've probably often used a Bluetooth enabled speaker or VoIP phone.

Adding technology to devices only increases the attack surface and, here at Cyberis, we decided to look at how Bluetooth might change the attack surface of VoIP devices. Specifically, we wanted to see if it would be possible to intercept communications through insecure Bluetooth configurations.

We took some time to look at three available solutions. Of the three we tested, the only vulnerable system was the Polycom Trio 8500.

All three devices allowed you to connect a mobile phone via Bluetooth and all allowed you to dial from the conference phone using the mobile to make the call.

Introduction To Bluetooth

When Bluetooth is mentioned, most people think of it as a single technology for connecting devices together. In reality, Bluetooth is a range of technologies, protocols and standards that, when combined, create a means of sharing data between devices wirelessly over a short distance.

The concept of "Bluetooth" as a whole can be compared to that of "the internet". Bluetooth is an umbrella term for a range of standards and can be compared with the OSI model for conventional networking.

Bluetooth devices have unique addresses, similar to the MAC address of a network adaptor. These are assigned when manufactured and are used by Bluetooth protocols to determine which device is being interacted with. This is represented by a 48-bit number, usually presented as 6 hexadecimal numbers separated by colons (for example 11:22:33:44:55:FF).

Most people are familiar with pairing of Bluetooth devices. The process of pairing creates a trust relationship between the devices, however, this is not completely necessary for Bluetooth to work. The requirement for pairing is set at the application level and can be used to prevent an unknown user from controlling Bluetooth applications on a device without authorization.

Pairing of devices can be done in a number of ways. Legacy pairing allows devices to connect to each other using a shared PIN. There are known weaknesses in the legacy pairing protocols and legacy pairing also makes it difficult to pair devices that don't have a user interface (such as headphones). This has been replaced by the Secure Simple Pairing protocol (SSP) which provides three methods of Bluetooth pairing:

• Just Works. The "Just Works" method does exactly what it says on the tin: one device requests a pairing and the devices are paired. This is the simplest method and is used largely by devices lacking a UI.
• Numeric Comparison. Numeric Comparison is the most similar to legacy pairing. Once pairing is requested a PIN is shared between the devices. If the PINs match on both devices, the user must then accept the connection for the devices to be paired. This adds a degree of validation to the "Just Works" pairing.
• Passkey Entry. Passkey Entry should be familiar to most computer users. This requires that the passkey (or password) be set by the user initiating the pairing. This passkey them must be entered on the second device to authenticate the connection.
• Out of Band. Out of Band pairing requires a non-Bluetooth technology to pair the devices. The most common out of band pairing media is NFC.

Bluetooth Protocols.

There are a wide range of communications protocols which operate over Bluetooth. At the lowest level is the Host Controller Interface (HCI) which manages the Bluetooth interface on the device. Above this are the Logical link control and adaptation protocol (L2CAP) and Radio frequency communication (RFCOMM). RFCOMM is built upon L2CAP and they can be seen as Bluetooth equivalents to TCP and IP in the OSI model proxy.

On top of these protocols are implemented a number of Bluetooth "profiles" comparable to OSI application layer protocols (such as HTTP or FTP). Again, there are a large number of these but the ones we are most interested in here are Advanced Audio Distribution Profile (A2DP) which is used to handle a wide range of audio functionality; and Hands-Free Profile (HFP) and Headset Profile (HSP) which are two closely related profiles which (as the names suggest) manage headsets and handsfree devices.

Blueberry Pi

There are several possible devices we could use to attempt to connect to the VoIP devices. We chose to use the Raspberry Pi 3 as it has built-in Bluetooth and, with a Linux operating system, it is highly configurable and allows a low level of control over the device.

Linux has a Bluetooth library, Bluez, which provide control over the Bluetooth controller. With it we were able to establish connections to the devices we were testing. Once the connection was established, we needed a means to record audio. Linux provides ALSA (Advanced Linux Sound Architecture) which, amongst other things, has an audio recorder and audio player. In order to combine the Bluetooth drivers with ALSA we needed to use something that exposed the Bluetooth audio devices to ALSA. This was achieved with bluez-alsa.

So, now we knew what tools we would be using, we need to look at how they work.

Bluez

Bluez is the official Bluetooth stack for Linux. It provides everything required to connect and communicate over Bluetooth. Once installed, the bluetoothctl tool can be used to interact with Bluetooth devices.

The first step is to enable the Bluetooth interface:

[bluetooth]# power on

Then you can begin scanning for devices:

[bluetooth]# scan on

This will begin scanning for discoverable devices in the vicinity and will continue to do so until it's turned off.

Once we've found the device we are looking for, we can pair with it:

[bluetooth]# pair 00:00:00:00:00:00

This creates a pairing between our Raspberry Pi and the phone.

In the case of the majority of the devices we tested, a message was displayed on the screen that a pair device was connected. For the Polycom Trio, the only noticeable change was that the Bluetooth icon in the top right corner changed from white to blue, the device was using the "Just Works" form of pairing. This looked promising as a means to surreptitiously connect to the Polycom Trio.

Bluez-Alsa

Now that we have a pairing and have established a connection, we need to see if it is possible to remotely record from the conference phones' microphones. With bluez-alsa installed, the system should provide a service called bluealsa. This will be executed as root on startup and will provide ALSA with access to the Bluetooth audio device.

To this, we used ALSA to play a wav file on the conference phones:

aplay -D bluealsa:HCI=hci0,DEV=XX:XX:XX:XX:XX:XX,PROFILE=a2dp sound.wav

When the audio was played Polycom's display didn't change. The next step now was to see if we could record audio from the phones audio input.

ALSA provides a means to record audio as well and again can be used with the bluetooth device:

arecord -D bluealsa:HCI=hci0,DEV=XX:XX:XX:XX:XX:XX,PROFILE=sco output.wav

You'll notice in this case that we used the SCO profile in order to access the device microphone. Playing back the output file (through the conference phone's speaker) showed that we had successfully recorded from the microphone.

This Call May Be Monitored

So far so good. We can connect to the device and record audio, all without alerting users. Even without the final step of recording a phone call, this give us the opportunity to use the Polycom as a covert listening device in any meeting room. This alone is a compromise of confidentiality.

The last step we are going to take is to create a call between two devices, then attempt to record both sides of the conversation through the Raspberry Pi.

We initiate the recording and dial out to the other phone. Once the call in finished, we play back the audio file through the conference call. Again, there was no notification on the Polycom's display that suggests that anything is being recorded.

When we played the audio back, it was possible to record the audio input from the call, however, the audio output was not recorded. This is likely due to the use of active noise cancellation (https://en.wikipedia.org/wiki/Active_noise_control) which is used in a lot of modern phones. This is a process in which two identical sound waves are added together out of phase. This results in cancellation of the sound wave. As a result of this (and by virtue of the fact that we cannot record from the speaker) we are only able to capture one side of the conversation.

However, this is still a significant breach of privacy and is not likely to be something that many users would even consider. It would also be possible to record conversations taking place solely within the conference room in which the phone was located.

Disclosure

• Following the discovery, Polycom were notified of the vulnerability on the 20th of July 2018 via a support ticket.
• Polycom responded to the notification of the 27th of July 2018 and escalated the support ticket to the engineering team.
• On the 2nd of August 2018 Cyberis were contacted by a member of Polycom's security team acknowledging the vulnerability and stating that remediation was underway.
• On the 6th of August 2018 CVE-2018-14934 was reserved by Cyberis.
• Between the 13th of August 2018 and 15th of October, no communication was received from Polycom despite several attempts by Cyberis to make contact.
• On the 15th of October 2018, Polycom informed Cyberis that the point of contact was no longer there and that the case had been moved to another handler.
• On the 2nd of November 2018, Polycom released to Cyberis a draft security bulletin outlining the details of the vulnerability and the patch to be applied.
• On the 5th of November 2018, Polycom released the final version of the security bulletin (https://support.polycom.com/content/dam/polycom-support/global/documentation/bluetooth-authentication-weakness-trio.pdf and firmware version 5.7.2 addressing the vulnerability.

Experimenting With Android And Ideas For Further Research

We also considered using Android as a means of intercepting calls, however, given timing constraints to our research window this was not covered in much depth. Several of the devices allowed calls to be made through a Bluetooth connected phone dialling from the VoIP phone but establishing the call through SIM of the connected mobile. The following considerations could make Android a suitable platform from which attacks could be made:

• Android can allow the user to set the application they use to make phonecalls.
• Android applications can be developed to listen for outgoing calls and potentially record the call content.
• Recording from a audio source (i.e. the speaker) is only possible in very low quality in stock Android.
• Modified Android kernels could be developed without this security feature