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/