Understanding ZigBee Communication

In discussing the underlying concepts in ZigBee networking, it is important to also understand the addressing mode in ZigBee. A ZigBee device would have two addresses—one from 802.15 standards, which is a globally unique 64-bit number, one that is a 16-bit NWK address.

However, to send a broadcast, all a device needs to do is send a broadcast packet to the address 0xFFFF, which would be received by all the devices present on the ZigBee network.

Another thing that will be useful once we are exploiting ZigBee devices is the knowledge of channels used in ZigBee communications. There are a total of 16 channels used in ZigBee devices, so as we move forward into sniffing ZigBee channels, we would first need to figure out which channel the device is operating on and then capture ZigBee packets on that specific channel.

Hardware for ZigBee

A typical ZigBee hardware radio contains a combination of digital logic circuitry with analog circuits. One of the popular ZigBee modules, which you can also use to perform your initial security research, is the XBee module by Digi, shown in Figure 10-2.

ZigBee Security

Just like any other communication medium, there are a number of security issues that are possible with ZigBee, such as the ability to capture and intercept communication, replay packets, jam signals, and more. We will be looking into some of these security issues later in this chapter, but before we do that, we need to get ourselves a working setup to perform ZigBee exploitation.

Setting Up XBee

The first thing that we start with is programming an XBee with our corresponding channel and PAN ID. For this, we will use XCTU, which is a software tool to configure XBee devices, and an XBee explorer (or an XBee adapter), which is an adapter for XBee modules that can be plugged into our system. To get started, simply place the XBee module on the XBee adapter and connect it using a mini USB cable to your system.

The next step is to fire up XCTU and click Search Radio Modules as shown in Figure 10-3.

XCTU then asks which interface to scan for radio modules, as shown in Figure 10-4.

You can keep the configurations as shown in Figure 10-5—which is searching for the radio modules at the baud rate of 2400 and 9600, 8 data bits, no parity bit, and one stop bit (8N1). Click Finish once you have selected the configuration and XCTU will start scanning for all the radio modules.

As you can see in Figure 10-6, we have identified an XCTU module.

Click Add Selected Devices and you’ll be able to see the radio module now added to the XCTU workspace. You will be able to change various properties of the XBee module as shown in Figure 10-7.

For this, set the channel to 16 and leave the other parameters unchanged, then save the configuration. This is how we can set up our XBee module in the desired configuration.

Creating a Vulnerable ZigBee Setup

Now that we have our XBee configured, the next thing that we need to do is use an XBee shield with Arduino and our programmed XBee module plugged in. Figure 10-8 shows an XBee shield, which has an interface to connect Arduino and XBee.

For this, we need to first program our Arduino with the code shown in Figure 10-9, which is an authentication program where the authentication happens over the ZigBee network. The complete code is given in the Downloads bundle for this book.

Once we have flashed the Arduino with our vulnerable program, we are ready to plug everything in and start with our initial security analysis.

Introduction to KillerBee

Now that we have our vulnerable setup, the next step is to attack the target setup and perform radio-based attacks. For these purposes, we use a tool called KillerBee, which is an open source tool developed by RiverLoop Security to help assess and exploit ZigBee-based devices.

KillerBee supports a number of various hardware devices such as Atmel RzRaven USB Stick, APIMote, MoteIV Tmote Sky, TelosB mote, and Sewino Sniffer. For our current exercises and entire ZigBee exploitation, we use the Atmel RzRaven USB Stick, displayed in Figure 10-10.

Before you start assessing ZigBee-based devices with KillerBee and RzRaven, the first step would be to flash the KillerBee firmware onto the RzRaven USB stick using AVR Dragon over JTAG interface . You can also get preflashed RzRaven sniffers ready to use from attify-store.com.

Once we have flashed the RzRaven USB stick, the next step is to download and set up KillerBee on our local system as shown in Listing 10-1.

# apt-get install python-gtk2 python-cairo python-usb python-crypto python-serial python-dev libgcrypt-dev

# hg clone https://bitbucket.org/secdev/scapy-com

# cd scapy-com

# python setup.py install

Listing 10-1

Setting Up KillerBee

The next step is to go to the killerbee/tools folder and run the zbid utility . Make sure your RzRaven USB stick is plugged in, and you should see the RzRaven device with an ID of all Fs, as shown in Figure 10-11.

In case of an APIMote instead of RzRaven, you will see the device listed as GoodFET, as shown in Figure 10-12, instead of KillerBee.

The next step in any ZigBee security assessment is determining the channel of our target device. This can be done using another utility in the KillerBee tool suite called zbstumbler . Make sure to run zbstumbler with the –v flag to ensure that you get verbose messages, as in some cases when the packets detected by zbstumbler are not in the proper ZigBee packet format, it won’t show it on the terminal without the verbose flag.

To identify the channel being used by a ZigBee device, we need to look for the keyword Received Frame while running zbstumbler in verbose (-v flag) mode. As you can see in Figure 10-13, we have identified our target ZigBee setup on channel 20 in this case.

Sniffing ZigBee Packets

The next thing we can do is to capture all the packets using zbdump . This can be done by specifying the channel identified in Figure 10-13.

During this step, we try authenticating with our target device by entering the password in the serial monitor (Figure 10-15).

Once we have captured the packets, we can run strings on it and we will be able to see the strings that we mentioned in the Arduino program, as expected (see Figure 10-16).

We can also, instead of capturing packets to a dump file, sniff them actively using zbwireshark, and by specifying the channel ID on which you want to capture the packets. As you just saw, we were able to identify the channel ID of the ZigBee device and sniff the packets on that channel revealing our clear-text traffic.

Replaying ZigBee Packets

One of the other interesting things one could do with ZigBee communication is to perform replay-based attacks. This is extremely straightforward, as you would expect.

First, we need to capture the packets while a user is legitimately controlling the device. In this case, our target device is a Philips Hue Smart Hub and the connected light bulb. To perform this capture, we use the Attify ZigBee Framework, which is a GUI toolkit built on top of KillerBee.

To do this, you will need to specify the channel on which you want to perform the capture, the number of packets to capture, and the file in which the packets need to be stored, as shown in Figure 10-17.

During the sniffing period, we perform actions from the mobile application to control the Philips Hue smart light bulb, such as changing colors and turning it on and off.

Once we have captured the packets, the next step is to simply replay the packets. As we replay the packets, you would see the bulb being controlled without any user interaction and without the requirement of any authorization. This is also shown in Figure 10-18.

We are able to control the ZigBee-enabled smart device by replaying packets because the CRC verification mechanism was not implemented.

This is all for the attacks on ZigBee here. As you can imagine, though, there are a number of additional attack vectors that you can now perform with the knowledge of foundational techniques used for exploitation.

BLE Internals and Association

Before jumping into BLE security and the various exploitation techniques, let’s have a look at some of the BLE internals, so that we have a greater in-depth understanding of the foundational concepts when we are working with BLE-based IoT devices. Figure 10-19 shows the BLE stack structure.

As you can see from Figure 10-19, the BLE stack consists of two different layers—Host and Controller—bound via the Host Controller Interface (HCI). All the different components in various layers perform their own functionality; for example, the Physical layer is responsible for all the modulation and demodulation of the signals; the Link layer handles CRC generation, encryption, and defining how devices communicate with each other; and the Logical Link Control and Adaption Protocol (L2CAP) takes multiple data formats from the upper layers and puts them into a BLE packet structure.

At the very top of the BLE stack, inside the Host layer, you will notice a couple of more interesting components such as Attribute Protocol (ATT), Generic Attribute Profile (GATT), and Generic Access Profile (GAP).

So as you can imagine, it will be GATT (or ATT) that we are mostly concerned with during our further security research journey. As we go deep inside a BLE connection, it is also vital to understand how all of the data are stored on a device in a BLE connection. This is better illustrated in Figure 10-20.

Inside any BLE device, there can be a number of profiles, each of which will have different services. Services are a collection of characteristics (which we will come to in a while) or in layman’s terms, just a collection of information of a related nature. Services in this case could be anything that is defined by the Bluetooth SIG such as heart rate, blood pressure, alarm level, and so on. BLE developers are free to choose from one of the services defined by the Bluetooth SIG ( https://www.bluetooth.com/specifications/gatt/services ) or create their own.

Moving further in Figure 10-20, we have various characteristics that have a value and a descriptor. Characteristics are the actual values that are stored for a given service. As you can probably imagine here, it is the characteristics that we are interested in sniffing, reading, and modifying to exploit a given IoT device.

Now that we are familiar with the underlying concept of BLE internals, let’s have a quick look at what a typical authentication process looks like in BLE.

Figure 10-21 shows a representation of how BLE association and communication happens in IoT devices.

Interacting with BLE Devices

Now that we understand the BLE architecture and how devices communicate, let’s go a step further and see it in action. Figure 10-22 shows our setup for this section.

In this section, we interact with a BLE beacon and look at the various characteristics that are stored in the beacon. For this, we use a BLE adapter dongle and a utility called Gatttool.

Plug in the BLE dongle inside your system; if you are using a VM, make sure it is detected by the VM. You can verify it by using the command hciconfig, which should show an hci interface if the BLE dongle is successfully connected.

As you can see from Figure 10-23, we have a BLE adapter dongle connected with the Bluetooth Address (BD_ADDR) of 78:4F:43:55:A2:31.

Once we have connected the adapter, the next step is to search for BLE devices around us. We can use either the hcitool utility for this, or other open source projects such as Blue Hydra. Here we use hcitool’s lescan functionality to scan for nearby BLE devices.

As you can see in Figure 10-24, we have a couple of BLE devices nearby, such as the LEDBlue smart light bulb, UNI-LOCK smart lock, and a few other devices for which names have not been resolved.

In this case, our beacon is with the address 0C:F3:EE:0E:19:97, which we can now connect with. We launch Gatttool using the additional flag of –I to launch in an interactive mode and –b providing the BD_ADDR of the target device, as shown in Figure 10-25. Once you’re at the Gatttool prompt, type connect to connect to the target device (see Figure 10-25).

At this point, as shown in Figure 10-26, we can do primary services discovery and list all the various characteristics of the target device, which in this case is a beacon.

Let’s try to read one of the characteristics here—0x000c—using char-read-hnd, also shown in Figure 10-27.

If we go ahead and decode this as ASCII hex, we get the actual name that we have given to the beacon, in this case, testname, as shown in Figure 10-28.

We can also try reading other handles such as 0x0014, which contains the hex string shown in Figure 10-29.

Again, if we decode this, we get to see that this contains the URL wth which we have configured the beacon as shown in Figure 10-30.

Let’s try this on another beacon—iTag. As earlier, the first step would be to find out the BD_ADDR of our target device using the lescan functionality of hcitool, as shown in Figure 10-31.

In this case, our beacon has the address 20:CD:39:A8:3E:1E as shown in Figure 10-31.

Next, let’s go ahead and find out all the services that are present in this beacon using the primary command. As shown in Figure 10-32, it now lists all the services running on the target device along with attr handle, grp handle, and UUIDs. With the help of the first part of Universally Unique Identifier (UUID), we can also determine the service it relates to.

For example, for a UUID value of 00002800-0000-1000-8000-00805f9b34fb, the value 00002800 indicates that this is a GATT primary service.

In the case of this specific beacon, it is designed in such a way that during the normal operational state, the beacon stays connected to the device in all instances, but only for around five seconds. After that it disconnects and tries to connect again. This functionality allows users to tag this beacon to their valuables and makes sure they are not leaving the valuable item behind. This works on the principle that if the mobile application is not able to connect to the beacon every five seconds, the item is far away from the user. Let’s see if by modifying the properties of the beacon we are able to change this condition and make it stay connected all of the time.

If we look up the Bluetooth SIG web site mentioning the different UUIDs and their use cases at https://www.bluetooth.com/specifications/gatt/services , we see that UUID 0xfff0 is not one of the services defined by Bluetooth SIG. Let’s have a look at the handle for that particular UUID, and see if we find anything useful.

If we look at Figure 10-33, we can see the complete list of handles for UUID 0xff0 using the command char-desc.

If we relate this to what has been defined by the Bluetooth SIG, we see that the service 0xfff1 to 0xfff7 is defined by the manufacturers, and the others are services adopted by the Bluetooth SIG such as primary service, characteristic, characteristic user description, and so on.

Let’s finally go ahead and read the handle 0x0023 using the command char-read-hnd 0x0023. As shown in Figure 10-34, the current value in that handle is 03.

We can also change this value to something like 01, as shown in Figure 10-35.

On the device side now, the device no longer disconnects every five seconds and an attacker can now steal the valuable item attached to the beacon without the user getting a notification that this valuable item is missing.

In our current device itself, the beacon that we are using has a sound buzzer. This buzzer gets triggered whenever the device is not close to the pairing device. This is another potential attack surface that we can try exploiting.

In the following steps, we take a deeper look at the buzzer functionality, the current value of the characteristic, and how we can modify the value to trigger the buzzer as per desire. Let’s again go ahead and have a look at the primary services in Figure 10-36.

If we look up the Bluetooth SIG documentation online for the BLE GATT services available at https://www.bluetooth.com/specifications/gatt/services , we find that the UUID 00001802 is an immediate alert service, which is something of interest to us.

If you look at the output of the preceding command, the UUID 00001802 corresponds to the attr handle 0x0038. Let’s now go ahead and expand the handles of this particular UUID.

We can use the char-desc command to expand any given UUID as shown in Figure 10-37.

As we can see from Figure 10-38, the current value of the handle 0x003a is 00.

We can write our own data to this handle using char-write-req, as shown in Figure 10-39, and make it 01.

As soon as we do this, the beacon starts making a loud buzzing sound, which was our goal.

In this section, we were able to dig deep into various devices using BLE and explore how the entire BLE stack was laid out. We were also able to read and modify data that changed the behavior of the target device.

Exploiting a Smart Bulb Using BLE

Now that we know how to work with basic BLE devices, and read and modify data, let’s move to more complicated real-world IoT devices using BLE. In this case, we will use a BLE-enabled smart light bulb. The goal of this exercise is to control the light bulb without any authentication required whatsoever.

The first step, as in all the cases, is to determine the BD_ADDR, which is the Bluetooth address of the target device. We can again find this using hcitool lescan as shown in Figure 10-40.

Our smart bulb in this case has the Bluetooth address of 88:C2:55:CA:E9:4A. Now before we jump into Gatttool and modify the handles to change the behavior of the device, we need to know what properties to change.

This is easier if the device has defined its various characteristics as per the Bluetooth SIG, but in cases where it is custom implemented, the only option left is to sniff the BLE traffic and figure out what the handles being written in the normal operation are, and write those handle values manually.

Sniffing BLE Packets

To sniff BLE packets, you can use various devices such as the Ubertooth One or the Adafruit BLE Sniffer. For our exercise purposes, we use the Ubertooth One by GreatScottGadgets.

Setting up Ubertooth is straightforward and can be done by following the instructions on the Ubertooth wiki located at https://github.com/greatscottgadgets/ubertooth/wiki/Building-from-git .

Once everything is installed, we use the utility ubertooth-btle to sniff BLE packets. The additional flags that we use are –f to follow the connections (because of channel hopping) and -t to specify the BD_ADDR of the target device, which in this case is 88:C2:55:CA:E9:4A. Once you run this, you will see the packets on the screen shown in Figure 10-41.

If you also look further into the scanning process, you will see what is shown in Figure 10-42.

If you look at Figure 10-42, it has both the scan response (SCAN_RSP) from the target device and scan request (SCAN_REQ) from the mobile application communicating with the smart light bulb.

As we discussed in the very first sections regarding BLE, you will also see CONNECT_REQ packets as shown in Figure 10-43.

Let’s open the captured file in Wireshark. Figure 10-44 is what we see. If you are not able to see proper packets, make sure you are using the latest version of Wireshark with the DLT_USER (in Preferences | Protocols) set to btle.

Because there are a lot of packets during the entire network communication, let’s filter out the packets that are of interest to us. In the top bar, which says Apply a display filter, type btl2cap.cid==0x004. If we look at the packets now in Figure 10-45, we see that there are only ATT packets with interesting information.

During the packet capturing process, I changed the color of the light bulb, so let’s look for write packets in the Wireshark packet list. As we can see in Figure 10-45, the packet number 337 has the Write Request.

As we can see in Figure 10-46, the data are being written to the handle 0x0012. Let’s dissect this a step further and look into the packet details for this specific packet.

While actually working on this exercise, if we perform the changing of colors a number of times, we notice that the value actually follows a specific pattern, which is shown in Figure 10-47.

This is how we can take control of a given BLE device using techniques such as sniffing and manually writing the value of the BLE devices.

Exploiting a BLE Smart Lock

In some cases, there might be two writes required to take control of the target device—the first one being the authentication, and the next one being the actual data that need to be written.

Let’s take a smart lock for example. If we capture the packets during the normal lock and unlock process and look at Wireshark for the captured packets, Figure 10-48 is what we see. Therefore, in exploiting the device with Gatttool, we first need to pass it the authentication data, which we were able to sniff in this case, because they were being passed in clear text on an insecure BLE channel.

Next, we simply write the value that determines whether the lock is locked or unlocked, as shown in Figure 10-49.

Now, if you check the smart lock, it has been unlocked. This was all about sniffing BLE packets and manipulating them using Gatttool, both for basic devices and for complex real-world devices such as a smart lock and a smart light bulb.

Replaying BLE Packets

One of the additional things you can try is using tools such as BTLEJuice, which is an excellent handy utility for performing processed such as replay-based attacks. What follows is a demonstration of how to use the tool.

The first step is to connect the target device from the BTLEJuice web interface, shown in Figure 10-50.

Now, as we start performing actions in the smart light bulb, we will be able to see traffic in the BTLEJuice interface in the Data section along with a specific column mentioning the characteristic that’s being read or written, the service value, and the action that is taking place, as shown in Figure 10-51.

You can right-click any particular data packet and select Replay as shown in Figure 10-52.

This opens a dialog box mentioning the data that are being replayed, and if you want to perform any changes in the data that are replayed. You can change the RGB values and on/off toggle bit here.

Once you click Write (see Figure 10-53), you will see that the bulb’s color has changed or the bulb has turned on or off, depending on what data you wrote.