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.

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.

Pairing Problems

I briefly discussed the fundamental protocols that work in conjunction with Bluetooth, like: LMP, L2CAP, SDP and RFCOMM.  I also touched up on  BD_ADDR, and NAP/UAP/LAP.  I went over other states BT devices within a piconet swap to, and hinted at the amount of enumeration we can glean from just OUI‘s and packets.  I will now go a step further and cover the pairing process involved between devices and note some of the problematic areas associated with them.  By the end of this part of the series, we should start to get a clearer understanding of why Bluetooth has raised so many security concerns.  

Let’s Make A Perfect Pair…
…Or a Perfect Pear

Many of us pair BT devices together all the time without actually thinking about how the process works.  It seems to be a riddle of questions no one wants to bother with.  Well, we know the BD_ADDR is public and establishes communication with devices and that various protocols work to make this happen, but let’s dive a little deeper because it’s almost summer and I like to swim.  A BD_ADDR master device (utilized by different states) gets what’s called a DAC, or Device Access Code, and a CAC, or Channel Access Code, which works as an identifier used in FHSS (Frequency-Hopping Spread-Spectrum).  It’s also transmitted in clear text (oops).  We can actually analyze the different ADDR states by these varying identifiers as a result.

Anyway, pairing can be trusted or non-trusted.  This means security is partially reliant on the vendor or app being paired.  However, the key exchange used for authentication and encryption between devices uses EO, a 128-bit key stream cipher that is problematic.  E0 uses four shift registers and two internal states that update before bits are extracted, added and used with an algorithm to obtain a sum.  Research into E0 turned up numerous problems and they go as far back as the late 90’s.  Even if you’re not a cryptography expert, we can gather this seems lax.  This is essentially why it is one of BT’s weakest links.

If you create a building without a good foundation, how long will it stand?

Pairing is a three part process where the establishment/initialization of a key is temporarily made for encryption/decryption processes.  The first BT device generates a random number and transmits it to a second device’s BD_ADDR’s random number, which generates this key.  This key then acts as a shared PIN and once it’s generated, a challenge-response is formed.  If both match, you have successful verification.  It also makes you wonder if the process could be intercepted because the second device just spits the same information back.

Let’s not worry about my random thoughts however and let’s focus on link key generation a little here, since it’s an important part of the pairing process.  I don’t want to make this complicated when it doesn’t need to be.  There are actually two key generation process types and the one used depends on whether or not either of the devices are limited by memory resources.  This is most likely for compatibility, but it also seems like it could be an issue.

Why Problematic?

Did you ask this?

If you did awesome (if you didn’t, you’re just going to have to pear with me).  It’s problematic because the key generation process changes and creates an even greater lack of complexity if the resources aren’t there.  If there’s a memory constraint, a key is encrypted with a cipher text and transmitted to the other device to be decrypted/used as a key.  If not though, these devices go through the random number generation process described in the paragraph above.  So we essentially forgo this random number generation if a device lacks resources.  By now, hopefully you’re asking yourself a lot of questions and finding some of these processes slightly awkward.

Security Modes

Bluetooth also has three security modes, creatively labeled 1, 2, and 3.  Mode 1 is simply no security (hmm…why is it called a security mode then?).  Any authentication/encryption can be bypassed.  Basically devices are open and can connect with others.  Mode 2 doesn’t initiate security before establishment on L2CAP, and it allows for different policies with apps (which have different requirements).  A security manager maintains access controls/interfaces with other protocols, and authentication and authorization are supported.  Lucky Mode 3 devices initiate security procedures before links are setup with LMP.  It isn’t aware of application layer security however, even though encryption is supported and a shared secret key link is gained in pairing.

So, looking at the psychological profile of BT mentioned in Part 1 and combining it with our knowledge here, we can tell there are a lot of issues with BT.  It also gives us an understanding of why we see so many devices and attacks it could be hit with.