Message-ID: <3FB4CD21.5030405@algroup.co.uk>
Date: Fri, 14 Nov 2003 12:40:01 +0000
From: Adam Laurie <adam@...roup.co.uk>
To: Pentest Security Advisories <alerts@...test.co.uk>,
   bugtraq@...urityfocus.com, full-disclosure@...ts.netsys.com
Subject: Re: Serious flaws in bluetooth security lead to disclosure of personal
 data


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@...roup.co.uk
UNITED KINGDOM                PGP key on keyservers


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

Powered by blists - more mailing lists