RE: Bluejacking ain't hijacking

[InfoSec News <isn () c4i org>]

Forwarded from: Adam Laurie <adam () algroup co uk>

> http://www.theregister.co.uk/content/69/34139.html
>
> By John Leyden
> Posted: 21/11/2003
>
> Letter - Last week we reported on preliminary research from security
> firm A.L. Digital which suggested a number of security problems with
> Bluetooth-enabled mobile phones from Nokia and Ericsson. The paper
> argued that digital pickpockets could swipe address books and data
> from mobile phones because of security shortcomings in the
> implementation of Bluetooth by the manufacturers.
>
> Not so, says Nick Hunn, who in addition to his day job at TDK
> Systems is a long-standing proponent of and expert on Bluetooth.
> Nick reckons A.L. Digital's research gives little cause for concern.
> The easiest way to get data off a mobile phone is to steal it,
> according to Nick:
>
> -=-
>
> 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.

that is simply not the case. we give specific examples on the website
of devices we have found to be vulnerable (and are about to test a
whole bunch more, so that list will be updated). oh, and Ben isn't my
father... he's my brother.
 
> 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.

the problem with bluejacking, as explained in the original post, is
the ability to trick users into responding in a way which leads to
further compromise. this isn't criticising bluetooth per se, it's just
pointing out a simple fact of life that new abilities come with new
risks. the risk may be small or large, but it is a risk nevertheless.
 
> 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.

the fact that TDK have been unable to crack it in six years doesn't
mean that it can't be done. we have demonstrated this problem to
several external research groups, including some other manufacturers,
who have all confirmed that the attack is real and have managed to
reproduce it in their own labs.

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

how the pairing got there in the first place isn't particularly
relevant. we are simply pointing out that it is a flaw if removing a
pairing does not remove access rights. having said that, I can think
of several situations in which I might grant temporary access to my
phone (to pass a photo to a friend, for example), and then remove
access immediately thereafter. having done so, I would normally expect
to have secured my device from further (unsupervised) access by that
individual or workstation.

to put it in the context of locks and family silver, the situation
we've found is that everybody who's ever been invited into the house
for any reason whatsoever, be it the plumber, the postman or the
dinner guest, now has a full set of keys and can enter the house
whenever they are passing, and help themselves to the family silver if
they so desire.

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

unfortunately, as we've shown, these security precautions do not work
as expected.

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

actually, in some cases, it does. we have found that some devices are
vulnerable to the snarf attack even when not in discoverable mode if
the address is known. it is also neccessary to tune the attack
pramaters according to manufacturer, so the ability to determine
manufacturer before making a connection is crucial.

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

shareware fee???

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

I agree that most of this is not new. however, it is all useful for
the task in hand - to quietly steal someone else's data - and so it
makes sense to package it all together. the only really new bit is the
the snarf tool, and, as stated in the original post, and on the
bluestumbler site, it specifically does not require the target's
permission to acquire their data.
 
> 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.

actually, as a bluetooth manufacturer, TDK have, like all others, been
alerted to the issue and given an open invitation to contact us for
more information. this was done through what I consider to be the
proper channel - the aforementioned bluetooth SIG
(http://www.bluetooth.org), who are the owners of the bluetooth
trademark, and run a public access site which contains, amongst other
things, a message board for the industry "Security Expert Group".
unfortunately, the SIG do not seem to take their security obligations
very seriously, and, indeed, no messages on the security forum have
been responded to in the last 7 months. this is also refelected in
their annual conference, where security is not even on the agenda
(http://www.ibctelecoms.com/bluetoothamericas/default.asp?url=agenda).

since my original posting, I have been contacted both by Nick Hunn
(who did not ask me for any further details of the attacks... on the
contrary, he promised to send me some bluetooth devices so i could
test them and report back, but to date these have not been
forthcoming).

I have also been contacted by Anders Edlund of bluetooth.org, who
indicated that he would be raising the profile of the problem to the
relevant people in the security departments of various manufacturers,
but, again, I have heard nothing further through that channel.

also, the assumption that we are misinterpeting the results is not 
correct. I have successfully snarfed 100% of all bluetooth enabled 
phones in my office, and, since the laptop in use had a bluetooth stack 
installed specifically for this purpose and had never been paired with 
anything, I can confidently say that pairing is not a requirement for 
the attack to succeed.
 
> 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 is a classic and somewhat predictable manufacturer's knee-jerk
"shoot the messsenger, bury your head in the sand, and hope the
problem goes away" reaction, and, frankly, the idea that it's easier
to steal phones than to stand within 10 meters of multiple targets and
walk away with all their data, leaving them none the wiser, is nothing
short of laughable. fortunately, all the other manufacturers we've
spoken to are taking the problem more seriously.

once again, I would like to state that my offer remains open to those 
manufacturers who have yet to be convinced, and i'm more than happy to 
demonstrate and/or provide my tools to them.

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



-
ISN is currently hosted by Attrition.org

To unsubscribe email majordomo () attrition org with 'unsubscribe isn'
in the BODY of the mail.