The ZigBee threat landscape
As the range of IoT products utilising the ZigBee protocol continues to grow, cementing the protocol as a major player in the IoT connectivity landscape, it seems like a good time to look at the current state of security with regards to the specification as well as the implementation by the many manufacturers taking it up in their devices.
Overview
First, let's look at what ZigBee actually is. ZigBee is a popular industry protocol standard within the same family as other control system protocols based on IEEE 802.15.4. The IEEE standard defines the underlying network stack, and forms the basis of several other protocols such as DigiMesh and Thread. While 802.15.4 is a protocol in itself, used for higher bandwidth, lower latency scenarios, these deritivative protocols extend the standard to suit other uses, often incorporating mesh networking capability, or simplified network control service. ZigBee, similar to Bluetooth, is designed to provide a low cost, low power, low data rate wireless solution for connected devices. These devices are not typically 'internet connected' in themselves, but rather form part of a WPAN (Wireless Personal Area Network) that, in turn, is connected to a local IP network and, potentially, the internet through a bridge device.
This WPAN arrangement delivers some segregation from our other devices, but two key threats remain for users of these devices in the home.These are device takeover and manipulation, and presenting an attack vector into the home network. The severity of the former depends largely on what your ZigBee devices are doing. An attacker gaining control of your lights is not a huge threat, but if your door locks are on the same network you have bigger concerns.
ZigBee is an open standard defined and controlled by the ZigBee Alliance. A formal certification program, administrered by approved third parties, is provided by the alliance to ensure protocol requirements are met. The primary focus of the certification program seems to be user experience. The criteria are largely focused around interoperability and correct protocol functionality, rather than any specific security focus.
ZigBee Protocol Model
There is a useful write up on the security design in this paper from UNLV if you want to dig into the details. As a summary for our purposes, the security framework in the ZigBee protocol does cover the requirements that we would expect from a secure network. Data encryption, replay protection, and message integrity are all built in. Broadcast communication on the network is encrypted with a network key, and unicast communication between nodes on the network is secured with a device specific link key. In a mesh scenario, the communication is routed between nodes to get to the destination, and is decrypted and re-encrypted by each node in the route with it's own key, which is all good on paper.
Exploit History
There have been various documented theoretical attacks against ZigBee dating back to 2011, a key example being the widely publicised possible attack on Philips Hue light bulbs in 2013. In that exploit, the researchers leveraged weak authentication with the bridge device to issue continuous commands into the ZigBee network to turn off the light bulbs. By utilising a simple MAC address whitelist to authorise devices to send commands to the bridge, a script delivered via a malicious website was used to sniff MAC addresses from the local network and try them until a successful command was sent. This type of attack is indicative of the lax state of security observed by manufacturers back then.
More recently, a series of vulnerabilities were identified in Osram's LIGHTIFY products in 2016. While many of these relate to the app, such as storing the Wifi key in clear text in the configuration files, device issues include allowing unauthenticated access to the gateway via TCP 4000, and a ZigBee implementation issue was found where failure to re-key the devices after initial pairing would allow for capture and re-use of the key by an attacker. Osram has responded appropriately by issuing patches, although it's not clear if all the issues have been resolved by this point.
Gateway products are of particular concern, as they not only provide the remote attack path to the devices, but also are the entry point to our home networks from a compromised end device. As shown in this 2016 Threatmodeler listing for the SmartHome Gateway, these can be essentially wide open if not built with a security focus.
In another, more interesting, attack demonstration from 2016, researchers from the Weizmann Institute of Science leveraged a global default key exposure in Philips Hue lights to execute a takeover attack by uploading malicious firmware. As this is done over the air, the researchers used a drone to infect lights from significant distance, and could theoretically do so over a large area in a short time. Thankfully the exploit has been patched by Philips after the researchers disclosed the attack to them.
Whilst manufacturers have certainly begun to increase their security focus in the last few years, the number of significant ZigBee related exploits covered in 2016 alone paints a disturbing picture. The better vendors, like Philips, are leveraging OTA updates to patch vulnerabilities reasonably promptly, but lower cost mass producers are not so interested in fixing issues after sale. It is these latter devices that are the subject of the actually attacks in the wild, and their numbers are only increasing. Let's look at what the security researches think of the ZigBee situation.
Security Analysis
An excellent investigation of their ZigBee security model was conducted by Tobias Zillner of Cognosec, and presented at the Blackhat security conference in 2015. In the article, Zillner explains the key exchange flaw in the ZigBee protocol. The protocol requires the use of a predefined default trust centre link key, "ZigBeeAlliance09" as a fallback for network pairing. This was easily exploited in a number of devices by selectively jamming the target device, forcing a re-join attempt. When the attempt failed the fallback path was used to encrypt and transmit network key for the join attempt.
“The Home Automation Public Application Profile states that: “The current network key shall be transported using the default TC link key in the case where the joining device is unknown or has no specific authorization associated with it.””
The use of a known default key, and an easily forced fallback to it's use, presents a clear threat to the network as once the network key is sniffed by the attacker, the entire local ZigBee WPAN is compromised. This same attack worked on the commonly used ZigBee Light Link profile as well, and while compromising control of the lights may not be a huge concern, the resultant access to all devices on the network certainly is.
Further compounding this attack vector is the fact that these types of devices may not offer any way to change the Network key, or to lock out unauthorised access once gained.
While it's worth noting that this analysis was from 2015, the paper by Charzel Azeri of UNLV dated December 2016 describes similar behaviour, both by the use of the default TC Link Key, and the clear text broadcast of connection details in some cases.
“In ZigBee protocol if the link key is not configured by the coordinator, then the network key will be sent unencrypted to the joining devices that match the PAN ID and the channel that the network is operating on. The PAN ID is a 64-bit value, and will take some processing time to find the right PAN ID, but eventually an attacker can find its value. ”
The paper goes into extensive details around the setup and execution of proof of concept attacks, so it's worth a look if you want to see the implementation details.
Conclusion
The ZigBee Alliance notes clearly that the implementation of the key handling and storage is fundamental to the security of the protocol:
“The level of security provided by the ZigBee security architecture depends on the safekeeping of the symmetric keys, on the protection mechanisms employed, and on the proper implementation of the cryptographic mechanisms and associated security policies involved. ”
Zillner notes that the protocol itself is secure, stating "The security features provided by the ZigBee standard can be considered as very strong and robust". The issue is consistently in the implementation of the security aspects by the manufacturers. This is a challenge, especially for consumer devices where convenience and ease of setup are necessary considerations. This inevitably results in the less secure key exchange behaviors noted above.
The protocol continues to evolve, but the limitations around consumer device interfaces and their inability to handle data input and configuration easily will remain an issue. For lighting solutions and similar low security applications, ZigBee is a great lightweight, cost effective solution. But for now, it would seem to be best to avoid using ZigBee devices for security and any applications that could have more significant impact on your household.
