Bluetooth Security Review, Part 1
by Marek Bialoglowy
Introduction to Bluetooth
Bluetooth (BT) wireless technology provides an easy way for a wide range of devices to communicate with each other and connect to the Internet without the need for wires, cables and connectors. It is supported and used in products by over 3000 companies, including large corporations such as Sony Ericsson, Nokia, Motorola, Intel, IBM, Toshiba, Motorola, Apple, Microsoft, and even Toyota, Lexus and BMW. A variety of products available on the market have short range Bluetooth radios installed, including printers, laptops, keyboards, cars and the most popular type of Bluetooth enabled devices - mobile phones, driving 60% of the Bluetooth market. The technology has already gained enormous popularity, with more than 3 million Bluetooth-enabled products shipping every week. According to IDC, there will be over 922 million Bluetooth enabled devices worldwide by 2008. The technology seams to be very interesting and beneficial, yet it can also be a high threat for the privacy and security of Bluetooth users.
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:
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
The most well-known and basic Bluetooth security mechanism is the user's ability to choose if a device is in "Discoverable" mode (visible to other devices) or "non-discoverable" mode, as shown on an example PDA below in Figure 1.
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
The Bluetooth address itself is a unique 48bit device identifier, where the first 3 bytes of the address are assigned to a specific manufacturer by the IEEE (www.ieee.org/), and the last 3 bytes are freely allocated by the manufacturer. For example, the hexadecimal representation of a Sony Ericsson P900 phone's Bluetooth address may look like 00:0A:D9:EB:66:C7, where the first 3 bytes of this address (00:0A:D9) are registered to Sony Ericsson by the IEEE, meaning that all P900 phones will have their Bluetooth address starting with same 3 bytes. The last 3 bytes (EB:66:C7) of the sample address are assigned to this device by Sony Ericsson and should be different for each P900 phone -- but is not always, unfortunately.
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
First of all, if the manufacturer of a device is known, the number of possible BT addresses is immediately limited to 16,777,216. Moreover, based on initial research some Bluetooth device manufacturers assign fairly predictable address ranges to particular models of devices. For instance, the address of the majority of Sony Ericsson P900 mobile phones out there seem to start with the 7 hex digits 00:0A:D9:E, meaning that only 5 remaining hex digits of an address are unknown. This reduces the search from more than 16 million addresses to only 1,048,576. Moreover, the fourth byte of the address of an SE P900 phone is actually very often in the more precise range of E7-EE, and therefore this reduces the number of possibilities to 524,288 - which means that while scanning for one address in an average of 6 seconds, the complete scan would be finished within 36 days. This is much less than the total scan of the Sony Ericsson address space which would otherwise take 1165 days, but it is still a relatively long period of time to make it at all useful for hackers. However, the research is still in progress, and thus it is still difficult for this author to precisely specify the address range for each model. Overall, it seems that most Nokia phones have a fairly random distribution of Bluetooth addresses, yet surprisingly, some P900 phones have been found to have the same Bluetooth address of 11:11:11:50:11:11!
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
Bluetooth addresses can also be extracted during Bluetooth communication, as the address itself is not encrypted even if user chooses to encrypt the rest of the communication. This is one of the major problems with the current Bluetooth specification. Frequency hopping (1600 hops / second) provides basic protection to the unencrypted Bluetooth device address during communication. However, the frequency hopping sequence used in Bluetooth technology is pseudo-random, meaning that a hacker with the proper equipment can synchronize to a pre-defined frequency hopping pattern used by two Bluetooth devices in communication. Additionally, the hopping sequence is also shared with all devices on the piconet, which may become the hacker's next advantage. Note that there are already devices available on the market that can capture Bluetooth communication from the air and analyze it, yet today the current price is still very high (approximately $9500 USD), thus it is not likely affordable for the majority of casual hackers.
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
A common task that involves Bluetooth security for most users is the "pairing" of devices. By default Bluetooth communication is not authenticated, and thus almost any device can freely connect to another. However, to access a particular service such as a dial-up account, a voice gateway, or to do a file transfer, some sort of authentication is usually required. The process of authentication is usually done during the pairing process by entering identical PIN codes (passkeys) on both devices, as shown below in Figure 2.
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.
Unfortunately for the Bluetooth users, the process of authentication and authorization to access services is not always correctly implemented by manufacturers. Such weaknesses already affect several Sony Ericsson and Nokia mobile phones, allowing malicious hacker to steal phone books, photos and calendar information, or allow the hacker to make a phone call or send an SMS using one's mobile. This is all due to the lack of authorization required for two important services.
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:
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
The process of pairing as implemented in most mobile phones also carries one other risk. The list of discovered Bluetooth devices on the mobile phone displays only the names of the located device, and it does not show the actual Bluetooth address, as shown in Figure 3.
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
As Bluetooth mobile phones are always used by humans, it is certainly possible to use social engineering techniques to attack them. The common lack of basic security awareness among phone users and general lack of understanding of Bluetooth technology is certainly an advantage for hackers. One of the tests which I performed for the purpose of this article clearly proved that social engineering attacks on Bluetooth are possible.
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
In this article we've introduced Bluetooth and the most common security issues that exist with these devices, including social engineering. Next time in part two, we'll offer an unpublished vulnerability in one vendor's Bluetooth phone as an example vector for an attack. Then we will look at Bluetooth antennas and range extenders, discuss how Bluetooth can be used to track one's position, and examine recent worm outbreaks that propagate via Bluetooth so that we can analyze their threat. Stay tuned.
About the author
Marek Bialoglowy is an independent IT Security Researcher from Poland who provides information security advisory and training services to private enterprises and government in Indonesia and Singapore. He has discovered several critical security vulnerabilities appearing on the SANS/FBI TOP 20 Vulnerabilities list, including one of the first critical vulnerabilities in Windows 2003.
This article originally appeared on SecurityFocus.com -- reproduction in whole or in part is not allowed without expressed written consent.