Introduction

In the previous articles (ZigBee Security: Basics (Parts 1 & 2)) provided a brief overview of the ZigBee protocol and its security features. ZigBee Alliance has made a remarkable feat in achieving confidentiality, integrity and, authentication.  However, it has failed to provide a comprehensive security suite. In this article, we explore ZigBee vulnerabilities and some practical attacks that could be performed on a ZigBee network. The article also provides an overview of the tools that can be used to assess a ZigBee protocol/network.

ZigBee Vulnerabilities

Vulnerabilities in a ZigBee network can be attributed to protocol issues (certain combination of protocol feature choices renders the network vulnerable) or poor implementation of the protocol by the developers. Some vulnerabilities include:

Implementation Vulnerabilities

Insecure key storage: ZigBee protocol’s security is based on the assumption that its keys are stored securely. Usually, the coordinator is preconfigured with the network key and, other devices such as routers and end devices are pre-configured with the link key. If the keys (network, link, or master) are insecurely stored; extraction of the keys from the device’s firmware becomes easy. Hence, when a node is compromised this way, a hacker can extract the network key and compromise the whole network or extract the link key and obtain all the unicast communication of the that device as well.

Insecure key transportation: In standard security mode, any node that joins a ZigBee network obtains its network key over-the-air, sometimes in plaintext. As a result, the key can be obtained by merely eavesdropping on the network. As the network key is shared among all devices; compromise of the network key, compromises the whole network.

Reusing Initialization Vector (IV) value with the same key is a security vulnerability inherited by ZigBee from 802.15.4. Reusing nonce values (Initialization Vector (IV)) with the same key introduces a vulnerability that enables an attacker to recover two plaintexts using their cipher-texts in the AES-CTR mode (recovering the two plaintexts is a simple operation; XOR operation on the two cipher-texts that has been encrypted with the same keys and nonce values). This attack is known as the same-nonce attack. There are 2 occasions that allow the reuse of nonce with the same key:

• Multiple Independent Access Control Entries: 802.15.4 radio devices have an Access Control List (ACL) for configuring the security suite that is to be used. Since each chip has multiple independent ACL, the same IV or nonce could be reused with the same key.
• Repopulating Access Control Table: this happens when a ZigBee device is inadvertently powered off, resulting in the loss of ACL entries and the need for the entries to be repopulated. If the last nonce states are unknown after the power failure, the system might reset the nonce states to a default value. This reset action increases
the chance of reusing the same nonce with a key that has been used before the power failure and could lead to the same-nonce attack.

Sending security headers in clear text: Auxiliary frames provide semantic security and replay protection. When an adversary crafts an invalid security header without knowing the key generating the MIC, although the integrity attack fails, the recipient device in fact expends certain amount of energy receiving and processing those bogus messages. If an adversary sends scads of such crafted messages to the victim device, a significant amount of energy will be dispensed by the device leading to its battery depletion. This attack is capable of reducing the battery life of a device from years to days [ghost attack or ghost-in-wireless].

Predictable sensor polling rates: ZigBee end devices remain in sleep mode for certain periods of time to conserve energy. They wake up at regular intervals to poll the coordinator for data inputs or wake up when the coordinator beacon so. However, knowing the polling rate will help an attacker to relay crafted messages to the end device at regular intervals even if it wasn’t required, thereby forcing the end device to dispense excess energy for polling (energy is dispensed when the device navigates from sleep mode to active mode) and processing the received messages. (Vidgren et al. demonstrates how it is possible to discharge the batteries of a sensor if the attacker knows the adopted sensor polling rate.)

Protocol Vulnerabilities

Default link key values are used by manufacturers to provide interoperability for all ZigBee devices. For example, a case where a user has a new ZigBee device to be added to his/her network, but the new device has no specific authorization associated to it, the ZigBee network will allow a default link key to fall back to at the startup time. Therefore, an attacker can join the network by using an unknown type device and collect the data needed to temper the network’s functionality. SEC Consult’s research has also revealed that millions of IoT devices are directly accessible via the Internet, and attribute it to insecure default configuration.

Unauthenticated acknowledgement packets (ACK): The 802.15.4/ZigBee specification does not provide integrity and confidentiality protection for acknowledgment packets. Hence, an unauthenticated remote attacker can spoof acknowledgement packets to cause a remote node to believe an acknowledgement was received by the intended node. This attack (association flooding) is a direct consequence of man-in-the middle attack.

Man-in-the-middle attack instance: A sender device sends a packet to the receiver and waits for an ACK confirming that the receiver has received the packet in order to continue its operation. In case an ACK was not received, the sender will send the packet again. However, in case the network is compromised and the ACK packet is not authenticated, an attacker can intercept the packet and send fake ACK to the sender. Thereby, forcing the sender to send all subsequent packets to the attacker.

CSMA/CA trade-off: At the MAC layer, an attacker can flood a channel with frames, thereby forcing the network to deny any communication among devices. This is made possible because ZigBee uses CSMA/CA (if it is running in non-beacon mode) and devices that use CSMA/CA communication always back off if a channel is busy, thereby resulting in an inadvertent DDoS. Exposed and hidden node problems in a network can also be considered shortfalls of CSMA/CA mechanism.

Unencrypted keys: When a non-preconfigured device joins a network, a single network key (default link key) is sent unencrypted by the Trust Center (at least in residential mode). This one-time transmission of the unprotected key results in a short timeframe of exploitability. If the key could be sniffed by an attacker, the active network key stands compromised and consequently the whole ZigBee network communication is compromised.

Vidgren, et al. demonstrated a sniffing attack on a ZigBee network that sends the network key unencrypted by having a node (Atmel RZRAVENUSB) interact with a ZigBee device and collecting their wireless transmissions/interactions. The captured packets were later analyzed using open source tools (KillerBee) to obtain the network key.

Predictable PAN IDs and limited channels: In ZigBee protocol, a rejoining device joins a network when its saved parameters match the PAN ID and the channel that the network is operating on. The PAN ID is a 64-bit value, and can be brute-forced (It will take some processing time to find the right PAN ID, but eventually an attacker can find its value). Also, the channel numbers that ZigBee operates on is limited to 16 which makes it easy to find the correct network channel as well.

Insufficient replay protections: You might argue that ZigBee has replay attack protection mechanisms as part of its specification; however, 802.15.4 specification has limited replay protection mechanisms that even an encrypted message cannot complement. Hence, a crafty attacker can replay any previously observed traffic (ZigBee has the advantage of preventing the attacker from modifying the packets) until key rotation (provided 802.15.4 has no authentication mechanisms enabled). There are several other attacks that accompany replay attack:

• DDoS: a malicious user can receive packets at one point in the network and then replays these packets in other areas to interfere with the overall network functionality (wormhole attack)
• Temporal Key Integrity Protocol (TKIP) MIC attack in IEEE 802.11 networks is the one in which an attacker decodes the payload one byte at a time by using multiple replays and observing the response over the air on MIC failures.

Over the years, researchers have also succeeded in implementing the replay attack using the “Killer Bee” tool made by Joshua Wright and have clearly illustrated the severe problems it can cause. For example, medical devices such as Fitbit, pacemakers and insulin pumps which replay old messages can lead to erroneous outputs and dangerous events (loss of life).

Signal interference: Although ZigBee has certain network interference protection techniques established, they are however not comprehensive and slow to execute, allowing an attacker to take control of the frequency channel the network is operating in. This phenomenon is prominent in large networks, where transmissions are much more frequent and the signals can be detected quite efficiently.

Unauthorized network commissioning: The ZigBee device connects to the first network that is made available to it without any further interaction from the ZigBee device’s user. Hence, it is possible to force a ZigBee device to join a fake network (even without the knowledge of the active secret keys expected by the ZigBee device if it were rejoining a network). An attacker could do this by sending a “reset to factory default” command to the device and wait on the device to look for a ZigBee network to connect to.

Lack of DDoS Protection Mechanisms: A denial-of-service (DoS) attack causes a node to reject all received messages. In a ZigBee network, DoS can be achieved by:

• Maximizing the frame counter: The attacker composes a message that includes random content (legit is fine too) as the encrypted payload (without knowing the security key), sets the frame counter to the maximum, and sends it to the node. By setting the frame counter to the maximum, any legitimate frame that arrives at the node after the attack will be automatically rejected by the recipient device because the frame counter of the received message will be less than the one recorded by the node at the time of the attack. This attack is made possible in situations where MIC of the packet is not verified.
• Flooding the network with messages (legit or spoofed packets) or frames. Krivtsova et al. proposed the broadcast storm attack that involved clogging the network by sending numerous broadcast packets.
• Altering routing tables to redirect all the traffic of the network to a bogus device (sinkhole attack) by purposely sending messages to construct artificial routing paths or introduce loops to the routing process of legitimate sensors. As a consequence, transmission of packets among devices is hindered, resulting in a DDoS.
• Using jamming techniques (signal jamming, reflexive jamming, changing the Power Spectral Density, etc) to trick the user to initiate a factory reset or preventing the devices from communicating. This technique can also force a rejoin and reestablish the attack time-frame to sniff the network key.

Re-using link key: ZigBee allows link keys to be re-used for rejoining the network. Hence, it would make it possible for an attacker to copy a device’s addressing credentials and spoof a network layer insecure rejoin using a separate device. This would result in the Trust Center passing the network key encrypted with the previously used link key to the cloned device. As a consequence, an attacker could gain complete access to the network key and hence the entire network.

TouchLink Factory reset: It is legitimate for a Touchlink initiator to send a factory-reset command to a target node already
in the network, allowing the target node to be removed from the current network and moved to another network. The process is aptly known as stealing. However, it provides a window of opportunity for an unauthorized person to move a device into another network of his/her for malicious intent.

Privacy issues: ZigBee protocol/network, similar to other wireless networks is susceptible to statistical attacks. Gleaning network traffic can reveal, with certain accuracy, the nature of the functionality implemented, thereby aiding the attacker to work around it to perform his or her malicious deed. However, a statistical attack on a ZigBee network can compromise ones Privacy as well. For instance, in home automation systems, an attacker can gather information to ascertain if tenants are at home or not. This information can aid an attacker to perform an informed robbery.

Pen-testing Tools

This section describes some hardware and software components used to assess the security robustness of the ZigBee protocol/network.

Hardware

• Bus Pirate and GoodFET: is required for physical attacks. It helps obtain encryption keys through physical attacks. [Check JTAG Debugging with Bus Pirate and OpenOCD]
• RZUSBSTICK: low-cost ZigBee radio used for sniffing and replay attacks. However, it sometimes stops recording packets out of the blue.
• Chibi: microcontroller with integrated ZigBee radio.
• Memsic TelosB (TPR2420): can receive frames from outside the building. For war-driving purposes, the TelosB seems to be the better choice. However, it tends to drops packets occasionally.

Software

• KillerBee: a suite of software tools that allow sophisticated interception (the sniffer software provided by KillerBee does not always catch all 802.15.4/ZigBee frames), analysis, and even transmission of 802.15.4 packets.  Also provides tools to inject and replay traffic, attacks cryptosystems, etc. KillerBee works well with Scapy and fuzzers like Sulley.
  • Scapy: is a versatile packet manipulation tool written in Python. Its two main features are mechanisms to create standard compliant packets and to parse received packets into their fields. Without a tool like Scapy, every packet has to be assembled manually bit by bit.
  • Sulley: fuzzing engine and fuzz testing framework consisting of multiple extensible components. The goal of the framework is to simplify not only data representation but to simplify data transmission and instrumentation
• SECBEE – ZigBee securityF testing tool. Based on scapy-radio and killerbee. It enables testers to check encrypted networks and automatically perform ZigBee specific tests such as network leaves / joins, reset to factory defaults or search for unsecure key transport.
• Z3sec: is a toolthat can help you pentest Internet of Things (IoT) devices that use the ZigBee standard. You can be a passive eavesdropper to extract key material from a distance of up to 130 meters. You can exploit legitimate touch link features to trigger the identify action, reset to factory defaults, change the wireless channel, and to join a touch link-enabled device to another or non-existing network.
• Api-do: Tools for ZigBee and 802.15.4 Security Auditing from the Dartmouth Trust Lab.
• Fuzzing Tools: Fuzzing can render devices unusable provided the device does not implement safe error handling mechanisms. On the brighter side, this would be accounted for a successful DoS attack.

Conclusion

The vulnerabilities listed in this article are a result of implementation errors or lack of “security by design” implementations. While the listed vulnerabilities can be exploited remotely, it is possible to attack micro-controllers and ZigBee radios as well, and hence, ZigBee devices, in general, are susceptible to side-channel attacks and other physical attacks. Therefore, just as network security is considered crucial for any ZigBee implementation, physical security must be taken seriously as well.

Assessments and verification is crucial at every step of development and the listed tools can aid in doing just that. While the tools listed seem ideal, they are however, not comprehensive or as robust as you would expect: Time to receive, parse, execute and send response frames might not match the ones required by the ZigBee devices. Having understood ZigBee protocol, its security measures, and various attacks that could be performed on a ZigBee device, in the articles to follow, we look into setting up KillerBee with RZUSBSTICK and performing a ZigBee pen-testing assessment with our new-found knowledge of ZigBee attacks and ZigBee pen-testing tools.

References

• Cache, Johnny, Wright, Joshua, and Liu, Vincent. Hacking Exposed: Wireless. Second Edition. McGraw-Hill, 2010.
• 15.4-2011 – IEEE Standard for Local and metropolitan area networks–Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs) <http://standards.ieee.org/findstds/standard/802.15.4-2011.html>
• ZigBee Security at Dartmouth Trust Lab. <http://www.cs.dartmouth.edu/~rspeers/>
• ZigBee Specification, ZigBee Document 053474r17, ZigBee Alliance, January 17, 2008
• Radmand, M. Domingo, J. Singh, J. Arnedo, A. Talevski, S. Petersen, and S. Carlsen. “ZigBee/ZigBee PRO security assessment based on compromised cryptographic keys”. Digital Ecosystem and Business Intelligence Institute, Curtin University of Technology, Perth, Australia
• Olawumi, K. Haataja, M. Asikainen, N. Vidgren, and P. Toivanen “Three Practical Attacks Against ZigBee Security: Attack Scenario Definitions, Practical Experiments, Countermeasures, and Lessons Learned”, in IEEE 14th International Conference on Hybrid Intelligent Systems (HIS2014), At Kuwai. DOI: 10.1109/HIS.2014.7086198
• N. Whitehurst, T.R. Andel, and J.T.McDonald. “Exploring Security in ZigBee Networks”, in 9th Cyber and Information Security Research Conference, 2014. ACM 978-1-4503-2812- 8/14/4
• ZigBee wireless networks and Transceivers – Shahin Farahani
• Y. Vasserman and N. Hopper, “Vampire attacks: draining life from wireless ad hoc sensor networks,” IEEE Trans. Mobile Computing, vol. 12, no. 2, pp. 318–332, 2013.
• Devu Manikantan Shila, Xianghui Cao, Yu Cheng, Senior Member, Zequ Yang, Yang Zhou, and Jiming Chen, “Ghost-in-the-Wireless: Energy Depletion Attack on ZigBee”
• Ivan Vaccari, Enrico Cambiaso, and Maurizio Aiello, “Remotely Exploiting AT Command Attacks on ZigBee Networks”
• https://phys.org/news/2017-09-flaws-smart-home-products.html
• Philipp Morgner, Stephan MaŠejat, Zinaida Benenson, “Insecure to the Touch: Attacking ZigBee 3.0 via Touchlink Commissioning”
• Vidgren, K. Haataja, J. L. Patiño-Andres, J. J. Ramírez-Sanchis, and P. Toivanen, “Security threats in ZigBee-enabled systems: Vulnerability evaluation, practical experiments, countermeasures, and lessons learned,” in Proceedings of the 46th Annual Hawaii International Conference on System Sciences, HICSS 2013, pp. 5132–5138, January 2013.
• Krivtsova, I. Lebedev, M. Sukhoparov et al., “Implementing a broadcast storm attack on a mission-critical wireless sensor network,” Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics): Preface, vol. 9674, pp. 297–308, 2016.