Bluetooth allows short-range wireless connections between a whole range of systems - including mobile phones.

But, Adam Laurie, technical director and co-founder A.L. Digital, says, some bluetooth-enabled devices have serious flaws through which the entire device can be ‘backed up’ to an attacker’s system.

On the other hand, Nick Hunn, a long-standing Bluetooth proponent, says A.L. Digital’s research gives little cause for concern.

We’ve included Laurie’s breakdown and Hunn’s reubuttal here, one under the other

Now read on >>>>>>>>>>>>>>>>

Bluesnarfing
By Adam Laurie - Bluestumbler

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, and the phone’s IMEI.

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, IMEI (International Mobile Equipment Identity [6], which uniquely identifies the phone to the mobile network, and is used in illegal phone ‘cloning’). 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’ê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:

Vulnerability Matrix
Make	Model	BACKDOOR	SNARF when Visible	SNARF when NOT Visible
Ericsson	T68	?	Yes	No
Sony Ericsson	R520m	?	Yes	No
Sony Ericsson	T68i	?	Yes	?
Sony Ericsson	T610	?	Yes	No
Sony Ericsson	Z1010	?	Yes	?
Sony Ericsson	Z600	?	Yes	?
Nokia	6310	?	Yes	Yes
Nokia	6310i	Yes	Yes	Yes
Nokia	7650	Yes	Yes	?
Nokia	8910	?	Yes	Yes
Nokia	8910i	?	Yes	Yes

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.

---

Bluejacking ain’t hijacking
Nick Hunn. managing director, TDK Systems Europe Ltd - (John Leyton, The Register)

Having just read the article on The Reg, I’d like to explain a bit more about the issues raised. The Laurie pere et fils article jumps between some observations about technology and scare mongering without paying too much attention to actual implementation and user models.

The recent Bluejacking stories describe a way that Bluetooth users can push messages onto other users’ handsets. This uses the same basic OBEX (Object Exchange) stack that was developed for Infrared and used to acclaim in the Palm for “beaming” business cards and applications. When used on Bluetooth phones it behaves in the same way - a user is alerted to a message which they can then read.

Bluejacking isn’t hijacking
Despite the name it doesn’t hijack the phone or suck off the information - it simply presents a message. The recipient can ignore it, read it, respond or delete it. After beaming became such a success on the Palm it seems a little unfair to castigate it on mobile phones just because it is becoming a youth culture rather than an implied serious business use.

Snarfing is more interesting. If it were possible it would be damaging, but we’ve yet to find out how to do it. We’ve been playing with Bluetooth devices at all levels of the protocol stack for six years and have yet to find a commercial device we can hack into.

That’s not for want of trying.

Pairing up
To get access you need to pair with a device. Whenever another device requests a pairing, the user of the targeted handset is presented with a message along the lines of “Device xyz is attempting to pair. Enter your password.” The password must be the same as the one on the device attempting to pair - in other words you don’t know it unless the person trying to hack into your phone comes over and tells you. If they’re going to do that it’s probably much easier for them to grab your phone and leg it.

A.L. Digital talk about the risk of removing a pairing from a previously paired device. They don’t mention how that device was paired in the first place, but imply this is a major threat. Given that you have to know and have made a conscious effort to pair in the first place I don’t see how it is. It is like giving somebody you meet in the street your house key, not changing the locks and then being surprised when the family silver goes missing.

Show us the vulnerabilities
It’s possible to think up all sorts of scenarios of how it could go wrong, but the industry’s been pretty busy doing that itself and ensuring that these access methods are blocked and the user alerted. One of the complaints levelled at Bluetooth is that it should be easier to use. The reason there are restrictions is because of the security and warnings that have been built into real devices.

Looking specifically at the tools, there is little new:
bluestumbler - Monitor and log all visible bluetooth devices (name, MAC, signal strength, capabilities), and identify manufacturer from MAC address lookup. This is nothing new - we’ve had a freeware utility called Blue Alert availed for around 24 months that does exactly that. You can do the same with Mobile phone IMEIs, Ethernet cards, Wi-Fi access points, Web IP addresses - essentially anything that has an IP or Ethernet type address. Knowing the name doesn’t give you any deeper access.

bluebrowse - Display available services on a selected device (FAX, Voice, OBEX etc). This is part of Bluetooth. If a device is discoverable you can ask it what it does. If you couldn’t do that it all gets a bit pointless, as you’d have no idea of whether you were trying to print to a headset or a printer. Not a lot of use, Mr Bond.

bluejack - Send anonymous message to a target device (and optionally broadcast to all visible devices). It’s a posh name for Object Push, as described above and comes built into almost every Bluetooth device you buy. It just sounds sexier to give it a name with undertones of hacking. So the major theft is from any user who pays a shareware fee for duplicating what came free with their Bluetooth device. Once again, not world shattering.

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. This is the most interesting claim, but in my experience it remains unsubstantiated. We have failed at all attempts to get data off an unpaired device. If the device is paired then yes, you can do it, but to say it’s a security flaw to give away data to someone who comes up to you and asks “Can I steal your data”, to which you reply “Yes - help yourself” is not a great claim.

As a Bluetooth manufacturer we’ve not been approached by A.L. Digital. I’ve asked them for details of this and look forward to receiving them and putting them to the test. If there is an issue then the Bluetooth industry needs to address it. The people I talk to in the SIG understand the need to get security right and be honest about it - they all saw what the consequence is if you don’t - look at the IEEE and 802.11. I suspect that what A.L. Digital have seen is a facet of having previously paired devices and then correlating the subsequent behaviour to that of a pristine, unpaired device. It would not be the first time that mistake has been made.

At the end of the day all security has to come down to the question of what is adequate for the application. In the case of Bluetooth on a mobile phone my interpretation is that the easiest way to get data off the phone is still to nick it. You can’t blame Bluetooth for that.

This entry was posted on Tuesday, February 17th, 2004 at 7:00 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

HOME

Viewed 3489 times