Adam Laurie
12/11/03, 21:15
--------------050000080900040703060905
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
folks,
please find attached a disclosure paper on bluetooth.
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
--------------050000080900040703060905
Content-Type: text/plain;
name="blu.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline;
filename="blu.txt"
Summary
-------
There are serious flaws in the authentication and/or data transfer mechan=
isms on some bluetooth enabled devices. Specifically, two 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.
Secondly, it has been found that the complete memory contents of some mob=
ile phones can be accessed by a previously trusted ("paired") device that=
has since been removed from the trusted list. This data includes not onl=
y the phonebook and calendar, but media files such as pictures and text m=
essages. In essence, the entire device can be "backed up" to an attacker'=
s own system.
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 withou=
t 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), cal=
endar, realtime clock, business card, properties, change log etc. This is=
normally only possible if the device is in "discoverable" or "visible" m=
ode, but there are tools available on the Internet that allow even this s=
afety 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 demons=
trated to manufacturers and press if required.
The BACKDOOR attack:
The backdoor attack involves establishing a trust relationship through th=
e "pairing" mechanism, but ensuring that it no longer appears in the tar=
get's register of paired devices. In this way, unless the owner is actual=
ly observing their device at the precise moment a connection is establish=
ed, they are unlikely to notice anything untoward, and the attacker may b=
e free to continue to use any resource that a trusted relationship with t=
hat device grants access to (but note that so far we have only tested fi=
le transfers). This means that not only can data be retrieved from the ph=
one, but other services, such as modems or Internet, WAP and GPRS gateway=
s may be accessed without the owner's knowledge or consent. Indications a=
re that once the backdoor is installed, the above SNARF attack will funct=
ion on devices that previously denied access, and without the restriction=
s of a plain SNARF attack, so we strongly suspect that the other services=
will prove to be available also.
Bluejacking:
Although known to the technical community and early adopters for some tim=
e, the process now known as "Bluejacking"[1] has recently come to the for=
e in the consumer arena, and is becoming a popular mechanism for exchangi=
ng anonymous messages in public places. The technique involves abusing th=
e 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 d=
evice 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 a=
ll well and good, and, on the face of it, fairly harmless, but, unfortuna=
tely, there is a down side. There is a potential security problem with th=
is, 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=
=2E The problem lies in the fact that the protocol being abused is desig=
ned for information exchange. The ability to interface with other devices=
and exchange, update and synchronise data, is the raison d'e^tre of blue=
tooth. The bluejacking technique is using the first part of a process tha=
t allows that exchange to take place, and is therefore open to further ab=
use if the handshake completes and the "bluejacker" successfully pairs wi=
th the target device. If such an event occurs, then all data on the targe=
t device bacomes available to the initiator, including such things as pho=
ne books, calendars, pictures and text messages. As the current wave of P=
DA and telephony integration progresses, the volume and quality of such d=
ata will increase with the devices' capabilities, leading to far more ser=
ious potential compromise. Given the furore that errupted when a second-h=
and 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 blueja=
cker gathering an entire corporate staff's contact details by simply atte=
nding a conference or camping outside their building or in their foyer wi=
th a bluetooth capable device and evil intent. Of course, corporates are =
not the only potential targets - a bluejacking expedition to, say, The Ho=
use of Commons, or The US Senate, could provide some interesting, valuabl=
e and, who's to say, potentially damaging or compromising data.
The above may sound alarmist and far fetched, and the general reaction wo=
uld probably be that most users would not be duped into allowing the conn=
ection to complete, so the risk is small. However, in today's society of =
instant messaging, the average consumer is under a constant barrage of un=
solicted 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 w=
ith much suspicion (although they may well be sceptical about the veracit=
y of the offers). Another message popping up on their 'phone saying somet=
hing along the lines of "You have won 10,000 pounds! Enter this 4 digit P=
IN number and then dial 0900-SUCKER to collect your prize!" is unlikely t=
o cause much alarm, and is more than likely to succeed in many cases.
Workarounds and fixes
---------------------
We are not aware of any fixes for the SNARF attack at this time other tha=
n to switch off bluetooth.
To permanently remove a pairing, and protect against future BACKDOOR atta=
cks, 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 therefo=
re make no claims as to the level of protection they provide, and you mus=
t 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 imp=
lementations of the bluetooth stack, so what affects one model is likely =
to affect others.=20
The devices known to be vulnerable at this time are:
SNARF attack:
Ericsson: T68, T68i, T610
Nokia: 6310i, 7650
BACKDOOR attack:
Nokia: 6310i, 7650
* It is not known at this time if Ericsson's are also vulnerable to the=
BACKDOOR attack.
Disclosure
----------
What is the Philosophy of Full Disclosure, and why are we providing the t=
ools 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 man=
ufacturers to rectify the situation. Consumers have a right to expect tha=
t their confidential data is treated as such, and is not subject to simpl=
e compromise by poorly implemented protocols on consumer devices. Manufac=
turers have a duty of care to ensure that such protection is provided, bu=
t, 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 disclos=
ure 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 wides=
pread to realistically believe that they could either adhere to the stric=
t levels of confidentiality required until the problem has been rectifie=
d, 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 al=
ert the general public to the fact that the problem exists, and to give t=
hem the information required to adequetely defend themselves. Fortunatel=
y, 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 ad=
vice is somewhat generic, but we will publish more detailed information a=
s 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 (nam=
e, MAC, signal strength, capabilities), and identify manufacturer from MA=
C address lookup.
bluebrowse - Display available services on a selected device (F=
AX, Voice, OBEX etc).
bluejack - Send anoymous message to a target device (and opti=
onally broadcast to all visible devices).
bluesnarf - Copy data from target device (everything if pairin=
g succeeds, or a subset in other cases, including phonebook and calendar.=
In the latter case, user will not be alerted by any bluejack message).
Tools will not be released at this time, so please do not ask. However, i=
f 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 d=
etails on how you can identify your device status.
Credits
-------
The above vulnerabilities were discovered by Adam Laurie, during the cour=
se 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. Digi=
tal Ltd.
Ben Laurie is Technical Director of A.L. Digital, and author of Apache-SS=
L and contributor to many other open source projects, too numerous to exp=
and 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
w: http://www.thebunker.net
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] - http://www.bluejackq.com/
http://www.theregister.co.uk/content/6/33781.html
http://news.bbc.co.uk/1/hi/technology/3237755.stm
[2] - http://www.palowireless.com/infotooth/tutorial/lmp.asp
[3] - http://www.out-law.com/php/page.php?page_id=3Dblackberryforsale1061=
969777
[4] - http://bluesniff.shmoo.com/
[5] - http://www.eff.org/
Copyright (c) 2003, Adam Laurie, Ben Laurie, A.L. Digital Ltd., all right=
s reserved.
--------------050000080900040703060905--
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
folks,
please find attached a disclosure paper on bluetooth.
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
--------------050000080900040703060905
Content-Type: text/plain;
name="blu.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline;
filename="blu.txt"
Summary
-------
There are serious flaws in the authentication and/or data transfer mechan=
isms on some bluetooth enabled devices. Specifically, two 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.
Secondly, it has been found that the complete memory contents of some mob=
ile phones can be accessed by a previously trusted ("paired") device that=
has since been removed from the trusted list. This data includes not onl=
y the phonebook and calendar, but media files such as pictures and text m=
essages. In essence, the entire device can be "backed up" to an attacker'=
s own system.
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 withou=
t 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), cal=
endar, realtime clock, business card, properties, change log etc. This is=
normally only possible if the device is in "discoverable" or "visible" m=
ode, but there are tools available on the Internet that allow even this s=
afety 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 demons=
trated to manufacturers and press if required.
The BACKDOOR attack:
The backdoor attack involves establishing a trust relationship through th=
e "pairing" mechanism, but ensuring that it no longer appears in the tar=
get's register of paired devices. In this way, unless the owner is actual=
ly observing their device at the precise moment a connection is establish=
ed, they are unlikely to notice anything untoward, and the attacker may b=
e free to continue to use any resource that a trusted relationship with t=
hat device grants access to (but note that so far we have only tested fi=
le transfers). This means that not only can data be retrieved from the ph=
one, but other services, such as modems or Internet, WAP and GPRS gateway=
s may be accessed without the owner's knowledge or consent. Indications a=
re that once the backdoor is installed, the above SNARF attack will funct=
ion on devices that previously denied access, and without the restriction=
s of a plain SNARF attack, so we strongly suspect that the other services=
will prove to be available also.
Bluejacking:
Although known to the technical community and early adopters for some tim=
e, the process now known as "Bluejacking"[1] has recently come to the for=
e in the consumer arena, and is becoming a popular mechanism for exchangi=
ng anonymous messages in public places. The technique involves abusing th=
e 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 d=
evice 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 a=
ll well and good, and, on the face of it, fairly harmless, but, unfortuna=
tely, there is a down side. There is a potential security problem with th=
is, 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=
=2E The problem lies in the fact that the protocol being abused is desig=
ned for information exchange. The ability to interface with other devices=
and exchange, update and synchronise data, is the raison d'e^tre of blue=
tooth. The bluejacking technique is using the first part of a process tha=
t allows that exchange to take place, and is therefore open to further ab=
use if the handshake completes and the "bluejacker" successfully pairs wi=
th the target device. If such an event occurs, then all data on the targe=
t device bacomes available to the initiator, including such things as pho=
ne books, calendars, pictures and text messages. As the current wave of P=
DA and telephony integration progresses, the volume and quality of such d=
ata will increase with the devices' capabilities, leading to far more ser=
ious potential compromise. Given the furore that errupted when a second-h=
and 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 blueja=
cker gathering an entire corporate staff's contact details by simply atte=
nding a conference or camping outside their building or in their foyer wi=
th a bluetooth capable device and evil intent. Of course, corporates are =
not the only potential targets - a bluejacking expedition to, say, The Ho=
use of Commons, or The US Senate, could provide some interesting, valuabl=
e and, who's to say, potentially damaging or compromising data.
The above may sound alarmist and far fetched, and the general reaction wo=
uld probably be that most users would not be duped into allowing the conn=
ection to complete, so the risk is small. However, in today's society of =
instant messaging, the average consumer is under a constant barrage of un=
solicted 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 w=
ith much suspicion (although they may well be sceptical about the veracit=
y of the offers). Another message popping up on their 'phone saying somet=
hing along the lines of "You have won 10,000 pounds! Enter this 4 digit P=
IN number and then dial 0900-SUCKER to collect your prize!" is unlikely t=
o cause much alarm, and is more than likely to succeed in many cases.
Workarounds and fixes
---------------------
We are not aware of any fixes for the SNARF attack at this time other tha=
n to switch off bluetooth.
To permanently remove a pairing, and protect against future BACKDOOR atta=
cks, 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 therefo=
re make no claims as to the level of protection they provide, and you mus=
t 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 imp=
lementations of the bluetooth stack, so what affects one model is likely =
to affect others.=20
The devices known to be vulnerable at this time are:
SNARF attack:
Ericsson: T68, T68i, T610
Nokia: 6310i, 7650
BACKDOOR attack:
Nokia: 6310i, 7650
* It is not known at this time if Ericsson's are also vulnerable to the=
BACKDOOR attack.
Disclosure
----------
What is the Philosophy of Full Disclosure, and why are we providing the t=
ools 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 man=
ufacturers to rectify the situation. Consumers have a right to expect tha=
t their confidential data is treated as such, and is not subject to simpl=
e compromise by poorly implemented protocols on consumer devices. Manufac=
turers have a duty of care to ensure that such protection is provided, bu=
t, 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 disclos=
ure 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 wides=
pread to realistically believe that they could either adhere to the stric=
t levels of confidentiality required until the problem has been rectifie=
d, 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 al=
ert the general public to the fact that the problem exists, and to give t=
hem the information required to adequetely defend themselves. Fortunatel=
y, 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 ad=
vice is somewhat generic, but we will publish more detailed information a=
s 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 (nam=
e, MAC, signal strength, capabilities), and identify manufacturer from MA=
C address lookup.
bluebrowse - Display available services on a selected device (F=
AX, Voice, OBEX etc).
bluejack - Send anoymous message to a target device (and opti=
onally broadcast to all visible devices).
bluesnarf - Copy data from target device (everything if pairin=
g succeeds, or a subset in other cases, including phonebook and calendar.=
In the latter case, user will not be alerted by any bluejack message).
Tools will not be released at this time, so please do not ask. However, i=
f 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 d=
etails on how you can identify your device status.
Credits
-------
The above vulnerabilities were discovered by Adam Laurie, during the cour=
se 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. Digi=
tal Ltd.
Ben Laurie is Technical Director of A.L. Digital, and author of Apache-SS=
L and contributor to many other open source projects, too numerous to exp=
and 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
w: http://www.thebunker.net
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] - http://www.bluejackq.com/
http://www.theregister.co.uk/content/6/33781.html
http://news.bbc.co.uk/1/hi/technology/3237755.stm
[2] - http://www.palowireless.com/infotooth/tutorial/lmp.asp
[3] - http://www.out-law.com/php/page.php?page_id=3Dblackberryforsale1061=
969777
[4] - http://bluesniff.shmoo.com/
[5] - http://www.eff.org/
Copyright (c) 2003, Adam Laurie, Ben Laurie, A.L. Digital Ltd., all right=
s reserved.
--------------050000080900040703060905--