TL;DR: All Athom Homey and Athom Homey Pro devices, before version 5.0.0, have a static and well-known ZigBee communications encryption key. Official CVE can be found here: CVE-2020-28952.
Previous work
I’ve been doing security research against the Athom Homey and Athom Homey Pro as time permits for a while. I have previously reported another issue with the Homey (CVE-2020-9462) that was similar in nature. Both issues are about communications crypto. The previous issue was only vulnerable for a specific period of time because it was only vulnerable during device setup. This issue is a bit bigger. It affects every Homey device out there and the user couldn’t do anything about it. Despite this, I’m still a big fan of Athom’s Homey devices. They seem to be built for geeks by geeks and that just makes me happy.
Looking at ZigBee traffic
As part of another project I have spent a fair amount of time looking at ZigBee traffic. I thought I would have a look at the ZigBee meshing capabilities of the Athom Homey. This post doesn’t go into meshing at all. ZigBee meshing is a very complex topic in its own right and deserves a whole series of posts.
For my work, I have a “ZigBee Sniffer Array”. This array is essentially 16 x CC25xx ZigBee receivers plugged into a couple of USB hubs. I use the KillerBee software suite which allows me to dump all ZigBee traffic in RF range.
Once the capture is complete, looking at the pcap in Wireshark you can see all the usual ZigBee traffic types. In ZigBee there is a publicly-known cryptographic key exchange flaw. Devices in the public ZigBee ecosystem all start with knowledge of a globally-known default Trust Center Link (TCL) key. This key is the hexadecimal equivalent of “ZigBeeAlliance09” (which is 5A:69:67:42:65:65:41:6C:6C:69:61:6E:63:65:30:39). This default TCL key isn’t a great design decision by the ZigBee Alliance but it is what it is. This is not the part that Athom got wrong.
Why is a global default Trust Centre Link Key bad?
The implications of having a default TCL key are that an attacker can sniff the communications of devices being “paired” with a ZigBee network. When ZigBee devices are being paired, the hub device shares the network key with the new device for future communications. If an attacker doesn’t capture the key exchange, they are “outside” the ZigBee network. Being outside the network eans they cannot examine the content of any messages or impersonate any devices.
The default TCL key is installed in my Wireshark as a matter of course these days. This means I can immediately read those network key exchange messages. Inserting a key is fairly trivial. It can be added in the protocol dissector configuration in the key management function.
Spotting the vulnerability in Athom Homey
I regularly find myself looking for network key exchange packets. This is so I can extract the network key to be able to do further analysis against the encrypted packets.
I quickly found the packet I was looking for and added the Network key to Wireshark in the same manner as before.
In the image above you can see that the network key being exchanged is:
01:03:05:07:09:0b:0d:0f:00:02:04:06:08:0a:0c:0d
It took longer than I really want to admit for me to realise that this network key wasn’t machine generated. Eventually it dawned on me that the pattern in the key was a little to regular to be a coincidence. I immediately went to check with another Homey in case the same key was in use there… and it was.
Worse still, the default Network key I observed I later found out is a ZigBee chipset defined default key. So this key is likely used in all manner of ZigBee devices around the world. A quick search online for that key finds dozens of hits.
Responsible disclosure
As always, I got in contact with the vendor on the 19th November 2020:
Hi Athom Support Team,
Just getting in contact because my slow-time research has brought another issue to light that I am hoping you will be interested in discussing.
As per my previous contact, I will be applying for a CVE for this, I am not looking for any form of payment / reward, instead I am just hoping to make the world a better place. This email marks the start of a 90 day period before this vulnerability is published unless our discussions indicate that an extension is wise.
I have been looking at ZigBee communications and packet sniffing and know the protocol reasonably well. I know that the weak point for all encrypted ZigBee communications is the pairing / enrolment process. This is because the vast majority of ZigBee devices are within the public ecosystem and the key exchange process must use a Global Master Key – this is publicly known and is the hexadecimal equivalent of “ZigBeeAlliance09”. What is supposed to happen is that the hub generates a unique Standard Network Key which is then exchanged with all enrolled devices so that all communications with that device and between those devices is encrypted in a secure fashion from that point onwards. Unfortunately I found that your devices use another widely known key that is designed for testing purposes:
“01030507090b0d0f00020406080a0c0d”
This is the decimal equivalent of 1 3 5 7 9 11 13 15 0 2 4 6 8 10 12 13 which is clearly human generated.To confirm that this is not just a coincidence I repeated the packet
capturing with a second Athom Homey and a different model ZigBee device and found the keys were consistent.What this implies is that all Athom Homeys use the same standard Network key for all ZigBee traffic. This means that if I can find one of these devices deployed, I will be able to capture the decrypted traffic, inject my own traffic and modify existing traffic within the targeted network. For this to work, I do not need to be present for the enrolment process to capture the network key during the known-insecure key exchange process.
To be clear, what I am not saying is that Athom should attempt to fix the Key Exchange problem – this is with the ZigBee spec. However, I am saying that it is inappropriate to use a static Standard Network Key, let alone one that is publicly known.
Please do let me know that you have received this email. I am happy to help / give advise and would be keen to hear how you are planning on correcting the issue. Once again, this is not any form of extortion – I do not expect payment of any kind.
I won’t name the individual, but my friendly Athom support desk contact was on the case within an hour. Within 10 days they were in contact again saying that they were releasing a fix alongside their major version release that was scheduled for the not-too-distant future. That major version was released on the 11th February 2021.
Confirming the fix
I came to perform testing of their fix when version 5.0.1 had been released. I can only assume it was in place for the earlier sub-version, but, it is possible that the behaviour may have changed. Rather frustratingly, upon performing the upgrade from v4.2.0 to v5.0.1 my ZigBee network simply stopped working. Knowing what I was looking for this wasn’t that big a surprise. I got out my ZigBee Sniffer Array and had added a device back into my ZigBee network. Low-and-behold, a completely new network key was found. This is why my previously-connected devices stopped working: they no longer had a valid network key.
From a user-perspective the lack of warning, or better key-management is a bit frustrating. I imagine there are plenty of people who upgraded and then found that they had a non-functional ZigBee network. However, this is arguably better than what the guys at Athom had originally planned. They wanted the encryption key update to be an “opt-in” feature. This would mean the user would have to actively go into the settings and reset the network to get a new key. This option clearly leaves all existing user’s without protection.
The good news is that it is possible for an average user to confirm that they don’t have the global default TCL key in their system. They can check this themselves by using the developer tools that Athom provides. Go to this website and access the developer tools where you can inspect the self-reported status of the ZigBee network. This status includes details about what ZigBee channel is in use, mesh routing, the extended PAN ID, and the Network Key.
EDIT (2021-03-12): I had an automated update for another Homey I own to v5.0.1. This one didn’t get an automated key rotation… I am going to have to do it manually and I suspect that is going to be painful and require re-building the whole network from scratch. This is frustrating both personally as well as from a security perspective as this means there will be significant numbers of installations that are left unprotected.