Is "Insecure Rejoin" for Zigbee still a risk?

I have a few Zigbee devices that go offline periodically, and I read that enabling the “Insecure Rejoin” is one method to allow these devices to reconnect again without my intervention. However, I also read about the security risk this could cause, but they often reference that Zigbee 3.0 will fix this. If I have a SmartThings Hub v3 that I believe supports Zigbee 3.0, do I still need to worry about this security vulnerability or no?

I honestly didn’t believe it was something to be concerned about with previous hub versions, but my environment and scenario may not reflect yours.

I believe unless if you live in a densely populated environment, or perhaps have other Zigbee hubs that are in an “auto-join state constantly looking for new devices mode”, or have a crazy neighbor constantly joining devices, or there’s a hacker parked in your driveway waiting to access your mesh, I’d enable insecure rejoin. Remember, someone would have to be in close proximity and in range of your Zigbee mesh.

TLDR:

The current ZigBee Home Automation 1.2 standard uses encryption to allow only authorized devices to join a home network. In order to allow some devices (like motion sensors) to drop off of, and then easily re-join the network (to preserve battery power), there is a feature known as “insecure rejoin” built into the standard. It has been shown, however, that in very specific cases this feature could potentially be used to gain unauthorized access to a ZigBee network. The upcoming ZigBee 3.0 specification removes this potential vulnerability, but until that new standard is released, SmartThings is giving users the ability to disable the insecure rejoin feature.

5 Likes

Is ZigBee 3.0 official doc avaliable? I didn’t find any docs about ZigBee 3.0, only ZigBee Pro-2015.

It’s been available for years (first the draft form, then the final) through the Zigbee alliance, so you could start there.

https://zigbeealliance.org/

If you are looking for something available online, NXP publishes a good technical user guide

If you just want the security details, see the following:

1 Like

Thanks a lot!

2 Likes

I am still confused as to the danger of insecure mode.

What would could a nefarious device do to the network? And wouldn’t you see it in your devices and know it doesn’t belong?

Or is the danger a device impersonating another that sets off an automation? Like a presence sensor triggering a look opening. A ‘fake’ sensor could rejoin and convince the lock to open to an attacker? Seems like a lot of work.

There are three significant types of attacks.

  1. Denial of Service after an attacker adds a node to your network (of any kind) and then starts flooding your network with messages.

If it’s just a random hacking and you are not yourself individually at target, then The risk is quite low, usually just prankster type annoyance, typically flooding your network with way too many messages so that your legitimate messages can’t get through and you start getting annoyed with the whole system.

For a typical specified target, the biggest risk would be if this caused legitimate Sensor signals not to be able to get through, so that you didn’t get an alert that a sensor had detected window opening because your whole system was being flooded with messages from the cuckoo’s egg device.

These can be truly dangerous for health devices like pacemakers. And obviously there is some danger if your lights are not going on when you expect them to, but not usually on the same level of risk. The attacks on a security system are a real issue if you are being specifically targeted, that is someone knows that you have zigbee sensors and are relying on them.

  1. device stealing.
    There is another kind of attack which is complicated but possible. And attacker may be able to trick one of your existing devices, specifically a sensor or maybe a doorlock, into joining the attacker’s network instead of your network at a rejoin point. They would then have control over that specific device. They could even reset the user codes on a lock, for example. But that is a more complex attack then just flooding the network and people who are likely to be the target of that kind of effort or not likely to be using smartthings for their home automation anyway.

  2. replay for a purpose.

It may also be possible for The attacker to record and then replay an existing legitimate network command, which might fool the target device into thinking it was a real command when it was replayed. These really only make sense in highly highly targeted scenarios. So someone waits for you to come home, records unlock or garage door information that gets sent when your presence is detected, and then later replays those messages to get the door to unlock or the garage door to open. But this sounds scarier than it really is because it’s pretty hard to do. It’s hard to get the message in the first place, it’s hard to know exactly what message you got, and then of course you have to replay it later. All of which has to be done physically close to the home. So it’s not impossible but again it’s not likely to be just some random prankster.

And in all three cases the person would have to be physically close to your house during the attack, which usually isn’t worth the risk for most just random hacking.

So… Is it a risk? Yes. Could it have serious consequences? Sure, if somebody got into your house when you didn’t want them to. But it’s not an easy hack and it does require being physically close. It’s something you should probably worry about if you have a bad break up with an ex or an ex roommate who knows a lot of the details about your set up and has strong technical skills. But it’s not likely to be something that some techno kiddie sitting at a keyboard 1000 miles away can just randomly do for fun.

NXP: Maximizing Security in Zigbee Networks

2 Likes

Good summary and detailed, thanks.

Sounds like a lot of trouble to break into my house! A brick to a window or my head sounds a lot easier.

2 Likes