Since the introduction of the ZigBee-2004 specification, the ZigBee Alliance has made significant improvements in the security of sensor-based wireless networks. Despite improvements introduced in later amendments including the ZigBee-Pro specification, the security is not bullet-proof, due to the significant constraints of CPU, flash and memory availability in low-cost devices. Designing around these constraints, the ZigBee Alliance has made reasonable security options available to vendors of ZigBee products, broadly classifying security levels into high-security mode (intended for enterprise applications) and low-security mode (intended for residential applications). Looking at the available offerings for ZigBee stacks from vendors such as Atmel, Microchip and TI, it is apparent that high-security mode costs more, not necessarily in software costs but in terms of memory, flash and CPU requirements.
If you read up on ZigBee, you’ll quickly identify the Achilles’ heel plaguing the security of any low-cost wireless technology:
|“… due to the low-cost nature of ad hoc network devices, one cannot generally assume the availability of tamper resistant hardware. Hence, physical access to a device may yield access to secret keying material and other privileged information, as well as access to the security software and hardware.”
ZigBee Specification 053474r17, Jan. 2008; available from www.zigbee.org
Effectively, if you use sensor-based networks, and an adversary is able to steal a device, they can extract key information from the hardware which can be used to exploit the rest of the network. This style of attack has been demonstrated by my neighborly colleague Travis Goodspeed on multiple occasions, snagging encryption keys, dumping device firmware and many other interesting hacks with hardware in hand.
Following Travis’ article, a few people submitted posts indicating that while his attack is interesting, it requires hardware to be effective. Today, we’re a little bit closer to making that reality.
Introducing zbfind – ZigBee Location Tracking
Following my previous work on reversing the Microchip Zena ZigBee sniffer, I put together a quick Linux tool to passively sniff for the presence of ZigBee/802.15.4 devices and display some summary information about the identified devices. When a device is selected in the GTK UI, a speedometer needle and histogram will record the relative signal strength of the selected device with a relative distance estimate in feet using the free-space path loss formula. A screen-shot is displayed at the top of this post.
Readers from my SANS Ethical Hacking Wireless course will recognize this UI; it’s based on a tool Mike Kershaw and I wrote for Bluetooth analysis (that has yet to be released, but we have big plans for it, stay tuned). This initial code is a little rough around the edges, but provides a simple interface to track down and identify ZigBee and other 802.15.4 devices in the area.
I’m holding off on releasing this tool until I iron out a few more bugs, but am happy to share the code individually if folks 1. have a Microchip Zena Sniffer and 2. have experience with Linux and Python. Drop me a note if you are interested and meet these conditions (I don’t mean to be unfair, but I want to spend my time working on the code to add features and fix bugs instead of helping users, at the moment; thanks for understanding).
My goal in releasing this tool is simple: provide administrators with the firepower to justify the added cost of enterprise-security ZigBee technology with hardware tamper-proof security features. If the tools don’t exist publicly, many people disregard the threat. By making this tool available, I’m hoping people will be able to use it as an argument to justify more expensive ZigBee hardware deployments where warranted by security policy.