Re: Bluetooth: Theft of Link Keys for Fun and Profit?

["KF (lists)" <kf_lists () digitalmunition com>]

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


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/