From: alerts at pentest.co.uk (Pentest Security Advisories)
Subject: Re: Serious flaws in bluetooth security lead to disclosure of personal
 data

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.


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.

In particular the OBEX Push Profile is often unprotected whereas the OBEX
FTP profile is not. The name of the profile is also misleading as you
would believe that the OBEX Push would only allow files to be uploaded.
However the profile also allows information retrieval.

The OBEX vulnerabilities can be divided into two categories, PUT and GET.
As is implied from the names, they refer to information being sent to or
returned by the host device. Both PUT and GET actions can be restricted by
the need to pair, however some manufacturers have chosen to remove this
restriction to add extra features, such as vCard exchanging.

It should be noted here that OBEX is protocol independent and it is
possible to exploit the vulnerabilities via IrDA and even via serial
connection. It should also be noted that OBEX does have the ability to
manage authentication. However, this is not used by any of the devices
we have tested over the past three months.

The rest of the information contained here will be based on un-paired and
un-trusted devices attacking a target device.

Much more information can be obtained from many devices by physical
contact or social engineering, however this is not a deficiency in
Bluetooth or the host device. Due to the prompt given by some devices, it
is possible to trick the user into pairing. However this is a form of
social engineering.

These vulnerabilities exist whether the Bluetooth device is in
discoverable mode or not.


Vulnerabilities.
=================

OBEX PUT vulnerabilities.
-------------------------

This series of attacks relates to the movement of information towards the
target device. These attacks are based upon information extracted from the
IrMC specification, which describes several interesting files.

The IrMC specification can be found at:
http://www.irda.org/standards/pubs/IrMC_v1p1Specs_Errata001024.zip

These files are often accessible via unprotected Bluetooth profiles. While
they can be viewed on protected profiles, some manufacturers choose to
also enable this via un-protected profiles such as "OBEX Push". OBEX also
has a DELETE action, which is a PUT with an empty body, by pushing to each
of the phone book entries it would be possible to overwrite or delete all
of the phone book entries. A solution for manufacturers would be to
separate the PUT functions into specific profiles and not allow the same
actions via all profiles.


OBEX GET vulnerabilities.
-------------------------

While similar to the PUT vulnerabilities, these present a much more of a
serious threat including invasion of privacy. All vulnerable files are
mentioned in the IrMC specification.

Once again these files are usually only accessible via protected Bluetooth
profiles, however, it appears that some manufacturers have used the same
code to implement the un-protected services and thus the files are
visible.


Fixes.
======

1) Only enable Bluetooth when absolutely necessary.

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.

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

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.


Current state of alerts.
========================

The information relating to these vulnerabilities has been in the public
domain for some time. However, until the recent bugtraq and full
disclosure posts, the consequences of these issues was not widely
advertised. A number of affected vendors have already been contacted with
varied degrees of response.


Researchers.
============

Mark Rowe, Pentest Limited.
Tim Hurman, Pentest Limited.
Contact: bluetooth at pentest.co.uk

Powered by blists - more mailing lists