Mobile, Embedded, & Wireless Security

Zigator: Security Analysis Tool for Zigbee Networks


Zigbee is one of the most widely used communication protocols for IoT devices in smart home environments. Zigator is a software tool that we developed in order to analyze the security of Zigbee networks. Our analysis led to the development of selective jamming and spoofing attacks that we implemented in the firmware of an IEEE 802.15.4 USB adapter. We studied our attacks against a set of commercial Zigbee devices by capturing I/Q signals with a software-defined radio. We conducted several experiments in order to gain insight into the nature of Zigbee traffic, especially in relation to NWK commands, and show that valuable information can be inferred from centralized Zigbee networks. Our dataset of captured Zigbee packets is available to download from the CRAWDAD research data archive. We reported the vulnerabilities that we discovered to the Zigbee Alliance and recommended security enhancements for the commissioning process.

Zigator Testbed

Software


Dataset


Presentations


Discovered Vulnerabilities

In the following figures we visually describe the vulnerabilities that we discovered with Zigator. Consider a Zigbee network that consists of a Zigbee Coordinator (ZC), a Zigbee Router (ZR), and a Zigbee End Device (ZED). Suppose that the Personal Area Network Identifier (PAN ID) of this Zigbee network is 0x99aa and its Extended PAN ID (EPID) is 0x1122334455667788. The attacker (A) can learn both of these values because they are transmitted unencrypted. The attacker can then cause a PAN ID conflict by spoofing a beacon that uses the same PAN ID (0x99aa) but a different EPID (e.g., 0xfacefeedbeefcafe). The attacker allows the Zigbee Router to inform the Zigbee Coordinator about the PAN ID conflict by transmitting the Network Report command. However, the attacker jams the broadcasting of the Network Update command to prevent the Zigbee Router and the Zigbee End Device from learning the value of the new PAN ID that the Zigbee Coordinator selected. The attacker can easily identify Network Update commands as they are being transmitted because they are the only NWK commands whose payload length can be equal to 12 bytes. Shortly after the broadcasting of the Network Update command, the Zigbee Coordinator switches to the new PAN ID (0xbbcc), but because the attacker interfered with its transmission, the Zigbee Router and the Zigbee End Device are still using the old PAN ID (0x99aa). Thus, the attacker can disconnect any Zigbee Router or Zigbee End Device from its Zigbee network.

Network Update Attack

One would expect that the Zigbee Router and the Zigbee End Device would try to rejoin their Zigbee network once they realized that they were disconnected. Let us first consider the case where the attacker wants to keep the Zigbee End Device disconnected. The Zigbee End Device is periodically sending Data Requests to its parent in order to poll for pending packets. If its parent does not respond to these Data Requests (e.g., because it is now using a different PAN ID), the Zigbee End Device should initiate the rejoin process. However, the attacker can spoof a MAC acknowledgment for each Data Request, since they do not utilize any authentication services. As a result, the Zigbee End Device remains disconnected because it thinks that it is still connected to its parent, so it does not initiate the rejoin process.

Data Request Attack

Alternatively, even if the Zigbee End Device was able to learn the new PAN ID and initiate the rejoin process, we discovered another approach that the attacker could follow in order to keep it disconnected. Similar to Network Update commands, Rejoin Responses can also be easily identified despite the use of encryption on the NWK layer. In particular, according to the Zigbee PRO 2015 specification, Rejoin Responses are the only NWK commands that can have a payload length of 3 bytes and be limited to a single-hop transmission. Therefore, by jamming only Rejoin Responses, the Zigbee End Device will keep initiating the rejoin process without reporting any observed events. Furthermore, since NWK commands also rely on unsecured MAC acknowledgments, the attacker could reduce the number of packets that have to be jammed by spoofing a MAC acknowledgment for each jammed Rejoin Response.

Rejoin Response Attack

Let us now consider the case where the attacker wants to keep the Zigbee Router disconnected. Obviously, since the Zigbee Router is not polling for pending packets, attempting to spoof a MAC acknowledgment for each Data Request would not affect the rejoin process of the Zigbee Router. We also observed that some of our Zigbee Routers were able to rejoin their Zigbee network even if they failed to receive their Rejoin Responses. Regardless, we were able to discover a different approach that allows the attacker to keep any Zigbee Router and any Zigbee End Device disconnected. After causing a PAN ID conflict and interfering with the broadcasting of Network Update commands, the attacker can prevent the Zigbee Router from rejoining its Zigbee network by jamming the beacons with the new PAN ID. Since the EPID remains the same after the PAN ID conflict, the attacker can selectively jam the corresponding beacons in order to prevent the Zigbee Router from learning the new PAN ID so that it remains disconnected.

Beacon Attack

If the aforementioned attacks are launched against a centralized Zigbee network, the end user will be unable to control their affected actuators (e.g., inability to lock a smart lock), affected sensors will be unable to inform the end user about detected events (e.g., inability to report the opening of a door), and automation rules that rely on affected devices will be unable to complete successfully (e.g., inability to turn the lights on when motion is detected). Apart from attacking the system's availability, the attacker may launch these attacks in order to learn the network key of the end user's Zigbee network by targeting Zigbee devices that use known Trust Center link keys to join the Zigbee network after a factory reset. For example, in our ACM WiSec 2020 paper we describe some methods by which the attacker can identify Zigbee devices that use the default Trust Center link key. If the attacker succeeds in tricking the end user into factory resetting such a device by launching a denial-of-service attack against it, then the attacker can obtain the network key by decrypting the Transport Key command during the commissioning process. Currently, a leaked network key enables the attacker to eavesdrop on the end user's smart home activities (e.g., reports of detected motion) and control the end user's Zigbee devices (e.g., unlock a smart lock). It should be noted that, currently, the attacker will also be able to control Zigbee 3.0 devices whose install codes have not been leaked if their network key was exposed by one of the other devices. Finally, we realized that some Zigbee Routers may not initiate or significantly delay the rejoin process when the attacker interferes with the broadcasting of Network Update commands. More specifically, our Centralite 3-Series Smart Outlet initiated the rejoin process about 25 minutes after the PAN ID conflict attack, while our SmartThings Smart Bulb did not initiate the rejoin process at all during the 38 hours that we monitored it since the PAN ID conflict attack. The attacker can exploit such behaviors to force the factory reset of a Zigbee device by the end user and expose the network key without having to jam as many packets as in the typical case.

In 2021, we leveraged the framework of our modified ATUSB firmware to implement an energy depletion attack against battery-powered Zigbee devices in order to test our prototype implementation of a network security monitoring system, called HiveGuard. You can find more information about our energy depletion attack and our network security monitoring system in our corresponding IEEE CNS 2021 paper and on the HiveGuard project page.


Related Publications