lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <web-66115449@atlantech.net>
From: srenna at vdbmusic.com (srenna@...music.com)
Subject: Re: Serious flaws in bluetooth security
 lead to disclosure of personal data

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ