Full Disclosure mailing list archives

Re: Re: Serious flaws in bluetooth security lead to disclosure of personal data


From: <srenna () vdbmusic com>
Date: Fri, 14 Nov 2003 08:30:12 -0500

Adam,

Are you aware of any very informative papers or tools(other
than btscanner) for use in testing bluetooth networks(such
as Airsnort).  From what I know about it thus far, it just
operates in the same spectrum as 802.11b, but I'm still
researching.  I'm very interested in observing traffic
patterns and analyzing what is exactly happening.  I do
analysis for a living and it's a new area that no one
really at my position has an experience in(even though it's
been around for a while).  My idea is to research how far a
bluetooth signal will travel when leaving a building as we
want to set up a test lab and do not want people sitting
outside to be able to detect any of it.  We've looked into
doing this with 802.11b standard before but we cannot find
a way to mute the signal enough to meet our needs. 

Scott Renna


On Fri, 14 Nov 2003 12:40:01 +0000
 Adam Laurie <adam () algroup co uk> wrote:
Pentest Security Advisories wrote:
Summary.
========

A recent posting from A.L. Digital suggests that
security flaws exist in
Bluetooth, while not describing the vulnerabilities in
any technical 
detail. This email concerns itself specifically with
the vulnerabilities 
related to retrieval of personal information from
devices.

Some of the attacks described have been known about for
some time and
discussed (or hinted at) in public before, at
BlackHat/Defcon (Las Vegas)
by FX of Phenoelit (More Embedded Systems), at Defcon
by Bruce Potter of
Shmoo and most recently by Alexander Grimm, Marcel
Holtmann and Andreas
Vedral at the Wireless Technologies Congress.

i think "hint" is the operative word here. i came away
from defcon
unaware that such an attack was possible, and, to date, i
am still
unable to find any papers or tools that do anything other
than brute
forcing of macs or show that it's possible to browse
services from a
brute forced mac (and just to be clear here - this does
not mean browse
files. it just means you can obtain a list of services
such as fax, obex
etc., not do anything with them). my co-author, ben, is a
fellow shmoo,
and he was equally unaware, and their sniffer tool gives
no hint that it
can be taken any further, nor does bruce's presentation
(http://www.shmoo.com/~gdead/dc-11-brucepotter.ppt),
although it's possible his actual talk did, but that is
not yet available on the defcon site. since posting,
marcel holtmann has brought his papers to my attention,
but i have not yet seen an english translation, so i
can't comment. your own tool "btscanner"

(http://www.pentest.co.uk/cgi-bin/viewcat.cgi?cat=downloads)
makes no mention of this attack, and the only reference
to any file
transfer mechanism is "obex", which is is in the "To do"
section of the
README: "3) Try to connect to services, particularly OBEX
which requires
no pair.".

at the end of the day, i'm not interested in getting into
a pissing
contest. the important thing is to get the manufacturers
to acknowledge
the problem, and the general public to be aware of it,
and to that end i
will add any and all information/links that come to light
to the
advisory page.

in the meantime, my discussions with manufacturers
indicate that so far
they have only been made aware of theoretical attacks,
and nobody has
thus far been able to actually pull data from the
targets. this attack
changes that.



Detail.
=======

It is incorrect to assume that these vulnerabilities
exist because of a
lack of security in Bluetooth itself. These
vulnerabilities are purely the
result of design errors in the host devices, and
Bluetooth is simply the
transport mechanism over which the attacks can be
carried out. The
vulnerabilities occur in some of the OBEX profiles used
by manufacturers
to transfer arbitrary information via Bluetooth.

agreed. the particular worry with bluetooth is that the
nature of the
mechanism makes for a far wider attack profile than irda
or serial cable.

[snip]

Fixes.
======

1) Only enable Bluetooth when absolutely necessary.

this is not a "fix". whilst enabled, the device is (in
some cases)
vulnerable.


2) Place the device in non-discoverable mode. While
this does not correct
   the fault, it is harder to find the target device.
There can be problems
   with this, some Nokia devices fail will to connect
properly when hidden.

although this will protect you against casual "drive-by"
style attacks,
it will not help against a specific determined attack as
your address
can be brute forced.


3) Refuse any pair attempt or content transfer unless
it is from a known
   and trusted device/source.

this only helps against the bluejack attack. SNARF does
not require any
user interaction.

the point of the current attack is that the content
transfer happens without any user interaction or pair
attempt (this being the really key difference between
this and previous attacks), and, ultimately, yes, this
should be the fix, but what is happening is that we're
bypassing this stage completely.


The ultimate fix is for manufacturers to provide a
greater separation of
services, an attitude that seems to have been taken
with the Ericsson T610.

indeed. however, i'm puzzled as to what you mean about
the T610, as we
have found it to be one of the vulnerable devices.

[snip]

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


_______________________________________________
Full-Disclosure - We believe in it.
Charter:
http://lists.netsys.com/full-disclosure-charter.html

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


Current thread: