Docstoc
EXCLUSIVE OFFER FOR DOCSTOC USERS
Try the all-new QuickBooks Online for FREE.  No credit card required.

txt - Download Now DOC

Document Sample
txt - Download Now DOC Powered By Docstoc
					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 Gateway and Headset profile free kits use channel 1 and a and a device class os my previous attempts at exploiting the Widcomm Audio failed was more apparant now. While traditional hands specific device class, the Widcomm drivers use channel 7 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\ HKLM\SOFTWARE\Widcomm\BTConfig\Services\009\ (HeadSet) (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

a PIN

Select "Advanced Configuration" Click "Local Services" Highlight the Headset profile and click properties Enable the the check box next to Secure Connection to require 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] [2] [3] [4] Car Whisperer, http://trifinite.org/trifinite_stuff_carwhisperer.html SkypeHeadset, http://www.skypeheadset.co.uk/ BlueZ, http://www.bluez.org/ The original Widcomm Pimps, http://www.pentest.co.uk/


				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:21
posted:1/2/2010
language:English
pages:4