Contents |
| Bluetooth pairing |
| Sniffing the Bluetooth pairing |
| Breaking the Bluetooth pairing |
Sniffing the Bluetooth pairing
Bluetooth pairing
Bluetooth pairing is understood as a trust relationship between two devices. When two Bluetooth devices agree to communicate with each other and establish a connection both devices must be paired up.
In order to pair two Bluetooth devices, a passkey needs to be exchanged between the two users. This passkey, also known as PIN code, is a security code (1 to 16 bytes in length) shared by both Bluetooth devices, which proves that both users have agreed to pair with each other .
With this PIN code, a link key is generated based on the following procedure:
1) A initialization key Kinit is created using the E22 algorithm, whose inputs are the PIN code and its lenght, the BD_ADDR and a 128 bit random number IN_RAND.
2) The devices use the initialization key Kinit to exchange two new random numbers, known as LK_RAND A and LK_RAND B. Each device generates a random number and sends it to the other device after XORing it with Kinit. Since both devices know Kinit, each device holds both LK_RAND random numbers too. With BD_ADDR and LK_RAND as inputs, the E21 algorithm creates the 128 bit link key Kab.
3) Once the link key Kab has been created, both devices use this shared key to authenticate each other on the next connection attempts.
However ...
It's possible to crack the pairing algorithm by using brute force. In 2005 Yaniv Shaked and Avishai Wool published Cracking the Bluetooth PIN and explained how to cryptographically crack the Bluetooth PIN. Basically, you can brute force inputs on the pairing algorithm until the temporary keys generated through out the algorithm match with the keys captured when sniffing the Bluetooth pairing between two remote Bluetooth devices.
The algorithm requires the following inputs:
- The PIN code, which can be calculated using brute force (usually it's a 4 digit code)
- BD_ADDR of the two remote devices, which can be obtained with a simple hci inquiry.
- The IN_RAND number, which in fact does not look very random (may be somehow based on a date/time stamp and can be obtained with a simple hci inquiry).
Through out the course of the pairing procedure, participating devices will exchange temporary keys which could be captured by an attacker who is eavesdropping the communications in the given piconet. The attacker can brute force the pairing algorithm and compare the temporary keys generated with the keys captured, if the keys do match the attacker will have successfully obtained the PIN code and the link key shared between the paired devices.
In 2006, Thierry Zoller developed the worlds first Bluetooth PIN brute force implementation, BTCrack. The tool can brute force the PIN code and the link key from captured pairing exchanges after eavesdropping the paring procedure. Response speed on a P4 3.6GHz is amazing: takes 0.25 sec. to crack a 4 digit PIN code and 42 min. to crack an 8 digit PIN code.
In 2006, David Hulton released btpincrack as a part of the OpenCiphers project.
In 2007, Thierry Zoller in cooperation with David Hulton announced BTCrack with FPGA support. Response speed is increased considerably: takes 0.001 sec. to crack a 4 digit PIN code and 10 sec. to crack an 8 digit PIN code.
En 2009, Eric Sesterhen and Thierry Zoller released the source code of Linux version for BTCrack.
Sniffing the Bluetooth pairing
As i explained, it's possible to build your own Bluetooth sniffer from a consumer Bluetooth dongle. Among all the cool things you can do with that sniffer, it'd be amazing it you could sniff the Bluetooth pairing process and obtain the secret link key shared between two remote devices.
First, you need to build your own Bluetooth sniffer.
Then, discover two random devices before they initiate the pairing process.
Andrea Bittau published a frontline tool which can be used for sending commands to the hardware sniffer. Instead, i'll use a modded version of this frontline coded by drgr33n and published under a Bluetooth security suite called Blue Smash.
Let's start sniffing...
At this time, the remote devices can begin the pairing process, packets generated will be captured by the sniffer.
Among all the packets captured, you may find the keys created for the Bluetooth link key generation and therefore obtain it.
OpenCiphers' Bluetooth Pin Cracking Core or BTCrack PIN Cracker by Thierry Zoller can be used to crack the link key from the sniffed keys.
You can check the cracked link key, Kab, is the same shared by the remote devices.
Once you own the Bluetooth link key, you can perform the BD_ADDR spoofing attack and use it to access to profiles requiring authorization/authentication in both devices, such as OBEX File Transfer Profile, which can be used to send files, get files and list directories in the mobile phone.
And the Dial Up Networking Profile, which canbe used to send AT Commands to the mobile phone.
Breaking the Bluetooth pairing
Sniffing and cracking the secret Bluetooth link key shared between two remote devices is only possible if the attacker can sniff the pairing process successfully. This means there's no way to sniff and crack the Bluetooth link key if both devices are already paired up, since they will follow the Challenge-Response authentication process.
If you find this scenario, it'd be interesting if you could break the pair relationship between both devices and force them to repeat the pairing process. Then you'll have the chance to sniff and crack the new link key.
Shaked and Wool Re-Pairing attack, the theory.
In 2005 Yaniv Shaked and Avishai Wool published a paper explaining how to cryptographically crack the Bluetooth PIN. I quote:
5.2 Attack details
Assume that two Bluetooth devices that have already been paired before now intend to establish communication again. This means that they don't need to create the link key Kab again, since they have already created and stored it before. They proceed directly to the Authentication phase (...). We describe three different methods that can be used to force the devices to repeat the pairing process. The efficiency of each method depends on the implementation of the Bluetooth core in the device under attack. These methods appear in order of efficiency:
- Since the devices skipped the pairing process and proceeded directly to the Authentication phase, the master device sends the slave an AU_RAND message, and expects the SRES message in return. Note that Bluetooth specifications allow a Bluetooth device to forget a link key. In such a case, the slave sends an LMP_not_accepted message in return, to let the master know it has forgotten the link key (...). Therefore, after the master device has sent the AU_RAND message to the slave, the attacker injects a LMP_not_accepted message toward the master. The master will be convinced that the slave has lost the link key and pairing will be restarted (...). Restarting the pairing procedure causes the master to discard the link key (...). This assures pairing must be done before devices can authenticate again.
- At the beginning of the Authentication phase, the master device is supposed to send the AU_RAND to the slave. If before doing so, the attacker injects a IN_RAND message toward the slave, the slave device will be convinced the master has lost the link key and pairing is restarted. This will cause the connection establishment to restart.
- During the Authentication phase, the master device sends the slave an AU_RAND message, and expects a SRES message in return. If, after the master has sent the AU_RAND message, an attacker injects a random SRES message toward the master, this will cause the Authentication phase to restart, and repeated attempts will be made (...). At some point, after a certain number of failed authentication attempts, the master device is expected to declare that the authentication procedure has failed (implementation dependent) and initiate pairing (...).
The three methods described above cause one of the devices to discard its link key. This assures the pairing process will occur during the next connection establishment, so the attacker will be able to eavesdrop on the entire process, and use the method described in Section 3 to crack the PIN.
Spoofing the wrong link key, the practice.
Shaked and Wool attack looks nice and smart, but method 3 can be described in a much easier way: You just need to spoof one device's BD_ADDR and provide a wrong Bluetooth link key when authenticating in some other device's Bluetooth profile. Trust relationship will be broken for security reasons and the stored link key deleted.
Let's see an example:
You discover two remote devices, a mobile phone and a PDA. You'd like to obtain the secret shared Bluetooth link key, however both devices are already paired up.
If any of the devices establishes a connection with the other one, they will follow a Challenge-Response process to validate the authentication mechanism.
In order to break the pair relationship, you need to spoof one of them first (spoof its BD_ADDR). Let's say you choose to spoof the mobile phone...
Then, you need to install a random Bluetooth link key in the system.
From now on whenever you try to establish a connection with any Bluetooth profile requiring authentication in the PDA, like the OBEX File Transfer Profile, the stored link key will be used in the Challenge-Response process.
The link key provided is wrong, so the Challenge-Response process will fail.
For security reasons, the trust relationship will be broken and the stored link key will be deleted in the PDA.
If the mobile phone now tries to establish a connection with the PDA, the devices won't follow the Challenge-Response authentication process; they will need to repeat the pairing process.
And you will be there to sniff and crack the new Bluetooth link key.