Author Archives: Felix

Athom Homey Security | Static and well-known keys (CVE-2020-28952)

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.

Half the ZigBee Sniffer Array and the KillerBee toolset

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.

Installing the default TCL key

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.

Key exchange without the global default TCL key installed into Wireshark

I quickly found the packet I was looking for and added the Network key to Wireshark in the same manner as before.

Key exchange packet with the global default TCL key installed into Wireshark

In the image above you can see that the network key being exchanged is:


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:

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.

ProxyCannon-Revival – A tool for IPS evasion

Today we are releasing a tool called ProxyCannon-Revival and it is for IPS evasion. The original ProxyCannon is a tool written by Shellntel and released back in 2015. It coordinates virtual machines on cloud platforms and local routing policies so that penetration testers can simulate a real attackers ability to come from multiple IP addresses. This ability is crucial in avoiding IPS technologies and not worrying about getting caught by IP address blocking techniques.

The tool has been brought up to date, had new features added, and had a load of bug fixes/code clean-up. It is now in a dedicated repository here.

The catalyst to the Revival

During a penetration test some of our standard not-trying-to-be-quiet infrastructure was blocked by Fail2Ban. After a bit of investigating, we got in contact with our customer. The conversation went a bit like this:

[Us] “Tick, well-done customer, now please can you whitelist our source IP addresses.”

[Them] “Actually, we would like you to act like a real attacker, and that means you have to overcome this defensive capability.”

[Us] “Ok then, that should not be hard.”

We had a look around at what projects already exist, asked some fellow pen testers about what was around, and none of the projects found fit the requirements. There are a few that appear abandoned, such as the original ProxyCannon. Others seem massively complex, requiring Terraform and multiple layers of Proxy server. And then, there were both complex and abandoned projects such as ProxyCannon-NG. We just wanted a tool that worked with minimal effort – a classic pop-pop bang-bang affair.

We took the best fit of the projects we found and tried to get it to work, but it did not. It probably worked fine until relatively recently, as blog posts were raving about it until early 2019. As it is now 2021, we guess that the OS world has moved on and left it behind.

The update

At first, the plan was to bug-fix it and do the minimal to get it up and running again. By the time it was apparent that it would not be that easy, we were already far too emotionally invested in getting the project up and running to make the sensible decision to use a different project. Cue far too much engineering effort.

There is an issue tracker in the GitHub repo for full details, but the highlights are:

  • converted to Python 3
  • added a ton of debug output, so when it goes wrong, there is a chance of dealing with it
  • code consistency improvements and general clean-up
  • refactoring the network configurations deployed to be in line with modern OSs.

The extension – cache busting

The concept of the tool is great but works best against an IP subnet of targets rather than a single IP address. That means doing an infrastructure scan would be fine, but, a web app penetration test would end up without having randomised routes.

This routing behaviour is a result of the way current Linux OS’s do route caching. Essentially, in Equal Cost Multi Path (ECMP) routing, when the connection is made to the destination a route is calculated and stored for future use. Where you have ECMP, that route is calculated for every destination IP address so you would get random routes, but not each time you connect to the same IP address.

The ProxyCannon-Revival tool now has an optional cache busting function which can be enabled with the command line switch “-b”. This function continually changes the route weights so that, strictly speaking, it isn’t ECMP anymore. In practice it will still be pretty-much ECMP when averaged out over a period of time. The use of routes in this fashion along with a cache flush mean that the routes are used more evenly against a single IP address.

The extension – link health monitor

During testing it was plain to see that sometimes, for reasons outside the scripts control, one of the routes would be unhealthy and not function properly. This means that the user ends up with confusing timeouts or a bias towards particular routes.

There is now a network link health monitor in place that continually checks to see if the links are behaving as expected and if not, marks them as down so that the script doesn’t try to use them.

This functionality is on by default, but, can be turned off if so desired with the -m command line argument.

The extension – faster tunnel IP rotating

The process of asking AWS (the only currently supported cloud provider) for a new IP address takes approximately 2 minutes to complete. This might be sufficiently quick for some purposes but that might not be the case for other use cases, such as against application-layer IPS detection capabilities in web applications.

The tunnel host IP rotating functionality is now put into a queue with its own pool of thread workers which means that more than one host can have its IP rotated at once. This is limited to 50% of the number of tunnel hosts so that there isn’t a tragic loss of routes / source IP address entropy.

Tunnel host IP address rotation threading is enabled automatically if you run both the -b and -r command line arguments together. It is assumed if you want this level of IP address fluctuation that changing the hosts IP addresses quickly is important to you.


You Gotta Hack That has adopted this project but welcomes the original authors and newcomers to join in with it if they wish. Hopefully, it will be useful for a while yet to come and plenty of you will be able to demonstrate that simple IPS evasion is easily achievable.

How you can perform IPS evasion with ProxyCannon-Revival

The tools is intended to be really easy to use. It is simply a case of getting an AWS account and security tokens, installing the python dependancies and executing the appropriate command. The command syntax is currently:

-id, default='ami-d05e75b8', Amazon AMI image ID
-t, default='t2.nano', Amazon AMI image type
--region, default='us-east-1', Select the region
-r, Enable Rotating AMI hosts
-b, Enable multi-path cache busting
-m, Disable link state monitor
-v, Enable verbose logging
--name, Set the name of the instance in the cluster
-i, default='detect', Interface to use, default will result in detecting the default gateway and using that
-l, Enable logging of WAN IP's traffic is routed through

num_of_instances, The number of instances you'd like to launch.

You have to tell ProxyCannon-Revival how many instances you want, but all the rest are optional. Highly recommend -l for logging external IPs and -r for rotating those IP addresses periodically.

Usual disclaimer

Please don’t use this script for nefarious purposes. Pentesters == good, law enforcement == good. Bad people == bad.

How we got our name….

Choosing the name of your child is hard. Arguably, selecting the name of your business is harder.

When I was choosing the name of the company, I knew a few things. I knew I wanted it to be cool. I knew it needed to have a kickass domain name. And I also knew that everything I thought of was already taken.

So like any other proudly geeky person, I set about programming my way through the problem. I wrote a little script that tested to see what domain names were available for every possible combination of Domain. I started with all the known TLDs (Top-Level Domains such as .com) and then the script added characters to the front. I ended up with a reasonably long list of possible domains, and I needed to narrow it down. My next step was to take the Domains I had identified and gather a screenshot of the first page of Google when searching for each of them. I was looking for inspiration. When I searched for YGHT, I spotted an article in the Urban Dictionary titled “You Gotta Hit That”. I instantly knew the name of my company and how I would brand it: “You Gotta Hack That”.

Something inexplicable happened along the way, possibly caused by my inner nerd, and I stook with the shortened version of the company name: YGHT. For several years using YGHT has been fine, but, it is more and more evident that on its own this only means things to those of us in the company.

We are now relaunching ourselves with the full version of our name, “You Gotta Hack That” but we won’t be losing our favourite short domain name…