There are really two distinct things at play here, and I’ll do my best to describe them, what their potential impacts are, and what we’re doing at SmartThings to eliminate or mitigate them. I apologize in advance if this is overly dense, but there’s a lot to get to here.
What are the issues?
First, as @JohnR points out above, there is a designed “moment of insecurity” in the Zigbee HA 1.2 specification that uses a well-known symmetric encryption key known as the Trust Center Link Key to distribute a unique network key when a device first joins the network. This is a tradeoff that the ZigBee Alliance chose to make between security and simplicity - with a mitigated impact given that an attacker would have to be capturing ZigBee network traffic at the same time that a new device is being joined to the network.
This method has been removed from the upcoming ZigBee 3.0 specification and replaced with a process that requires a per-device installation code that is used to generate a unique joining key, which is then used to acquire the ZigBee network key. The install code may be printed on the device, be a 2D barcode that is scanned by a camera, or some other out-of-band method of passing the code from the end-device to the ZigBee Coordinator device (in our case, the SmartThings Hub) such as NFC or Bluetooth Smart.
The second issue described by CognoSec is with a method known as “insecure rejoin.” Insecure rejoin also exists in the ZigBee HA 1.2 specification as a tradeoff between security and simplicity. This method allows a previously paired device to rejoin a network using the same well-known Trust Center Link Key in the event that the network key changed since the last time the device joined the network. This enables battery powered devices that aren’t always listening for commands from the ZigBee Coordinator (otherwise known as “sleepy” devices) to rejoin a network if the network key changed, as the sleeping device wouldn’t have received the new key from the ZigBee Coordinator.
So if an end-device such as a motion sensor or contact sensor fails to join the network using their stored network key, they can ask for the new key which is transmitted using the well-known Trust Center Link Key. The specific issue that CognoSec describes in their publication is the ability to spoof a device on the network to send a false insecure rejoin request, triggering the network key to be sent using the well-known Trust Center Link Key. This bypasses the mitigation effect described above, as an attacker could potentially cause the network key to be transmitted at will.
How is SmartThings impacted, and what are we doing about it?
SmartThings currently supports insecure rejoin, as many ZigBee HA devices will only attempt to rejoin once with their stored key before reverting to an insecure rejoin mode. This means that without insecure rejoin, if there are any issues rejoining the network after a Hub reboots or a router in the mesh goes away, the device would not be able to rejoin the network and would be effectively stranded. The only way to resolve a stranded device would be to delete it from SmartThings, perform a factory reset on the device, and put it back through the initial join process.
We do recognize the security concerns presented by spoofed insecure rejoin requests, and since the issue was brought to our attention we’ve been developing an update that will give users the option of turning off insecure rejoin while we work to understand the broader negative impact of simply disabling it by default. We hope to have this update in place within the next 60 days. Once the feature is available, we’ll let you know how to go about disabling insecure rejoin. In the longer term, the ZigBee 3.0 specification eliminates the insecure rejoin process.
As for the initial joining process, SmartThings must support the standard ZigBee HA 1.2 Trust Center Link Key join process because it’s how nearly all ZigBee HA 1.2 certified devices join a ZigBee network, and as an open platform we support many ZigBee HA certified devices from many manufacturers. As mentioned above ZigBee 3.0 will eliminate the “moment of insecurity”, but we’re also exploring methods for enhancing communication security and add the ability to validate and trust devices that join the network - but this will be limited to our own devices whose firmware we directly control, as the solution will be outside of the ZigBee specification.
I hope this helps, and thank you for taking the time to read this far. As always, please let us know here if there are further questions we can answer or clarifications we can make.