View Single Post
qwerty12's Avatar
Posts: 4,274 | Thanked: 5,358 times | Joined on Sep 2007 @ Looking at y'all and sighing
#1
http://trifinite.org/trifinite_stuff_carwhisperer.html


The carwhisperer project intends to sensibilise manufacturers of carkits and other Bluetooth appliances without display and keyboard for the possible security threat evolving from the use of standard passkeys.

A Bluetooth passkey is used within the pairing process that takes place, when two Bluetooth enabled devices connect for the first time. Besides other public data, the passkey is a secret parameter used in the process that generates and exchanges the so-called link key. In Bluetooth communication scenarios the link key is used for authentication and encryption of the information that is exchanged between the counterparts of the communication.

The cw_scanner script is repeatedly performing a device inquiry for visible Bluetooth devices of which the class matches the one of Bluetooth Headsets and Hands-Free Units. Once a visible Bluetooth device with the appropriate
device class is found, the cw_scanner script executes the carwhisperer binary that connects to the found device (on RFCOMM channel 1) and opens a control connection and connects the SCO links.

The carwhiperer binary connects to the device found by the cw_scanner. The passkey that is required for the initial connection to the device is provided by the cw_pin.pl script that replaces the official Bluez PIN helper (graphical application that usually prompts for the passkey). The cw_pin.pl script provides the passkey depending on the Bluetooth address that requests it. Depending on the first three bytes of the address, which references the manufacturer, different passkeys are returned by the cw_pin.sh script. In quite a few cases the preset standard passkey on headsets and handsfree units is '0000' or '1234'.

Once the connection has been successfully established, the carwhisperer binary starts sending audio to, and recording audio from the headset. This allows attackers to inject audio data into the car. This could be fake
traffic announcements or nice words. Attackers are also able to eavesdrop conversations among people sitting in the car.

Ideally, the carwhisperer is used with a toooned dongle and a directional antenna that enhances the range of a Bluetooth radio quite a bit. (see Long-Distance-Snarf experiment)
Basically it works on the principle of standard passkeys to eavesdrop on a bluetooth headset and to send your own message to it.

Some things:
  • I've made some modifications to support some more classes of headsets and to fix up the scripts a little, paths were dodgy.
  • I was unable to test with my headset, it seems to switch off. let me know if this works for you.
  • This makes a lot of changes to the hcid.conf. Uninstall when you are done with this.
  • SoX needs to be compiled for best use out of this. I will compile later.
  • Nokia thought it would be a brilliant decision to modify the Bluez and their version of hcid refuses to acknowlege the pin_helper argument and still brings up the standard pair device dialog. Look in /usr/bin/cw_pin.pl for the list of pins. Thank Nokia for this annoyance, not me.
  • Thanks to KotCzarny for the grep help and Johnx for his scripts to "divert" things a little.

I lied, i didn't fix. reattaching and trying to fix tommorow. bluez-utils-test is needed too. memorise and guess the default passcodes. uninstall when you are done. make a better port of sox than my one.
Attached Files
File Type: deb carwhisperer_0.2-1_armel.deb (12.7 KB, 824 views)

Last edited by qwerty12; 2008-06-08 at 05:44.
 

The Following 3 Users Say Thank You to qwerty12 For This Useful Post: