Message-ID: <42FCC90F.9020903@thebunker.net>
Date: Fri Aug 12 17:59:00 2005
From: adam.laurie at thebunker.net (Adam Laurie)
Subject: Bluetooth: Theft of Link Keys for Fun and
	Profit?

KF (lists) wrote:
> Enjoy...
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 				Theft of Bluetooth Link Keys for Fun and Profit? 
> 					kf[at]digitalmunition[dot]com
> 				http://www.digitalmunition.com/TheftOfLinkKey.txt
> 
> In essence two things are required to attack a bluetooth pair. The ability to spoof a BD_ADDR and possession of a 
> secret key also known as a Link Key. Some folks may argue that a third item is required, in the form of a Bluetooth 
> Protocol Analyzer, however several trivial ways to steal link keys exist. 
> 
> In the Bluetooth Specification version 1.0A description of the Link Manager Protocol, section 3.2.1 states that
> "The authentication procedure is based on a challenge-response scheme... The verifier sends an LMP_au_rand PDU which 
> contains a random number (the challenge) to the claimant. The claimant calculates a response, which is a function of 
> the challenge, the claimant's BD_ADDR and a secret key. That response is sent back to the verifier, which checks if 
> the response was correct or not... A successful calculation of the authentication response requires that two devices 
> share a secret key." 
> 
> With both a spoofed BD_ADDR and a Link Key in hand we can simply allow our device to handle the challenge response 
> with out any special code required. Once the authentication has passed we in theory should have untethered access to 
> the device we are attacking. 
> 
> In this example scenario We have 3 devices involved: 'threat', 'gumstix', and 'pocket_pc'. We will be attacking the 
> pairing between 'pocket_pc' and 'threat' from 'gumstix'.
> 
> Since 'threat' is currently paired with 'pocket_pc' it can connect to the Serial Port profile at will. This profile
> has been protected by the check box "Authentication (Passkey) required", so any non paired device that attempts to 
> connect will be prompted to pair or simply refused a connection.
> 
> Here is the connection from 'threat' to 'pocket_pc'
> threat:~# rfcomm connect 2 00:04:3E:65:A1:C8 1
> Connected /dev/rfcomm2 to 00:04:3E:65:A1:C8 on channel 1
> Press CTRL-C for hangup
> 
> And here is the connection from 'gumstix' to 'pocket_pc'
> #  rfcomm connect 2 00:04:3E:65:A1:C8 1
> Can't connect RFCOMM socket: Connection refused
> (we also got a pairing request from 'gumstix' on the 'pocket_pc' screen)
> 
> As mentioned above theft of the actual Link Key is fairly trivial, so for the scope of this document assume that 
> either A) the pairing process was observed via Protocol Analyzer or B) Some sort of software bug was used to steal 
> the link key. 

Excuse me? You are skipping over the only important bit of your 
"disclosure"! Since getting the key is the only remotely difficult part, 
you need to address that or you've got nothing of interest... 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. This is like saying "If you make a copy of my house key you can 
open my door!". Not really big news.

> 
> As an example we could have forced a pairing attempt between 'pocket_pc' and 'gumstix' for sniffing purposes by 
> causing the existing pair to become invalid. From there calculations against the link key can be done. 

Tools? Apart from a $10,000 sniffer?

> 
> # cat > linkkeys
> 00:04:3E:65:A1:C8 thisisgarbadeasdasdadasdadasdasds 2
> ^C
> #   rfcomm connect 2 00:04:3E:65:A1:C8 1
> Can't connect RFCOMM socket: Connection refused
> 
> At this point the pairing data stord on 'pocket_pc' has been ruined, and the devices will have to re-pair.

This is true for some, but not all devices. Some other hints are already 
published, here:

   http://trifinite.org/trifinite_stuff_bluedump.html

> 
> Another chance to steal the link key could arise with certain software bugs in a devices Bluetooth Stack, for example 
> http://cvs.sourceforge.net/viewcvs.py/bluez/utils/hcid/security.c?r1=1.34&r2=1.31 .

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

> 
> Our goal in this attack is to allow 'gumstix' to connect to 'pocket_pc' without prompting for device pairing. 
> In this case since we already know that 'pocket_pc' and 'threat' are paired so we will make an attempt to spoof 
> requests from 'gumstix' by pretenting to be 'threat'. 
> 
>>From 'gumstix' first we must first obtain a few things, the device address, name and class of 'threat'. 
> 
> # hcitool inquiry
> Inquiring ...
>         00:04:3E:65:A1:C8       clock offset: 0x0ee7    class: 0x120110
>         00:0A:3A:54:71:95       clock offset: 0x0010    class: 0x3e0100
> # hcitool scan
> Scanning ...
>         00:04:3E:65:A1:C8       Pocket_PC
>         00:0A:3A:54:71:95       threat
> 
> Next will simply configure 'gumstix' to become a mirror image of 'threat' based on the above data. 
> 
> The first step is to steal the BD_ADDR from 'threat'. 
> 
> For this I personally have 2 options, one is my ROK 101 008 from Ericsson and option two is my ROK 104 001 from 
> Infineon. The only other option that I am aware of is the Infineon pba31307 however I have not tested this chip 
> myself. As a side note I am currently unaware of a method that allows a Cambridge silicon radio to specify a BD_ADDR. 

You could try the "bdaddr" tool in the BlueZ package.

cheers,
Adam
-- 
Adam Laurie                         Tel: +44 (0) 20 7605 7000
The Bunker Secure Hosting Ltd.      Fax: +44 (0) 20 7605 7099
Shepherds Building                  http://www.thebunker.net
Rockley Road
London W14 0DA                      mailto:adam@...bunker.net
UNITED KINGDOM                      PGP key on keyservers

Powered by blists - more mailing lists