   |
Serious flaws in bluetooth security lead to
disclosure of personal data
Summary
In
November 2003, Adam Laurie of A.L. Digital Ltd. discovered that there are
serious flaws in the authentication and/or data transfer mechanisms on
some bluetooth enabled devices. Specifically, three vulnerabilities have
been found:
Firstly, confidential data can be obtained,
anonymously, and without the owner's knowledge or consent, from some
bluetooth enabled mobile phones. This data includes, at least, the entire
phonebook and calendar, and the phone's IMEI.
Secondly, it has been found that the complete memory
contents of some mobile phones can be accessed by a previously trusted
("paired") device that has since been removed from the trusted list. This
data includes not only the phonebook and calendar, but media files such as
pictures and text messages. In essence, the entire device can be "backed
up" to an attacker's own system.
Thirdly, access can be gained to the AT command set of
the device, giving full access to the higher level commands and channels,
such as data, voice and messaging. This third vulnerability was identified
by Martin Herfurt, and they have since started working together on finding
additional possible exploits resulting from this vulnerability.
Finally, the current trend for "Bluejacking" is
promoting an environment which puts consumer devices at greater risk from
the above attacks.
Vulnerabilities
The SNARF attack:
It is possible, on some makes of device, to connect to the
device without alerting the owner of the target device of the request, and
gain access to restricted portions of the stored data therein, including
the entire phonebook (and any images or other data associated with the
entries), calendar, realtime clock, business card, properties, change log,
IMEI (International Mobile Equipment Identity [6], which uniquely
identifies the phone to the mobile network, and is used in illegal phone
'cloning'). This is normally only possible if the device is in
"discoverable" or "visible" mode, but there are tools available on the
Internet that allow even this safety net to be bypassed[4]. Further
details will not be released at this time (see below for more on this),
but the attack can and will be demonstrated to manufacturers and press if
required.
The BACKDOOR attack:
The backdoor attack involves establishing a trust relationship through
the "pairing" mechanism, but ensuring that it no longer appears in the
target's register of paired devices. In this way, unless the owner is
actually observing their device at the precise moment a connection is
established, they are unlikely to notice anything untoward, and the
attacker may be free to continue to use any resource that a trusted
relationship with that device grants access to (but note that so far we
have only tested file transfers). This means that not only can data be
retrieved from the phone, but other services, such as modems or Internet,
WAP and GPRS gateways may be accessed without the owner's knowledge or
consent. Indications are that once the backdoor is installed, the above
SNARF attack will function on devices that previously denied access, and
without the restrictions of a plain SNARF attack, so we strongly suspect
that the other services will prove to be available also.
The BLUEBUG attack:
The bluebug attack creates a serial profile connection to the
device, thereby giving full access to the AT command set, which can then
be exploited using standard off the shelf tools, such as PPP for
networking and gnokii for messaging, contact management, diverts and
initiating calls. With this facility, it is possible to use the phone to
initiate calls to premium rate numbers, send sms messages, read sms
messages, connect to data services such as the Internet, and even monitor
conversations in the vicinity of the phone. This latter is done via a
voice call over the GSM network, so the listening post can be anywhere in
the world. Bluetooth access is only required for a few seconds in order to
set up the call. Call forwarding diverts can be set up, allowing the
owner's incoming calls to be intercepted, either to provide a channel for
calls to more expensive destinations, or for identity theft by
impersonation of the victim.
Bluejacking:
Although known to the technical community and early adopters for some
time, the process now known as "Bluejacking"[1] has recently come to the
fore in the consumer arena, and is becoming a popular mechanism for
exchanging anonymous messages in public places. The technique involves
abusing the bluetooth "pairing"[2] protocol, the system by which bluetooth
devices authenticate each other, to pass a message during the initial
"handshake" phase. This is possible because the "name" of the initiating
bluetooth device is displayed on the target device as part of the
handshake exchange, and, as the protocal allows a large user defined name
field - up to 248 characters - the field itself can be used to pass the
message. This is all well and good, and, on the face of it, fairly
harmless, but, unfortunately, there is a down side. There is a potential
security problem with this, and the more the practice grows and is
accepted by the user community, and leveraged as a marketing tool by the
vendors, the worse it will get. The problem lies in the fact that the
protocol being abused is designed for information exchange. The ability to
interface with other devices and exchange, update and synchronise data, is
the raison d'être of bluetooth. The bluejacking technique is using the
first part of a process that allows that exchange to take place, and is
therefore open to further abuse if the handshake completes and the
"bluejacker" successfully pairs with the target device. If such an event
occurs, then all data on the target device bacomes available to the
initiator, including such things as phone books, calendars, pictures and
text messages. As the current wave of PDA and telephony integration
progresses, the volume and quality of such data will increase with the
devices' capabilities, leading to far more serious potential compromise.
Given the furore that errupted when a second-hand Blackberry PDA was sold
without the previous owner's data having been wiped[3], it is alarming to
think of the consequences of a single bluejacker gathering an entire
corporate staff's contact details by simply attending a conference or
camping outside their building or in their foyer with a bluetooth capable
device and evil intent. Of course, corporates are not the only potential
targets - a bluejacking expedition to, say, The House of Commons, or The
US Senate, could provide some interesting, valuable and, who's to say,
potentially damaging or compromising data.
The above may sound alarmist and far fetched, and the
general reaction would probably be that most users would not be duped into
allowing the connection to complete, so the risk is small. However, in
today's society of instant messaging, the average consumer is under a
constant barrage of unsolicted messages in one form or another, whether it
be by SPAM email, or "You have won!" style SMS text messages, and do not
tend to treat them with much suspicion (although they may well be
sceptical about the veracity of the offers). Another message popping up on
their 'phone saying something along the lines of "You have won 10,000
pounds! Enter this 4 digit PIN number and then dial 0900-SUCKER to collect
your prize!" is unlikely to cause much alarm, and is more than likely to
succeed in many cases.
Workarounds and
fixes
We are not aware of any workarounds for the SNARF or
BLUEBUG attacks at this time, other than to switch off bluetooth. For
permanent fixes, see the 'Fixes' section at the bottom of the page.
To permanently remove a pairing, and protect against
future BACKDOOR attacks, it seems you must perform a factory reset, but
this will, of course, erase all your personal data.
To avoid Bluejacking, "just say no". :)
The above methods work to the best of our knowledge,
but, as the devices affected are running closed-source proprietory
software, it not possible to verify that without the collaboration of the
manufacturers. We therefore make no claims as to the level of protection
they provide, and you must continue to use bluetooth at your own risk.
Who's
Vulnerable
To date the quantity of devices tested is not great.
However, due to the fact that they are amongst the most popular brands, we
still consider the affected group to be large. It is also assumed that
there are shared implementations of the bluetooth stack, so what affects
one model is likely to affect others. This table is accurate to the best
of our knowledge, but without the cooperation of the manufacturers (which
we currently do not have), it is not possible to conduct more extensive
validation.
The devices known to be vulnerable at this time
are:
| Vulnerability Matrix (* = NOT
Vulnerable) |
| Make |
Model |
Firmware Rev |
BACKDOOR |
SNARF when
Visible |
SNARF when
NOT Visible |
BUG |
| Ericsson |
T68 |
20R1B
20R2A013
20R2B013
20R2F004
20R5C001
|
? |
Yes |
No |
No |
| Sony Ericsson |
R520m |
20R2G |
? |
Yes |
No |
? |
| Sony Ericsson |
T68i |
20R1B
20R2A013
20R2B013
20R2F004
20R5C001 |
? |
Yes |
? |
? |
| Sony Ericsson |
T610 |
20R1A081
20R1L013
20R3C002
20R4C003
20R4D001 |
? |
Yes |
No |
? |
| Sony Ericsson |
T610 |
20R1A081 |
? |
? |
? |
Yes |
| Sony Ericsson |
Z1010 |
? |
? |
Yes |
? |
? |
| Sony Ericsson |
Z600 |
20R2C007
20R2F002
20R5B001 |
? |
Yes |
? |
? |
| Nokia |
6310 |
04.10
04.20
4.07
4.80
5.22
5.50 |
? |
Yes |
Yes |
? |
| Nokia |
6310i |
4.06
4.07
4.80
5.10
5.22
5.50
5.51 |
No |
Yes |
Yes |
Yes |
| Nokia |
7650 |
? |
Yes |
No (+) |
? |
No |
| Nokia |
8910 |
? |
? |
Yes |
Yes |
? |
| Nokia |
8910i |
? |
? |
Yes |
Yes |
? |
| * Siemens |
S55 |
? |
No |
No |
No |
No |
| * Siemens |
SX1 |
? |
No |
No |
No |
No |
| Motorola |
V600 (++) |
? |
No |
No |
No |
Yes |
| Motorola |
V80 (++) |
? |
No |
No |
No |
Yes |
+ We now believe the 7650 is only vulnerable to SNARF
if it has already been BACKDOORed.
++ The V600 and V80 are discoverable
for only 60 seconds, when first powered on or when this feature is user
selected, and the window for BDADDR discovery is therefore very small.
Motorola have stated that they will correct the vulnerability in current
firmware.
Disclosure
What
is the Philosophy of Full Disclosure, and why are we providing the tools
and detailing the methods that allow this to be done? The reasoning is
simple - by exposing the problem we are achieving two goals: firstly, to
alert users that the dangers exist, in order that they can take their own
precautions against compromise, and secondly, to put pressure on
manufacturers to rectify the situation. Consumers have a right to expect
that their confidential data is treated as such, and is not subject to
simple compromise by poorly implemented protocols on consumer devices.
Manufacturers have a duty of care to ensure that such protection is
provided, but, in practice, commercial considerations will often take
precedence, and, given the choice, they may choose to simply supress or
hide the problem, or, even worse, push for laws that prevent the discovery
and/or disclosure of such flaws[5]. In our humble opinion, laws provide
scant consumer protection against the lawless.
However, having said that, in this particular case, we
do not feel it is appropriate to follow the normal procedure of liaising
with manufacturers and giving them an opportunity to rectify the problem
before disclosing to the general public (this is not to say we haven't
contacted them - we have), as there are simply too many of them, and the
problem is too widespread to realistically believe that they could either
adhere to the strict levels of confidentiality required until the problem
has been rectified, or that there is even the possibilty that the problem
can be rectified in a reasonable timescale. Also, the volume of data
currently at risk is too great to allow the situation to continue
unchecked.
Instead, we feel it is more important to achieve our
primary goal, and alert the general public to the fact that the problem
exists, and to give them the information required to adequetely defend
themselves. Fortunately, the defence is relatively simple, and is detailed
above. To date we do not have a large selection of phones or other devices
to test, so the advice is somewhat generic, but we will publish more
detailed information as and when it becomes available.
Tools
Proof of
concept utilities have been developed, but are not yet available in the
wild. They are:
- bluestumbler - Monitor and log all visible
bluetooth devices (name, MAC, signal strength, capabilities), and
identify manufacturer from MAC address lookup.
- bluebrowse - Display available services on a
selected device (FAX, Voice, OBEX etc).
- bluejack - Send anoymous message to a target device
(and optionally broadcast to all visible devices).
- 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).
- bluebug - Set up covert serial channel to
device.
Tools will not be released at this time, so please do not
ask. However, if you are a bona-fide manufacturer of bluetooth devices
that we have been otherwise unable to contact, please feel free to get
in touch for more details on how you can identify your device status.
Credits
The
above vulnerabilities were discovered by Adam Laurie, during the course of
his work with A.L. Digital, in November 2003, and this announcement was
prepared thereafter by Adam and Ben Laurie for immediate release.
Adam Laurie is Managing Director and Chief Security
Officer of A.L. Digital Ltd.
Ben Laurie is Technical Director of A.L. Digital, and
author of Apache-SSL and contributor to many other open source projects,
too numerous to expand on here.
A.L. Digital Ltd. are the owner operators of The
Bunker, the world's most secure data centre(s).
e: adam@algroup.co.uk
w: http://www.aldigital.co.uk
e: ben@algroup.co.uk
w:
http://www.apache-ssl.org/ben.html
Further information relating to this disclosure will
be updated at http://www.bluestumbler.org
References:
[1]
[2]
[3]
[4]
- bluesniff
- btscanner
- redfang
[5]
[6]
|
