Part 1: A Brief History of BT

With the re-emergence of popularity in both vendor and client Bluetooth usage, along with the release of BlueBorne, I thought I would write a post that provides readers with a little bit of a better understanding of the fundamental workings and flaws used with the technology.  This post was personally picked as a subject of interest by Pirate Moo blog readers and friends, and will later be used to provide an analysis of subjects of interest chosen by users.  I will be adding to these posts as part of a series.

A Brief History Not of Time…
                                                 …but Bluetooth

Originally created as an RS-232 cable alternative, Bluetooth was developed by Tord Wingren/Jaap Haartsen/Sven Mattison, under Nils Rydneck/Johan Ullman.  The logo famously loved and hated, is actually a bind rune given with the idea that it would become a universal standard that brought all communication protocols together (nope!).  Jim Kardach coined the name, reading about King Harald Blatand’s endeavors as a ruler, using the HB initials.

Bluetooth is a WPAN (Wireless Personal Area Network) specification that operates in the 2.400 – 2.4835 GHz ISM band range using FHSS (Frequency-Hopping Spread Spectrum ) and AFH (Adaptive Frequency Hopping).

While spectrum modulations are important, it should be noted that AFH works through device adaptation within given environments.  It seeks areas of interference, so it doesn’t operate in them, so lessens such problems for 802.15 WPAN devices/802.11 WLANs.  Spread-Spectrum technology, uses lower power over a wider range of frequency while information is generated and modulated across air through RF signals, if both the modulation/spread spectrum type are the same.  The dwell time (lingering frequency), is combined with constant patterns provided by frequency changes, or hops (the US FCC dwell time value sits at 400ms and BT typically allows for data transfer rates of 1-2Mbps).

What Makes Bluetooth Work?

Bluetooth is a circuit/packet switching technology that allows asynchronous data channels and a few simultaneous voice ones.  It works with both point-to-point (only two) and point-to-multipoint (more than two) links.  The asynchronous connection-oriented packets work with point-to-multipoint are re-transmitted for integrity, while synchronous connection-less, or point-to-point links, don’t deal with this.  Devices sharing the same channel form an ad hoc network within the same physical channel known as a piconet.  Piconets help create links between users/devices, while utilizing a synchronization clock/hopping sequence in a master/slave relationship.

A little more on protocols…

There are a few protocols used in conjunction with Bluetooth, which gives what I would call a psychological profile of the problems and challenges faced.  Lets go over them real fast.

Link Manager is mainly used to to setup links, maintain security, and control piconets through pairing.  It also handles challenge-response authentication, and messages transferred in payloads.  On the receiving end, LM filters messages that have priority over user data, which can be delayed by a high re-transmissions of packets, which makes it susceptible to Denial of Service attacks.  The Logical Link Control/Adaptation Layer works on layer two of the OSI model (Data Link) and is placed over the baseband of BT.  It’s both connection-oriented (synchronous) and connection-less (asynchronous) for upper layer multiplexing.  It also handles segmentation/reassembly and works to interface with other protocols like SDP/RFCOMM.

Service Discovery allows devices to …you guessed it…discover services available within RF proximity of other BT devices.  This can be problematic and causes a few attack types that we’ll see later on in this series.  Meanwhile, RFCOMM gives the serial port emulation BT was originally designed for.  It can utilize 9 circuits of RS-232 ports, while working over L2CAP.

So now that we covered the underpinnings of BT a little bit, let’s talk about the BT Device Address (BD_ADDR), because this is where a majority of problems start to come into play.  The BT Device Address is a 48-bit identifier, whose first 3 bytes are associated with vendors (NAP/UAP), while the last byte provides the unique address of the device.  The IEEE provides information about which vendors use which addresses in devices.  This means we can enumerate information through OUI’s (organizationally unique identifier) simply by going to sites like IEEE and MACvendors.  You can also use a hacked up bash script I put on Git, if you want something offhand for whatever purposes.  There are technically a few different parts of BD_ADDR you should get acquainted with, because in deeper study, they actually become relatively important to decoding BT packets.  The NAP, UAP, LAP.  NAP, or Non-Significant Address (Part) makes the OUI portion of the address mentioned earlier, while the Upper Address makes the last byte, leaving us with the Lower Address that transmits with every packet header.

+------+-------+-----+
| NAP  | UAP  | LAP |
+–-----+------+------+
-ID PORTION-


There are a few things of some importance here.  Because BD_ADDR is publicly known, it can be obtained by ANY BT device because it’s used for communication establishment.  This means various targeted attacks can use a device’s BD_ADDR to either obtain information, or connect to a device (yikes!).  This gets a little more icky when you look into connectable modes, because they respond to messages from already found BT devices (which I’ll get into later on).

There are also three other address types that can be assigned other then BD_ADDR though, which I’ll cover really fast.  The AM_ADDR, or Active Member (Address) ID’s active communications between piconet members and is used in both slave/master packets, while PM_ADDR, or Park Mode, is an 8 bit address of a slave within a piconet, that is allocated by the master to be separated from (so basically the master picks a slave that’s not in active communication and it’s swapped to PM).   Once the slave becomes active, it swaps to AM.  That’s where AR_ADDR, or Access Request comes in.  It’s used by the PM to determine slave/master access assigned to slaves when they enter a PM state.  People tend to focus on BD_ADDR because it can enumerate the most information and while UAP’s help to figure out hopping sequences, PM and AM are actually distinctive in their own right because it essentially controls device behavior.

In the next part of these posts, I will go a little into about how pairing works and the problems that revolve around it.