The number of people who are using Bluetooth headsets have gone up recently. Thanks to the new generation bluetooth devices that offer reliable communication link between the headset and the device. Even I prefer them whenever I’m listening to music; but never when I am making a call! The simple reason is that you can easily intercept all the messages. Yes, I’m referring to eavesdropping…..
This article elucidates how this happens.
How the paring works?
You may notice that in most cases you don’t have to configure your headsets to work with your mobile phone. This is because of the fact it does only two simple checks:
- Checks whether the PIN is correct. By default, the pin is 0000 and most of the users will not change this PIN (even if they change this, it is not very hard to crack this)
- Checks if the connection is from a phone or any other device, by looking at the serial number. All these devices (headsets) will accept connections only from a mobile phone.
Note: You have to be in the GNU/Linux platform for testing this
The vulnerability lies in the actual pairing mechanism mentioned before. In order to exploit this, one needs to configure bluetooth stack and assign a PIN (if the default one is rejected, one can even use aÂ force brute access method).
You can issue the following command for checking the same:
The value we are expecting is 0000 (headsets).
We need a good Bluetooth DongleÂ to locate the nearby bluetooth devices (headsets). I recommend BlueWalker Bluetooth USB Dongle which you canÂ buy from Amazon. This will give a range up to 100 meters. Now we need a good software for doing all the processing.
I tried a couple of ones and IÂ found the ‘carwhisperer’ tool fromÂ TrifiniteÂ to be very effective and easy to use(you can download this from theÂ official site). Unzip (untar) this and see the contents.
You can easily install this piece of software by changing your directory to this one (unzipped one) and issuing the ‘make’ command.
We will now use the ‘hciconfig’ tool for configuring the interface. If you have not used this before, please have a glace at this picture:
And the interface is likely to be hci0, and you may issue the following command to crosscheck this:
And you will see an output similar to the one shown below:
Now we can check the ‘class’ of our device (Bluetooth Dongle) by issuing:
hciconfig hci0 class
As you can see, the device is categorized as a ‘computer’. We need to change this to a ‘phone’.
If you look at the hcid.conf , you can see an entry like the one shown below:
This means that ‘0×50204’ corresponds to a phone. Now issue:
hciconfig hci0 class 0×50204
And check the class again.
Now the device is classified as a phone.
How people may exploit?
One can exploit this vulnerability by using these tools and may intercept the conversations. Say, for example I can easily find the bluetooth devices (headsets) by using a simple scanning and this will give me the addresses of the devices.
Now one can issue:
./carwhisperer hci0Â file_in.raw out_put.rawÂ device_address
where, file_in.raw is your audio file that you wan to send to the headset and out_put.raw is the recording of the conversation. You also need to change the variable ‘device_address’ by the actual address of the device (which you obtained during scanning).
This will send the file to the handset and you can see the output in your screen.
Well, people may become suspicious if one uses his laptop for doing all these. You can avoid this by configuring a smart phone to remotely access the laptop (which may be kept inside a handbag) and pipe the output file to the smart phone (so that you can listen to the conversations)
How to secure yourself?
- Change the PIN of your headset (But, this is hard when it comes to some proprietary headset manufactures). This will make the process harder.
- Never use the headset while communicating any sensitive information
- If you wish to try an open source device, then use key based authentication for connecting (during the ‘hand-shake’ stage)
- Track back — Techblog