Bluetooth Hacking Primer

bt_hack_feat

2600 Issue 27:1

Foreword

I’m obsessed with Bluetooth. I’m not really sure why, but the technology and its application simply fascinates me. I’ve been working with various Bluetooth hardware and software for a few years now to understand more about it, and also document some of the possible security risks that are associated with its use. This is an area which, regrettably, doesn’t seem to get as much exposure as it should.

To try and help that situation a bit, I wrote “Bluetooth Hacking Primer“, which was published on page 54 of 2600 issue 27:1. This document is not a guide about actually attacking Bluetooth devices, but rather walks the reader through Bluetooth’s basic principles of operation, and touches on the hardware and software setup required to start doing security related research. Some simple attacks are mentioned at the end of the document to illustrate the realistic threat of Bluetooth devices, but it is not intended as a full documentation of those weaknesses.

Introduction

Originally conceived in 1994 by Ericsson, Bluetooth was set to revolutionize the computing and consumer electronics world. It promised to rid us of wires and provide a method by which all of our devices could communicate seamlessly. Unfortunately, early versions of the protocol were so beleaguered by problems that consumers were all too happy to keep their spider web of cables. Besides, most technology of the mid-ninety’s was not exactly designed with mobility in mind in the first place.
But today, Bluetooth has come back in a big way. Mobile technology has dominated this decade, and the need for a standardized method of low-power communication has never been greater. At the same time, newer versions of the Bluetooth protocol have all but eliminated the poor range, transfer rate, and interoperability issues that plagued earlier implementations. Bluetooth has now become so popular in the mass market that it has even attained a sort of brand association, to the point that most people simply refer to all wireless headsets as “a Bluetooth.”

However, with the resurgence of Bluetooth has come a dangerous, if predictable, complacency. Millions of people are now using the technology without any clear understanding of how it works and what it is capable of.

This article is not written as a hyper-technical look at the Bluetooth protocol, nor does it detail any one particular attack against Bluetooth devices. Instead, it is intended to give the reader some information on how Bluetooth works, what you can do with it, and the risks associated. Hopefully this article will give you enough information to start exploring Bluetooth and allow you to form your own opinions on the technology.

Low-Level Communication

Bluetooth operates in the ISM band between 2.4 and 2.4835 GHz, which is divided into 79 channels that are each 1 MHz wide. Connected Bluetooth devices hop channels at up to 1600 times per second in a pattern derived by the master device’s clock. By rapidly changing channels like this, Bluetooth devices are able to avoid interference with other devices in the 2.4 GHz band, such as WiFi networks and cordless telephones, and remain segmented from other Bluetooth networks in the area.

When one Bluetooth device wants to connect to another, it must go through a few steps to learn about and authenticate with the remote device. The eventual master device first scans the band to find other devices which are in so-called “discoverable” mode, and then preforms an inquiry on each one. This gives the device a list of hardware addresses (which are in the familiar MAC-48 format), human-friendly device names (which the owner of the device assigns, or more often than not, leaves as the default), device class IDs (to determine what the device actually is), and clock offsets (used in calculating channel hopping operations). This provides the master device with enough information to begin establishing an actual connection with one or more of the devices it found. The master sends out what is known as a frequency-hop synchronization (FHS) packet, which the slaves use to get locked on to the correct channels and start the authentication process.

While the Bluetooth protocol is a master/slave arrangement, there is a provision which allows for multiple devices to be connected together in what is known as a piconet. In a piconet, up to 8 Bluetooth devices can communicate simultaneously by timing their transmissions to fall on even or odd channel hops. The device currently marked as master can communicate with any of the slaves in the piconet, as well as add or remove devices from the network. It is also possible to connect multiple piconets together by having certain devices act as a master in one piconet and a slave in the other, which is referred to as a scatternet.

Even though only 8 devices can be active in the piconet, there can be up to 255 slaves waiting for their turn to be activated. In addition to the standard “Active” mode, a slave in a piconet can be in 3 modes: “Sniff”, “Hold”, and “Park”. Each of these modes involves progressively less data transmission and therefore lower power consumption (important on portable devices). Devices in these inactive modes still remain synchronized with the piconet master, but do not actively participate unless they are brought back to “Active” status.

High-Level Protocols

There are a few core protocols that all Bluetooth services make use of in some way or another. The most fundamental of these is the Logical Link Control and Adaptation Protocol (L2CAP), which could be thought of as the Bluetooth equivalent of TCP. L2CAP handles the creation, sequencing, and reassembling of packets, QoS, and the channel identifiers (CIDS). CIDS are like TCP ports, they are the endpoints between two devices through which processes can communicate. Like TCP, L2CAP also features a number of signalling commands which are used to control communication over the CIDS.

The next protocol is known as Radio Frequency Communication (RFCOMM). At it’s core, RFCOMM is designed as a replacement for RS-232 connections; anything that uses serial communications can be adapted to RFCOMM very easily. RFCOMM provides up to 60 emulated serial ports per device, which are usually referred to as RFCOMM channels. Bluetooth services bind to an open RFCOMM channel, and remote devices address that particular service with a combination of MAC and channel number.

The last major protocol you should be aware of is the Service Discovery Protocol (SDP). SDP is the method by which two Bluetooth devices can determine which services the other is running and how they would connect to them. Each SDP entry contains the name of the service, which protocols it relies on, and which RFCOMM channel it is bound to. With this information, the device can inform the user about the remote device’s capability, and internally store the channel and protocol information for later use.

On top of all of these protocols are the highest-level functions, which are provided by what are known as profiles or services. These applications are what the end user is actually interacting with when they send a picture to a phone or connect a headset. There are many Bluetooth services available, certainly more than I would want to list here, but the main ones would be things like Dial-up Networking (DUN), File Transfer Profile (FTP), Headset Profile (HSP), Object Push Profile (OPP), etc.


Tom Nardi

Tom is a Network Engineer with focus on GNU/Linux and open source software. He is a frequent submitter to "2600", and maintains a personal site of his projects and areas of research at: www.digifail.com .

Related posts

Top