Researchers find major security flaw with ZigBee smart home devices
Don’t know if anyone else saw this, and if it’s just Engadget trying to scare up some news, but it’s interesting nonetheless. I am not technical enough to comment, but I wanted to get some thoughts.
Initial internal conversations about this are that it’s not new information and was specifically understood during the design of the ZigBee spec.
Yes, ZigBee pairing sequence is insecure. However practically all modern ZigBee hubs are not in pair mode by default.
The only way to join a network is to be in pair mode.
The keys are secure but the keys can be found. It requires specific software and on premise access, so not a huge risk but a risk none the less.
ZigBee has been around for over a decade, and is improving significantly in 3.0 standard.
A signal jammer would be far more effective and easier than capturing secure keys. As would breaking down the door.
Keep in mind all ZigBee attacks require local access and the hub to be in join / pair mode, and no way to hide your hack on the mesh.
It is doable but extremely difficult.
Thanks! And it seems to be limited to certain devices that poorly implement security. It’s always good to be aware of potential threats.
The flaw seems “difficult” enough to exploit that the targets would have to be of high value. I doubt the typical home is realistically at risk while other easier vulnerabilities exist (e.g., physical lock picking / key bumping 
)
As stated above, the ZigBee Security is based on
the assumption that keys are securely stored, and
devices are pre-loaded with symmetric keys so
they have never to be transmitted unencrypted.
But there are exceptions to this policy. If a non-
preconfigured device joins a network, a single key
may be sent unprotected and enable encrypted
communication. This one-time transmission of the
unprotected key results in a short timeframe of
exploitability in which the key could be sniffed by
an attacker. Since the security is dependent on
the safekeeping of the encryption keys such a key
interception would lead to a critical security
compromise and puts the security of the whole
network at risk. Even thought the timeframe
seems to be narrow, an attacker could use
jamming techniques to trick the user to initiate a
factory reset or another way of re-joining, re-
establishing that attack time-frame.
Well i’d have to agree, that is a pretty serious security flaw. Luckily it really requires developing a perfect storm to exploit it. IDK what anyone else’s zigbee range looks like… except @JDRoberts 
but in my case i pretty much have a 5-10ft zigbee bubble around my house and you would have to be in the bubble to pull off the attack and be very patient. Now if your zigbee range extends to the street or your neighbors house and you have things or knowledge in your home worth enough to wait days or months to steal and you have a zigbee door lock/HVAC then you should take action to @ least shrink your zigbee bubble. If thats not the case its still WAY easier to break in through a door, window or wall.
but thats just my 2 cents…
I’m waiting for the day someone gets in my house and has to deal with…
<— him.
Not really, but it would be funny to see it on video. We did have a rather inebriated individual from a party a few houses away get ‘lost’ in the middle of the night and walk in the front door, right after I closed it (I opened it to greet him, closed it, and in his drunken stupor, thought he was at the right house again). He got sober rather quick. It was rather funny to see a very large, very drunk fellow run sideways and crooked through the yard to get away from a rather crabby dog.
Many experts will be weighing in on this over the next few weeks, so I’ll leave analysis to them.
The Zigbee Light Link issue has been known for a long time, but there’s separation between them and other devices. Locks don’t use TC. Different zigbee profiles have different security protocols.
Here’s the full paper for those interested:
Engaget - loves the security linkbate 
Nicely said.
I can think of a few (maybe fun) social engineering attacks to get someone to put a hub into pair mode. It is certainly more directed (very much active, not passive), however. Not quite as easy as the garage door attacks of yesteryear.
In case any ZigBee experts are following this. Any ZigBee sniffer can capture packets without joining the network.
These packets are encrypted. In my limited tests, ST appears to not be using the default key or fallback key.
So you would need to capture the key exchange in join / pair mode and then you would be able to decrypt the packets.
Still that only gives you the data, is you could see the status of a device on poll.
In order to attack the network you would need to join the network. This can not be done without user sending hub into pair.
However, ZLL is vulnerable, as it has less security then ZigBee ha. ST doesn’t appear to use ZLL for any ZigBee functions, yet. ZLL is also limited to lights.
So a ZLL attack would just effect light bulbs.
ZLL doesn’t require a controller and it’s always had this vulnerability.
The assumption was that it was no big deal because:
A) it’s only lights and
B) Touch Connect would require that new bulbs would need to be within a few inches to force a new pairing.
B) turned out not to be quite true, although the max distance is probably less than a meter. But not quite as secure as planned. And, you know, lampstealer.
Here is a pretty good article that breaks down the vulnerabilities.
TLDR;
The hub will pass the encryption keys on boot. If you can force the controller to reboot, you can steal the keys. ZLL bulbs send get the keys in pairing mode. If you can get the hub into pair mode you can get the keys. The Zigbee standard has good security built in, but it’s up to device makers to enforce good security practices.
Since SmartThings is based primarily on compatibility with Zigbee and Z-Wave home automation standards, how do the two standards compare with regard to known security flaws? Is Zigbee being unfairly criticized for a minor security flaw that is also an issue with Z-wave devices?
What about security measures in newer standards like Home Kit?
HomeKit has very tight security, so much so that reportedly the challenges in getting it right are one of the reasons very few HomeKit devices have come to market yet. It will be awhile before we can really evaluate it.
Zwave, just like zigbee btw, offers different levels of security options. Quite a few complaints about the newest zwave generation, that pairing in high security mode is very difficult, and fails a lot. (You can see these concerns expressed in these forums with regard to the newest aeotec lightbulb and Aeotec multi-sensor.) sometimes very secure becomes too secure for normal use.
It’s always tough to get the balance between usability and security right.
To be fair, the flaw is not in the zigbee standard itself; but, in some implementations of that standard the vendors have made the devices easier to use at the expense of security.
Where is this stated? I never noticed the hub passes encryption keys on boot, only on pair / join requests. ZLL is totally insecure by default, since it is designed that way.
The two issues are these: private key exchange at pair / join can be intercepted, either sniff out packets or as an endpoint device. Also, some hubs (ST has not confirmed this vulnerability publicly, not sure if it is an issue or not) use a fallback default key vs using a secured custom key.
If the fallback default key is used, then any device, including rogue devices can be paired, potentially without a join command, but most likely will still need to be in join mode.
However, if the fallback key is used, then all sniffed packets could be decrypted easily.
If all hubs use the same hard coded key, which a lot of manufacturers do, once that key is discovered, then any sniffed packets that use that hard coded key could also be decrypted.
Again, decrypting packets only gets you status of devices. Not a high risk vulnerability.
However, forcing join mode and having the ability to send encrypted packets to other zigbee devices could cause problems.
In theory, the main vector of attack is to inject an encrypted packet to the hub to force it into join mode, spoofed from another joined endpoint, could gain access to the mesh and hub.
It is possible, but I would be much more worried about someone just logging into my ST account and pushing the “+” button that puts the hub into join mode anyway. Much easier.
'#1 Zigbee security flaw is the end user access to the hub and that access can be hacked. Doesn’t matter the hub.
If that isn’t a reason for optional 2 stage authentication, I don’t know what is. I truly wish ST would reconsider their stance on mobile device authentication.
Don’t know if this is ST behavior or not. But was one of the exploits they demoed.
From the article
That’s not the case with a home-security system. The pair played a video of a demonstration in which they jammed the ZigBee signals used by a wireless security system, forcing a reboot in which the encryption keys were again transmitted in the clear.
