The idea behind Bluetooth technology was born in 1994, when a team of researchers at Ericsson Mobile Communications, led by Dr. Jaap Haartsen and Dr. Sven Mattisson, initiated a feasibility study of universal short-range, low-power wireless connectivity as a way of eliminating cables between mobile phones and computers, headsets and other devices. It was later developed into the Bluetooth technology we know today by the Bluetooth Special Interest Group (SIG), an industry association which was announced in May 1998 and formally founded in September 1998. The founding members were Ericsson, IBM, Intel, Nokia and Toshiba, and later in December 1999, 3Com Corporation, Lucent Technologies, Microsoft Corporation and Motorola Inc. joined the Bluetooth SIG.

After years of development the final Bluetooth technology uses the free and globally available 2.4GHz Industrial-Scientific-Medical (ISM) radio band, unlicensed for low-power use, and allows two Bluetooth devices within 10-100 m range to share data with throughput up to 723.2 Kbps, or 2.1Mbps with the new Enhanced Data Rate specification already released in 2005. Each device can simultaneously communicate with up to seven other devices per piconet.

Bluetooth technology is also intended to be secure by providing authentication, encryption, quality of service (QoS) control and other security features. However, it will be shown that Bluetooth is vulnerable in a number of ways, opening the door for many malicious attacks now and in the future.

The common uses of BT technology nowadays include:

• Using a wireless mobile phone headset during a call while keeping a phone in the bag
• Synchronizing a calendar, phone book and other information between a PDA and a PC
• Connecting a printer, keyboard, or mouse to a PC without cables
• Transferring photos or ring tones between mobile phones

The technology is also constantly being examined and updated in order to make it faster, more secure, and cheaper with additional functionality.

Bluetooth security features

Figure 1. Bluetooth option to be "discoverable" or not.

When a Bluetooth device is discoverable, it is very easy to scan for it using a PC and download private data, as we'll see later in this article. This approach can easily contribute to some high profile attacks on celebrities and famous people, who often do not understand the Bluetooth technology.

Setting Bluetooth to a "non-discoverable" mode prevents BT devices from appearing on the list during a BT device search process. However, it is still visible to those devices and users who are familiar with its Bluetooth MAC address, which would be the case for previously paired devices (devices that have communicated with each other at least once before).

Scanning for Bluetooth addresses

In theory, enabling the non-discoverable mode on a Bluetooth device should protect users from unauthorized connections, yet in practice it is still quite possible to find these devices. There are software tools available which allow brute-force discovery of non-discoverable devices. An example of such an application is RedFang by Ollie Whitehouse, a small application which simply tries to connect to a unique Bluetooth address one by one, until finally a hidden device answers the request sent that was sent to that particular address. Unfortunately this technique is still more of a proof of concept rather than a serious hacking tool. The main obstacle for making this brute forcing technique truly useful is the time required to fully probe one Bluetooth device, which based on the author's initial tests is a minimum of 6 seconds to achieve a good level of accuracy (it varies from 2.5 to 10 seconds, on average). It is certainly possible to find a hidden device in less than 3 seconds, yet we will most likely miss some devices and this will certainly have an impact on the accuracy of the scanning results. Let's try to put this into hard numbers. The address space used by Sony Ericsson has 16,777,216 possible addresses. If we assume 6 seconds are required per device, the total scan would take us 1165 days, meaning we would need more than 3 years to discover all hidden Sony Ericsson phones in a conference room. As we can see, this is much too long to make this approach useful for hackers. However, there are certain techniques could help us to discover a hidden device much faster.

The advantage hackers have is the simple fact that majority of Bluetooth devices (nearly all are mobile phones today) have bright blue LEDs on them which indicate if Bluetooth is enabled or not. If a hacker sees a mobile phone with a large blue diode and he cannot find such a device using the standard Bluetooth discovery process, then he can assume that the device has Bluetooth enabled but it is in non-discoverable mode. Based on that, hackers will know that the Bluetooth is enabled on particular device, assuming it is within eye contact, and also know the type of the device -- which could make the brute force BT address discovery process much simpler.

Reducing address possibilities

The time required to do a full Bluetooth address scan can be reduced not only by specifying the right target address space, but also by speeding up the scanning process. The current implementation of the RedFang (v.2.5) application allows the simultaneous use of multiple Bluetooth dongles for the scan process. If we use only 8 USB Bluetooth dongles and can benefit from the previously mentioned range of the Sony Ericsson P900 address space, we would most likely find all hidden SE P900 mobile phones within range within four and a half days. It's still a long time, but again we have to remember that the research on discovering Bluetooth non-discoverable devices is relatively new and thus there is a lot of room for improvement. More efficient techniques and scanning tools may emerge in the near future.

Discovering Bluetooth addresses during communication

The malicious hackers can also benefit from mobile phone owners who simply keep their Bluetooth devices in discoverable mode. This happens most often because one mobile phone is required to be in discoverable mode before pairing with a new device (the process of pairing will be described in the next section). Often device owners simply forget to disable the discoverable mode afterwards - it is very easy to do. Or more likely, they simply do not understand what discoverable mode is.

The need to be discoverable during the process of pairing with another Bluetooth device is actually a big advantage for hackers, since they can benefit from this short period of time when the device is discoverable and easily record the address. None of the mobile phones available on the market allow for the manual entry of a Bluetooth address for the pairing process, meaning that one device always has to be discovered during the communication. Since the device's Bluetooth address is static and can not be modified by users, it requires the attacker to find this address only once. Therefore, as you can see it only requires one short moment of being in discoverable mode for a hacker to be able to connect to that device before it is switched to non-discoverable, and the mobile phone user won't be able to block the connection. This is because changing of Bluetooth addresses is not possible, and a mobile phone always accepts a basic L2CAP connection request without acceptance of the user. Current mobile devices unfortunately do not provide functionality which could limit the basic low level L2CAP connection to a Bluetooth device, or block certain addresses. Simply put, a Bluetooth firewall is not available by default.

Bluetooth pairing methods & security

Figure 2. Authentication example during the Bluetooth pairing process.

Once users have entered their correct PIN codes, both devices will generate a link key, which can be stored in the device's memory and will allow it to skip the authentication and authorisation process every time it attempts to communicate with the other paired device in the future.

Vendor issues

To realize the scale of the vulnerability, just imagine what would happen if someone hacks your mobile phone and, using your phone, sends an SMS message with a bomb threat to the local police station. The billing records would certainly point directly to you as the phone owner and the real sender of the SMS, and it would be nearly possible to identify the real sender, since mobile phones usually do not keep logs of the Bluetooth activity. To make it worse, the vast majority of phones don't even keep copy of the SMS message which was sent via Bluetooth AT commands. Therefore, you would not even notice that an SMS message had been sent from your phone unless SMS status notification on your phone is turned on by default.

The aforementioned vulnerability affecting Nokia and Sony Ericsson phones is also trivial to exploit and does not require any special skills or modifications of the Bluetooth stack. In fact, every user experienced in using Bluetooth on Linux would find it trivial to exploit. Only two standard commands are required to steal the Phonebook information from a T610 mobile phone:

# hcitool scan
Scanning .

00:0A:D9:15:0B:1C T610-phone

# obexftp -b 00:0A:D9:15:0B:1C --channel 10 -g telecom/pb.vcf -v
Browsing 00:0A:D9:15:0B:1C ...
Channel: 7
No custom transport
Connecting...bt: 1
done
Receiving telecom/pb.vcf...\done
Disconnecting...done

That is all what it takes to steal the Phonebook information from an insecure T610 phone. Both the hcitool and obexftp commands are standard Bluetooth commands, typically available in any Linux distribution along with the standard Bluetooth package.

Note that this vulnerability was discovered by Adam Laurie and affects many handsets, including the Nokia 6310, 6310i, 8910, 8910i, Sony Ericsson T68, T68i, R520m, T610, Z600 and possibly others. The vulnerability was widely researched by the trifinite.group which provided a great deal of information about it on their web-site, and even developed an application called Blooover which exploits the vulnerability.

An update had been already provided from the vendors but a simple scan often reveals vulnerable headsets, for example in your local mall food court. It is not a surprise that some less advanced mobile phone users, those who only need to make a phone call or send an SMS, may not be aware of the need to update their phone's software. It is surprising however to see devices with such serious flaws appear on the market. A basic security audit of these devices during the manufacturer's testing phase, prior to release, would certainly have revealed this problem. It is clear that some mobile headset producers simply don't bother with security very much, and therefore much more serious vulnerabilities in the future can be expected.

Fake AP risk

Figure 3. Discovered devices do not display their Bluetooth address.

Since the Bluetooth device name (like "ULTOR" in the above example) can be easily modified by all users, it should not be used as a sole device identifier in the pairing process; the Bluetooth address should really be displayed and compared for additional verification. This small detail could be exploited in many ways, especially in public services provided through Bluetooth. For instance, the Bluetooth Internet Access point service could be attacked by installing a fake Bluetooth access point. The device would have a same name as a real access point, and would be configured to accept the same PIN and provide access to the Internet. However, all the data during the connection from the mobile phone to the Internet will be captured and analysed for the presence of passwords and sensitive information.

This attack may be also executed in an alternate way. In some countries there are special mobile kiosks installed which may send a ring tone or a mobile game to the user via Bluetooth. When a user has selected content he wants to be sent to his device, and by nature have the mobile phone listed on the Bluetooth discovery list, a Bluetooth device such as "MOBILE-KIOSK" connects to the mobile phone and sends the mobile game. There problem is that we are not actually sure that a "MOBILE-KIOSK" device connecting to our device is really the mobile kiosk we are currently using, since once again, on most mobile phones the kiosk's Bluetooth address won't be displayed. The device could just as well be as well a hacker who has named his Bluetooth laptop "MOBILE-KIOSK" and is sending us a mobile virus or a backdoor application. Certainly such attacks could be prevented by implementing a better authentication process, yet most existing kiosks have authentication poorly implemented and the PIN passkey is usually static.

Bluetooth social engineering

To test this theory, I named my laptop Bluetooth dongle to PIN1234, 1234 or PASS1234 (in several different tests) and simply tried to connect to any discovered Bluetooth devices within the foodcourt of one of of the biggest malls in Jakarta. Benefiting on the 200m range of my equipment, I was able to discover from 3 to 11 Bluetooth devices during lunch time, and had tried to connect to each of them. Surprisingly, an average of 1 in 10 tries had my connection accepted. The phone users simply read "PIN1234" as the name of device which was trying to connect to his/her handphone, and so the user types the 1234 PIN (passkey) to accept the connection. This could potentially allow me to retrieve their phonebook, send SMS messages from the attacked phones, or even read Inbox SMS messages through AT commands. I can add that 4 of the 10 tries were most likely ignored by the user who did not even notice the connection to the phone (the connection remained pending for 30 seconds), thus the success rate of this type of attack seams to be relatively high for the users who actually notice the Bluetooth connection attempt. It is also interesting that majority of users do not realise that by accepting the connection they may not only receive data but also allow data to be retrieved on the majority of Bluetooth enabled mobile phones.

Concluding part one