RISKS Forum mailing list archives

Serious flaws in bluetooth security lead to disclosure of personal data


From: Adam Laurie <adam () algroup co uk>
Date: Tue, 11 Nov 2003 22:53:53 +0000

folks,

please find attached a disclosure paper on bluetooth.

cheers,
Adam
--
Adam Laurie                   Tel: +44 (20) 8742 0755
A.L. Digital Ltd.             Fax: +44 (20) 8742 5995
The Stores                    http://www.thebunker.net
2 Bath Road                   http://www.aldigital.co.uk
London W4 1LT                 mailto:adam () algroup co uk
UNITED KINGDOM                PGP key on keyservers
Summary
-------

There are serious flaws in the authentication and/or data transfer mechanisms on some bluetooth enabled devices. 
Specifically, two vulnerabilities have been found:

Firstly, confidential data can be obtained, anonymously, and without the owner's knowledge or consent, from some 
bluetooth enabled mobile phones. This data includes, at least, the entire phonebook and calendar.

Secondly, it has been found that the complete memory contents of some mobile phones can be accessed by a previously 
trusted ("paired") device that has since been removed from the trusted list. This data includes not only the phonebook 
and calendar, but media files such as pictures and text messages. In essence, the entire device can be "backed up" to 
an attacker's own system.

Finally, the current trend for "Bluejacking" is promoting an environment which puts consumer devices at greater risk 
from the above attacks.

Vulnerabilities
---------------

The SNARF attack:

It is possible, on some makes of device, to connect to the device  without alerting the owner of the target device of 
the request, and gain access to restricted portions of the stored data therein, including the entire phonebook (and any 
images or other data associated with the entries), calendar, realtime clock, business card, properties, change log etc. 
This is normally only possible if the device is in "discoverable" or "visible" mode, but there are tools available on 
the Internet that allow even this safety net to be bypassed[4]. Further details will not be released at this time (see 
below for more on this), but the attack can and will be demonstrated to manufacturers and press if required.

The BACKDOOR attack:

The backdoor attack involves establishing a trust relationship through the "pairing" mechanism,  but ensuring that it 
no longer appears in the target's register of paired devices. In this way, unless the owner is actually observing their 
device at the precise moment a connection is established, they are unlikely to notice anything untoward, and the 
attacker may be free to continue to use any resource that a trusted relationship with that device grants access to (but 
note that so far we have  only tested file transfers). This means that not only can data be retrieved from the phone, 
but other services, such as modems or Internet, WAP and GPRS gateways may be accessed without the owner's knowledge or 
consent. Indications are that once the backdoor is installed, the above SNARF attack will function on devices that 
previously denied access, and without the restrictions of a plain SNARF attack, so we strongly suspect that the other 
services will prove to be available also.

Bluejacking:

Although known to the technical community and early adopters for some time, the process now known as "Bluejacking"[1] 
has recently come to the fore in the consumer arena, and is becoming a popular mechanism for exchanging anonymous 
messages in public places. The technique involves abusing the bluetooth "pairing"[2] protocol, the system by which 
bluetooth devices authenticate each other, to pass a message during the initial "handshake" phase. This is possible 
because the "name" of the initiating bluetooth device is displayed on the target device as part of the handshake 
exchange, and, as the protocal allows a large user defined name field - up to 248 characters - the field itself can be 
used to pass the message. This is all well and good, and, on the face of it, fairly harmless, but, unfortunately, there 
is a down side. There is a potential security problem with this, and the more the practice grows and is accepted by the 
user community, and leveraged as a marketing tool by the vendors, the worse it will get.  The problem lies in the fact 
that the protocol being abused is designed for information exchange. The ability to interface with other devices and 
exchange, update and synchronise data, is the raison d'e^tre of bluetooth. The bluejacking technique is using the first 
part of a process that allows that exchange to take place, and is therefore open to further abuse if the handshake 
completes and the "bluejacker" successfully pairs with the target device. If such an event occurs, then all data on the 
target device bacomes available to the initiator, including such things as phone books, calendars, pictures and text 
messages. As the current wave of PDA and telephony integration progresses, the volume and quality of such data will 
increase with the devices' capabilities, leading to far more serious potential compromise. Given the furore that 
errupted when a second-hand Blackberry PDA was sold without the previous owner's data having been wiped[3], it is 
alarming to think of the consequences of a single bluejacker gathering an entire corporate staff's contact details by 
simply attending a conference or camping outside their building or in their foyer with a bluetooth capable device and 
evil intent. Of course, corporates are not the only potential targets - a bluejacking expedition to, say, The House of 
Commons, or The US Senate, could provide some interesting, valuable and, who's to say, potentially damaging or 
compromising data.

The above may sound alarmist and far fetched, and the general reaction would probably be that most users would not be 
duped into allowing the connection to complete, so the risk is small. However, in today's society of instant messaging, 
the average consumer is under a constant barrage of unsolicted messages in one form or another, whether it be by SPAM 
email, or "You have won!" style SMS text messages, and do not tend to treat them with much suspicion (although they may 
well be sceptical about the veracity of the offers). Another message popping up on their 'phone saying something along 
the lines of "You have won 10,000 pounds! Enter this 4 digit PIN number and then dial 0900-SUCKER to collect your 
prize!" is unlikely to cause much alarm, and is more than likely to succeed in many cases.

Workarounds and fixes
---------------------

We are not aware of any fixes for the SNARF attack at this time other than to switch off bluetooth.

To permanently remove a pairing, and protect against future BACKDOOR attacks, it seems you must perform a factory 
reset, but this will, of course, erase all your personal data.

To avoid Bluejacking, "just say no". :)

The above methods work to the best of our knowledge, but, as the devices affected are running closed-source proprietory 
software, it not possible to verify that without the collaboration of the manufacturers. We therefore make no claims as 
to the level of protection they provide, and you must continue to use bluetooth at your own risk.

Who's Vulnerable
----------------

To date the quantity of devices tested is not great. However, due to the fact that they are amongst the most popular 
brands, we still consider the affected group to be large. It is also assumed that there are shared implementations of 
the bluetooth stack, so what affects one model is likely to affect others. 

The devices known to be vulnerable at this time are:

SNARF attack:

  Ericsson: T68, T68i, T610
  Nokia: 6310i, 7650

BACKDOOR attack:

  Nokia: 6310i, 7650

  * It is not known at this time if Ericsson's are also vulnerable to the BACKDOOR attack.

Disclosure
----------

What is the Philosophy of Full Disclosure, and why are we providing the tools and detailing the methods that allow this 
to be done?  The reasoning is simple - by exposing the problem we are achieving two goals: firstly, to alert users that 
the dangers exist, in order that they can take their own precautions against compromise, and secondly, to put pressure 
on manufacturers to rectify the situation. Consumers have a right to expect that their confidential data is treated as 
such, and is not subject to simple compromise by poorly implemented protocols on consumer devices. Manufacturers have a 
duty of care to ensure that such protection is provided, but, in practice, commercial considerations will often take 
precedence, and, given the choice, they may choose to simply supress or hide the problem, or, even worse, push for laws 
that prevent the discovery and/or disclosure of such flaws[5]. In our humble opinion, laws provide scant consumer 
protection against the lawless.

However, having said that, in this particular case, we do not feel it is appropriate to follow the normal procedure of 
liaising with manufacturers and giving them an opportunity to rectify the problem before disclosing to the general 
public (this is not to say we haven't contacted them - we have), as there are simply too many of them, and the problem 
is too widespread to realistically believe that they could either adhere to the strict levels of confidentiality 
required until the  problem has been rectified, or that there is even the possibilty that the problem can be rectified 
in a reasonable timescale. Also, the volume of data currently at risk is too great to allow the situation to continue 
unchecked.

Instead, we feel it is more important to achieve our primary goal, and alert the general public to the fact that the 
problem exists, and to give them the information required to adequetely defend themselves.  Fortunately, the defence is 
relatively simple, and is detailed above. To date we do not have a large selection of phones or other devices to test, 
so the advice is somewhat generic, but we will publish more detailed information as and when it becomes available.

Tools
-----

Proof of concept utilities have been developed, but are not yet available in the wild. They are:

        bluestumbler - Monitor and log all visible bluetooth devices (name, MAC, signal strength, capabilities), and 
identify manufacturer from MAC address lookup.

        bluebrowse -   Display available services on a selected device (FAX, Voice, OBEX etc).

        bluejack -     Send anoymous message to a target device (and optionally broadcast to all visible devices).

        bluesnarf -    Copy data from target device (everything if pairing succeeds, or a subset in other cases, 
including phonebook and calendar. In the latter case, user will not be alerted by any bluejack message).

Tools will not be released at this time, so please do not ask. However, if you are a bona-fide manufacturer of 
bluetooth devices that we have been otherwise unable to contact, please feel free to get in touch for more details on 
how you can identify your device status.

Credits
-------

The above vulnerabilities were discovered by Adam Laurie, during the course of his work with A.L. Digital, in November 
2003, and this announcement was prepared thereafter by Adam and Ben Laurie for immediate release.

Adam Laurie is Managing Director and Chief Security Officer of A.L.  Digital Ltd.

Ben Laurie is Technical Director of A.L. Digital, and author of Apache-SSL and contributor to many other open source 
projects, too numerous to expand on here.

A.L. Digital Ltd. are the owner operators of The Bunker, the world's most secure data centre(s).

e: adam () algroup co uk
w: http://www.aldigital.co.uk
w: http://www.thebunker.net

e: ben () algroup co uk
w: http://www.apache-ssl.org/ben.html

Further information relating to this disclosure will be updated at
http://www.bluestumbler.org

References:

[1] - http://www.bluejackq.com/
      http://www.theregister.co.uk/content/6/33781.html
      http://news.bbc.co.uk/1/hi/technology/3237755.stm

[2] - http://www.palowireless.com/infotooth/tutorial/lmp.asp

[3] - http://www.out-law.com/php/page.php?page_id=blackberryforsale1061969777

[4] - http://bluesniff.shmoo.com/

[5] - http://www.eff.org/

Copyright (c) 2003, Adam Laurie, Ben Laurie, A.L. Digital Ltd., all rights reserved.

Current thread: