Date: Fri Aug 12 18:49:59 2005
From: kf_lists at digitalmunition.com (KF (lists))
Subject: Bluetooth: Theft of Link Keys for Fun and
	Profit?

Adam Laurie wrote:

>
> Excuse me? You are skipping over the only important bit of your 
> "disclosure"! 

When did I claim this was a "disclosure", this was simply some notes 
that I have jotted down while messing around with bluetooth link keys. I 
was not "disclosing" and new vulnerabilities, I am simply documenting 
how things can be done after you have obtained a link key. I have not 
seen any documentation on this anywhere so I figured I would create it.

> Since getting the key is the only remotely difficult part, you need to 
> address that or you've got nothing of interest... 

Maybe its not interesting to you... but then again not everyone is as up 
on bluetooth as you.

> Obviously if you can spoof the BD_ADDR and already have the link key 
> you can connect because those are the only two things that make your 
> device unique.

Simply having the link key does you no good if you don't know where or 
how to use it right ?

Just like exploiting a buffer overflow is blatantly obvious to alot of 
folks you still see new papers on how the technique works. This is no 
different. I am explaining a technique... not everyone knows its as easy 
as placing the key into a particular file in /var.

> This is like saying "If you make a copy of my house key you can open 
> my door!". Not really big news. 

You are correct. For the sake of argument lets pretend your door has a 
special keyslot location under the patio.  I am simply making sure 
everyone knows where to insert the key after they have obtained it. 
Again... nothing earth shattering... nor did I claim it was.

>
> Tools? 

If I could get  some valid non pseudo code to calculate e22 and e21 I 
would gladly release some of my own.  Apart from generic pseudo code I 
haven't seen any. Maybe you would like to share yours with the rest of us?

> Apart from a $10,000 sniffer?
>
Mine was only $1600, sounds like you got ripped off. =]

>
> This is true for some, but not all devices. Some other hints are 
> already published, here:
>
>   http://trifinite.org/trifinite_stuff_bluedump.html
>
noted...

> Please explain - if you're "stealing" a key from a machine you're 
> running hcid on, then you already own that key anyway, surely?


Who said I was stealing it from the machine I am running hcid on?

Perhaps I understood that bluez bug incorrectly. The code in question is 
for the bluetooth pin helper which gets called with the arguments 
<in|out><bdaddr><devname>. If the devname contained special chars and 
the pin helper was invoked it would be passed through popen like so:

snprintf(str, sizeof(str), "%s %s %s \"%s\"", hcid.pin_helper,ci->out ? 
"out" : "in", addr, tmp);
pipe = popen(str, "r");

Which would in turn allow a remote attacker to run commands on the 
machine running hcid.

Maybe it would make you feel better if I said I took root on a linux box 
that I did not own and stole the /etc/blueooth/link_keys file.

Or perhaps I stole /var/root/Library/Preferences/blued.plist off an OSX 
machine.

I could have even taken it from \HKLM\SOFTWARE\Widcomm\BtConfig\Devices\ 
on a windows box that I had previously broken into.

>
>
> You could try the "bdaddr" tool in the BlueZ package.
>
Good info! Is that documented somewhere or is it like the Ericsson 
opcode that was mysteriously left out of the documentation?

-KF

Powered by blists - more mailing lists