<<< Date Index >>>     <<< Thread Index >>>

DMA[2005-1214a] - 'Widcomm BTW - Bluetooth for Windows Remote Audio Eavesdropping'




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/