Thanks to cell phone driving laws and the desire for more convenience, Bluetooth has become a technology so common that it's part of our daily lives. It's a safe bet that at least some of your customers use Bluetooth to conduct business while driving or walking.
Most Bluetooth users are unaware of the dangers associated with the technology. Brad Haines, author of Seven Deadliest Wireless Technologies Attacks, outlines one such danger:
Imagine a commuter is traveling home by train every night. As he or she walks through the train station, he or she is concerned about getting home in time for dinner, not about getting scammed via the phone in his or her pocket. An attacker is sitting near the waiting area, scanning the air for advertising Bluetooth devices. He or she spots the phone in our commuter’s pocket and due to poor security choices is able to connect to it with a common or default PIN code. From there, the attacker instructs the phone to silently call out to a number, which stays connected until the commuter notices the phone call and dismisses it as accidental or the call is interrupted from a dead battery or service interruption. The attacker makes his or her money 1 month later when the commuter’s cell phone bill arrives. The number called was a premium rate line owned by the attacker that charges a high cost per minute ($3.99 or some such number). The victim’s phone called the number and incurred charges by the minute on his or her way home for the night. Over a 45-min train ride, that charge can grow to hundreds of dollars that goes into the attacker’s pocket.
Adapted from Seven Deadliest Wireless Technologies Attacks (Syngress)
By Brad Haines
With the widespread adoption and convenience of Bluetooth device comes the inevitable implementation problems that cause unexpected things to happen.
Most Bluetooth-based attacks are based on a simple and common flaw. Users often are very poor at reading documentation, at understanding risks and threats, and generally at changing defaults. Most attacks revolve around users not changing the default settings on their devices. That, coupled with poor user interface (UI) design, creates situations where users are unaware something bad is happening or about to happen. As well, documentation until recently did not fully explain the risks of certain actions.
Bluetooth Discovery
As with most attacks, the first thing to do is to find a target. Most often, Bluetooth attacks are against targets of opportunity (that is, not targeted). In the case of Bluetooth, its design assumes that devices interact with one another occasionally (that is the whole point of the technology). The need for these devices to find one another easily is a requirement of this. This allows legitimate users to find the device they are seeking, but also allows a nearby attacker to find those same devices and silently interrogate them to find out if they are suitable to attack.
The Bluetooth discovery process involves both parties in the pairing process. A device seeking to connect sends out a broadcast to the immediate area. Devices in the area, if they are set to be discoverable, then respond with the BD_ADDR of the device. From there, the querying device can use the SDP to discover all the profiles (that is, services) the device is offering (and vice versa). Simply put, a cell phone sends out a query, the headset responds saying it supports the hands-free profile, and the cell phone now knows to treat this remote device as a headset and not a dial-up adapter or some other profile.
Most cell phones, PDAs, or other Bluetooth devices have the capability to scan for discoverable devices. Even with this very simple interface, you can glean some Hacking Bluetooth 47 interesting information. Many phones by default have the make and model of the phone listed as the name of the device when queried in a scan. This automatically makes life easier for attackers because they can immediately see what device it is and determine if there are any specific procedures needed to do bad things to it. Alternatively, when people do change the default settings, they very often change them to their name or some other very easy identifier like “Bob’s phone” or “Alice’s Blackberry.” If an attacker is specifically looking to target Bob, then Bob has made his phone obvious among the others detectable in range and thus an easier-to-find target. By the same token, if the attacker knows Bob has a Nokia phone and sees only one device named Nokia 6330, then it’s pretty obvious which one is Bob’s.
The BD_ADDR, much like MAC addresses for network cards, has a known format to follow. They are 48-bit identifiers in a HEX format. The first 3 bytes are assigned to specific manufacturers. Like MAC addresses for network cards, the Institute of Electrical and Electronics Engineers (IEEE) assigns blocks of addresses to manufacturers to embed in their devices. The last 3 bytes are the unique address of the device. Since the assigned addresses are public, if the device name is not helpful, the BD_ADDR is not hidden and can be used to determine manufacturer. Anyone can query the OUI database and see what manufacturer made the device and adjust your attack accordingly. The IEEE has a query page up at http://standards.ieee.org/regauth/oui/index.shtml, and you can also download a copy of the whole database for integration into your own application or for local lookup.
Applications like BTscanner for Linux or Windows (http://www.pentest.co.uk/cgi-bin/ viewcat.cgi?cat=downloads) or Bluescanner for Windows (https://labs.arubanetworks. com/) can automate the process of scanning for devices, interrogating and cataloging the results. This allows attackers to sit and observe the results much like Kismet (http://www.kismetwireless.net) and Netstumbler (http://www.netstumbler.com/downloads/) did with Wi-Fi networks.
There have been several projects over the years to quantify the number of Bluetooth devices in any given area. In early 2006, F-secure along with secure networks created the Bluebag, a mobile Bluetooth detecting rig including nine Bluetooth adapters built into a hard-sided wheeled suitcase. They wheeled the case through airports, shopping malls, and even a security conference. In 23 h of scanning at various locations, they discovered 1405 unique discoverable devices, many of 48 CHAPTER 3 Bluetooth Attacks which were advertising various profiles such as OBEX file transfer and headset capabilities. These devices may be susceptible to various attacks. The final report is interesting reading and is available at http://www.securenetwork.it/bluebag_brochure.pdf.
Another project to catalog Bluetooth devices has been going on since 2007 in the Netherlands. The Bluetooth tracking project has set up multiple sensors in various parts of the Netherlands and even Paris, France, that continually monitor for discoverable devices and record the information in a database. Since then, they have collected over 600,000 devices and generated some interesting usage statistics. They also have been able to calculate the speed at which a device is moving. One sensor detects a device, another a few miles away detects it again – from that you can extrapolate the speed at which someone was moving and what direction.
Some devices, as a security measure, do not respond to probes or only have limited window of time where the device is discoverable. These devices can cause a bit of a problem for the attacker; however, they are not impossible to detect with a little coercion and brute force.
Devices made nondiscoverable still can connect to other devices, except that the other device needs to know the BD_ADDR. If Alice wants to connect to Bob and Bob’s phone is not discoverable, Alice needs to know Bob’s BD_ADDR before she can connect. If she does not know it, Bob needs to make his device discoverable or tell Alice his device’s BD_ADDR, and she can enter it (if possible) to specify what to connect to. When Bob’s phone sees a directed request to connect to its address, it allows the connection to continue.
From an attacker’s perspective, this makes it much harder to attack Bob’s phone since it won’t respond unless the attacker knows the BD_ADDR. It’s unlikely Bob would share that with just anyone, but by using some basic information, we can potentially find out Bob’s BD_ADDR.
Programs like Redfang written by Ollie Whitehouse allow you to force connection requests through a particular address space. If we know Bob’s phone make and model, we can either scan a similar model to determine its address range or search the IEEE database or BNAP database for that manufacturer known addresses. This will get us the likely first 3 bytes of the address. The remaining bytes will have to be brute forced sequentially until a response is received from Bob’s phone. Since each query can take around 10 s to be thorough in waiting for a response, the process can take a while, from minutes to days depending on the type of device and the address space being searched.
NOTE: While manufacturers are assigned addresses in blocks that can contain millions of device addresses, that doesn’t mean that all of them are used in the real world. Manufacturers may only use a few hundred thousand and then move on. The BNAP project aims to collect device addresses and see what actual manufacturer prefixes are in use. This greatly reduces the number of possibilities if we are searching address space since we can eliminate addresses not in use. The BNAP project’s list of address prefixes and the manufacturers are available at http://802.15ninja.net/bnapbnap/.
©2011 Elsevier, Inc. All rights reserved. Printed with permission from Syngress, a division of Elsevier. Copyright 2011. "Seven Deadliest Wireless Technologies Attacks" by Brad Haines. For more information on this title and other similar books, please visit elsevierdirect.com.
