The potential danger associated to ZigBee IoT Devices

Background

Zigbee is an IEEE 802.15.4-based specification for a suite of high-level communication protocols used to create personal area networks with small, low-power digital radios, such as for home automation. Hence, Zigbee is a low-power, low data rate, and close proximity (i.e., personal area) wireless ad hoc network.

ZigBee uses “profiles” to permit different device type created by different manufacturers to exchange control messages interoperability. The most common profile found in our homes/offices is the ZigBee Home Automation Public Application Profile (0x0104).

Home Automation Profile

The Home Automation profile states that manufacturer has to implement the standard interfaces and practices of this profile if it wishes its device to be compatible to other certified devices from other manufacturers.

From a security standpoint, two attributes are of particular interest:

• Default Trust Center Link Key A.K.A Link Key is a 16-byte key with the following values 5A:69:67:42:65:65:41:6C:6C:69:61:6E:63:65:30:39. This 16 byte key value is defined by the ZigBee Alliance.
• Default Link Key Join. If the configuration is enabled, your ZigBee set up allows default link key join as a fall back case at startup time

Important facts about ZigBee Security

ZigBee setup may employ a number of different keys (AES-128bits). However, below are two main keys you should note for this article.

• Network Key - Used for network layer encryption and shared between every device on the network
• Link Key - Used to encrypt unicast messages and shared between two devices

The issue arises

In your ZigBee setup, the trust center is responsible for authenticating new nodes and distributing network keys to new nodes as they join the network. The network key is encrypted with the default trust center link key and transmitted over the network.

An attacker can be listening on the ZigBee channel to obtain the network key, resulting in potential replay attacks, command injections or/and even device takeover.

ZigBee network set-up

My personal recommendation to get started on this Proof-Of-Concept (POC) is the use of ZigBee2MQTT. The products listed are inexpensive to purchase.

In a separate post, I shared on how easy it is to use ZigBee2MQTT and Node-Red to automate your Smart home.

Sniffing ZigBee packets

A software tool that you can use to sniff ZigBee traffic is the ZigBee Open Source Stack (ZBOSS). All you will need is a CC 2531 hardware which can be purchased online for 5 USD.

I personally recommend this setup as I have tried using the RZUSBSTICK and KillerBee but it somehow always resulted in incomplete packets sniffed.

ZBOSS Sniffer Graphical User Interface

Sniffing the Network Key

If you’re on a black-box approach, you will have to first identify the ZigBee channel/frequency your target set up is running on. To do so, you can run tools from KillerBee, SecBee or Z3sec.

Running zbstumbler will provide essential information on surrounding ZigBee network

After identifying the channel, run ZBOSS and set the appropriate channel for it to be passively listening for any communications in the network. When Wireshark launches, insert the default trust center link key. (Under Edit -> Preferences -> Protocols -> ZigBee -> Edit)

Inserting the default trust center link key into Wireshark

When a device attempts to join the ZigBee setup, a sequence of communication takes place as seen in the flow chart below.

Join using a pre-configured trust center link key

In this POC , the following actions took place when a new device joins the network:

1. Joining device sends an association request, providing basic information of itself. (RFD refers to Reduced Function Device)
2. The trust center will return an association response, which contains the ZigBee PAN address and the device’s network address.
   The PAN is a 16 bit identifier selected at random by the coordinator when the network starts up and is used by the MAC layer to filter out packets that are not part of the same network.
   NwkAddr also called “short address”, is a 16-bit address that is unique within an individual ZigBee network. The NwkAddr is assigned when a device joins the network and can change if it leaves and re-joins the network.
3. The trust center will encrypt the network key using the default trust center link key. As seen from the image below (Step 3), the Network Key can be obtained by anyone who is listening on the ZigBee channel.

Step 1: Association request sent by joining device

Step 3: Network key in the clear

For completion purposes, the new node will then attempt to broadcast its network address & MAC address (Similar concept to MAC and IP addressing) to other nodes and uses the ZigBee Cluster Library (ZCL) to obtain information from the coordinator. The ZCL is also used to send home automation commands to on/off your smart light bulbs etc.

The impact when an attacker gains hold of the network key

An attacker without the network key was unable to view the commands that were previously sent on the channel.

Communications were encrypted as the network key was not indicated

Insert the network key obtained from the POC to view all network traffics in clear.

Insert the known network key into the Wireshark settings

After inserting the network key, all commands and communications were decrypted. As seen in packet 7 below, the ‘on’ command was sent from the coordinator (0x0000) to a ZigBee end device (0x7003).

Communication in the clear after inserting the network key

An attacker can study the network traffic and craft malicious payload to control your smart devices resulting in a full system compromise.

Below are some automated tools to perform further attacks (replay attacks, DDoS, device reset etc.) in which I will not be covering in this article:

• KillerBee
• SecBee
• Z3Sec

Likelihood of attack

This attack will work in any of the following scenarios:

1. When a new device is paired to the network and default trust center link key is used to encrypt the network key
2. When a new device is paired to the network and default link key join is set to true
3. When a device re-joins the network and the setup allows re-join using default trust center link keys

Even though the timeframe to exploit this vulnerability is very limited, bringing the user into play can easily circumvent this. For example, sending noise on the target ZigBee channel to prevent successful communication. A typical user would notice a lost connection and attempt to perform a re-pairing procedure to solve the issue. Targeting the user level allows an attacker to enforce a re-pairing and sniff the transmitted network key.

Recommendations for a more secured ZigBee setup

1. Using installation code instead of default trust center link keys provides security for the initial exchange of the network key to the device, at the cost of added interaction between the user and the trust center. A user must somehow transfer the key from the device to the trust center. This is accomplished by a mechanism outside of the ZigBee network, such as typing in the code into the trust center GUI from a label listing the code on the joining device
2. From Zigbee 3.0, devices are required to request an updated trust center link key after successfully joining. This will replace their existing preconfigured key and be used as long as they are joined to that network. Even if the device joined used an installation code key, that key will be replaced.
3. For rejoins, the well-known link key (zigbeealliance09 key) should not be accepted.
4. Make sure that your network set up does not allow new nodes to join the ZigBee setup. If there is a requirement, ensure that whitelisting of MAC address is set before pairing the new device to the network.